Two years ago, efforts were made to provide more clarity in the Gutenberg GitHub repository to make it simpler to keep up to date with work underway at various levels. This post focuses on a piece of that effort: iteration issues and the growing role they can play to make it simpler to follow ongoing work in the 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/ repository at critical periods. Iteration issues should happen alongside dev notes Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. and merge proposals.
Changes to Iteration issues
As a reminder, these iteration issues are solely for following dedicated tracks of work in the Gutenberg repository, and their goal isn’t to replace the Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets that we use for tracking tasks.
- For each release, open a new iteration issue with the [Type] Iteration label and a name similar to “Feature Name for WordPress X.X”. Do not re-use an iteration issue from a prior release.
- Before the beta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. cycle for the release, updates need to happen at a minimum of once per month.
- 1 week ahead of beta and during beta/RC One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). periods, updates need to happen weekly. In particular, emphasis should be put on updates ahead of beta 1, RC1, and the final release.
- When the work on a release is done, close the iteration issue and open a new one for the next release as needed.
The aim in doing this is to make it easy for folks to stay up to date on features being worked on for major WordPress releases. Currently, pulling together accurate and up-to-date information remains too fragmented, partially due to either the lack of timely updates to Iteration issues or due to the lack of an iteration issue, leading to too few people who have the time/effort/expertise to sort through it all. This has led to confusion in the lead-up to key moments in the release cycle and is a vulnerability in the process that needs to be rectified. By contributors dedicating themselves more deeply to curating Iteration issues and keeping them up to date, that information can remain a shared resource for all in a consistent way and help us lean towards automation over the reliance of individuals to collate.
When should an iteration issue be opened?
Most, if not all, headline items in roadmap posts need iteration issues. When in doubt, create one.
What makes a good iteration issue?
To help more folks succeed in creating a good iteration issue, there is a new Iteration issue template when creating an issue that follows these best practices:
- Assigned contributors planning to work on it. As needed, this includes assigning someone to handle updates.
- A scope of work tailored to the release and the timeline, with necessary issues opened.
- Any necessary design input or clear requests for design collaboration.
- Any open questions or known decisions should be clearly stated, with discussions branching out into various individual issues.
- Regular updates in the form of comments on the issue. Specifically, monthly in early stages of the release and weekly at later stages aka starting 1 week before beta 1.
The iteration issue does not need to start this way, but it needs to grow in this direction rapidly as the release process continues. In many cases, an initial iteration issue is opened with a smaller set of known key items to work on, and broader contributors help shape it as the release gets underway.
What makes a good update?
A good update is timely and clearly states completed work, upcoming planned work, any known blockers or decisions to be made, and a broader sense of how the work is progressing. For example, an update that simply lists a changelog of items doesn’t provide a sense of whether work is continuing at the right pace for the release and what is likely to make it or likely not to.
Ahead of key moments in a release, beta 1 and RC 1 in particular, updates need to happen weekly as noted above and should include clear summaries of what is landing in each. These can be used as foundations for any future dev notes, merge proposals, release announcement material, or even documentation.
Let’s keep iterating
Just like these issues, this is an iteration too. Please share feedback, whether you’re handling these iteration issues or using them to stay closer to the work.
Props to @tyxla @desrosj @4thhubbard @jeffpaul for reviewing
#github, #gutenberg
You must be logged in to post a comment.