Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ is a big project, and many WordPress contributors have limited hours in which they can contribute. This makes getting up to speed on the scope of Gutenberg a daunting (if not insurmountable, at least in the WordPress 5.0 timeline) task. With this phase of the Gutenberg project setting the stage for the future of WordPress development, I’m sure you’re wanting to get involved in whatever way you can, so my goal is to help you get up to speed as quickly as possible. Every one of you has different skills, availability, and experience with the Gutenberg project, so the Gutenberg and WordPress 5.0 teams need your help to prioritise what information you need.
If you’re an experienced contributor or committer A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. who has time available during the WordPress 5.0 release cycle, and want to be able to make meaningful contributions towards making WordPress 5.0 awesome, you’re exactly who I need to hear from.
Please reply to this post with information about your availability, what components of WordPress you have experience in, and (if you haven’t got involved with Gutenberg yet) what you feel has been getting in the way.
In the mean time…
While we’re sorting out which tasks are available, please read Gutenberg’s Getting Started documentation, and get a Gutenberg environment up and running. The helper scripts in the Gutenberg repo use Docker, but if you already have an environment you prefer, there’s no need to switch: just make sure you have Node 8.x (or higher), and the latest NPM installed.
There are a few places where you can start straight away, depending on which components are of particular interest to you:
I’m also putting in a special request for folks to help with triaging Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. reports:
- Open tickets in the 5.0 milestone need to be reviewed, most of them should be moved to the 5.0.1 or 5.1 milestones.
- Closed tickets in the 5.0 milestone need to be reviewed, and reopened if the need to be ported to the 5.0 branch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch".. If they don’t need to be in 5.0, there are two options:
- If they should be in a 5.0.x release, move them to the 5.0.1 milestone, and reopen them for porting after 5.0 is released.
- If they can wait until 5.1, move them to the 5.1 milestone. If they need changes due to the milestone move (eg, inline documentation needs to be updated to the new version), reopen them.
Open tickets in the 4.9.9 milestone will mostly be moved to the 5.0.1 milestone, though there may be some that are appropriate for 5.0. Closed tickets in the 4.9.9 milestone will probably need to be reopened and moved to the 5.0 or 5.0.1 milestones.
These are just a few areas you can explore to get started. If there’s a different area you’d like to be contributing to, please say so, and we’ll see what we can find!