Recap and proposal: align the WordPress release cycle with the industry standard

Following a lively conversation that happened in this blog in October 2020, here is the recap of the different ideas that were brought up and the proposal to move forward.

Rename phases

There is a consensus here.

NowChange to
Phase 1: Planning and securing team leadsPhase 1: Preliminary Planning
Phase 2: Development work beginsPhase 2: Alpha
Phase 3: BetaBeta 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.Phase 3: Beta (stays the same)
Phase 4: Release candidaterelease candidate 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).Phase 4: Release Candidate (stays the same)
Phase 5: LaunchPhase 5: General release

Restructure Beta

The main point of discussion is what is allowed and what is not allowed during Beta.

Reserving Beta for testing and fixing bugs discovered by testing respects the efforts of the beta-testers by not introducing new bugs in areas they’ve already tested.

@azaozz

The wider software industry has done this work [how a release cycle is structured] for us. A mature software project is one that has a beta period during which the focus is on testing changes made during this release cycle to ensure its stability. Our current workflow means a random bugfix can go in ten minutes before RC 1.

@johnbillion

However, there are concerns specific to our project

I worry that we aren’t allowing space for older bugs that aren’t specific to the planned features in the release. I also worry that by calling hard freeze earlier in the process we narrow the window for feature inclusion too much. I think Matt agrees with my thoughts there, as well.

@chanthaboune

My concern here is to not shorten the time allowed for fixing older bugs, which I see as an essential part of the project.

@sergeybiryukov

Proposed solutions

Adding a “Feature Freeze” period came up from multiple parties and it seems to be the most popular solution to allow contributors to focus on features first and defect work later, without doing the defect work in Beta, which should be reserved for testing.

Easier said than done… @hellofromtonya presented us with two solutions

Proposal 1: feature freeze and then do defect work

This proposal is for a feature freeze 2-3 weeks before Beta 1 and then allocation of this time period for defect work.

Pro

This proposal has a clear definition in the major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. cycle after the major release is kicked off and when the release squad is in place. 

Concerns

  • It does not capitalize on the overlap between releases.
  • It does not provide a way to reduce the overall release cycle.
  • Does the major release squad need to be focused on the continuous defect work (i.e. defects not directly caused by the release)?

Proposal 2: defect work during release overlap

This proposal front-loads the defect work to overlap the previous release’s Beta and RC.

Pros

  • Work continues with purpose and focus while the previous release is in its testing and release phases. It capitalizes on the time between major releases while keeping the momentum rolling forward.
  • It provides an opportunity to shorten the overall major release cycle.

Cons:

  • Do we need the current release squad to be involved in this early phase or even in the defect cycle?
  • Could the component maintainers and CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Team work together to help prioritize and escalate defect work?

Branchbranch 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". at Beta

In both solutions, trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. gets branched at Beta

Length of Beta

Both solutions beg the question: is Beta long enough? For 5.7 it’s three weeks. If the leadership of the project decides to move forward with one of the above-proposed solutions, WordPress 5.8 will have to account for a longer Beta probably. See:

Concern: We already have feedback that it’s hard to keep up with changes for our pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party/theme authors. While a change like this is possible, it would require some paradigm shifts that I don’t think have been fully explored.

@chanthaboune

Call to action

  1. Discuss this during the next dev-chat (January 13) and leave comments open for an additional week (January 20)
  2. Present any additional evidence gathered to Josepha and Matt for final saying.

Thank you @hellofromtonya for peer review

Dev Chat Agenda for January 20, 2021 & January 21, 2021


Here is the agenda for this week’s meetings to occur at the following times: January 20, 2021 at 5:00 UTC and January 21, 2021 at 20:00 UTC.

Please note that the regular dev chat will be one day later due to the U.S. Presidential Inauguration. The APAC-friendly dev chat will remain at its usual time.

Blogblog (versus network, site) Post Highlights

Next Releases

  • WordPress 5.6.1 (Release to be scheduled)
  • WordPress 5.7 (BetaBeta 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. 1 is 2 weeks away 🎉 on February 2nd)

Components check-in and status updates

  • Check-in with each component for status updates.
  • Poll for components that need assistance.

Open Floor 🗣

Do you have something to propose for the agenda, or a specific item relevant to our standard list above?

Please leave a comment, and say whether or not you’ll be in the chat, so the group can either give you the floor or bring up your topic for you, accordingly.

This meeting happens in the #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

Editor chat agenda: 20th January 2021

Facilitator and notetaker: @get_dave.

This is the agenda for the weekly editor chat scheduled for 2021-01-20 14:00 UTC.

This meeting is held in the #core-editor channel in the Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

  • GutenbergGutenberg 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/ 9.8 release (release candidate already available).
  • WordPress 5.7 Beta 1.
  • Monthly Plan for January 2021 and key project updates:
    • Global Styles.
    • BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. based WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. Editor.
    • Full Site Editing.
  • Task Coordination.
  • Open Floor.

If you can’t attend the meeting, you’re encouraged to share anything relevant for the discussion:

  • If you have anything to share for the Task Coordination section, please leave it as a comment on this post.
  • If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.

#agenda, #core-editor, #core-editor-agenda, #meeting

Stale Issues in Gutenberg Repository

In the Core Editor meeting on Jan 13th, a group of us discussed the idea of implementing a “StaleBot” that will automatically close issues and PRs based on a level of inactivity (no comments or commits) after a period of time. Before implementing, it was agreed that it would help to get more thoughts and opinions to make sure this idea is set up for success. 

Please share your thoughts by Jan 29, 2021. If there are no major concerns, implementation will proceed. 

Implementation Details

Using a stale bot is a common practice among repositories, the ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. project uses the Probot Stale bot to automate, with a 90 day policy. The bot allows customization of the time, messaging, and the ability to configure a specific label to skip auto closing. This gives great flexibility to make an implementation work for us.

The current recommendation is to set our policy to a 180-day of no activity, so if no comments or commits are on an issue or PR in 180 days, then the bot will post a comment to the issue alerting the user it will be closed in 7-days due to inactivity. The proposed message:

This is an auto-generated message to let you know that this issue has gone 180 days without any activity and meets the project’s definition of stale. This will be auto-closed if there is no new activity over the next 7 days. If the issue is still relevant and active, you can simply comment with a “bump” to keep it open, or add the “[Status] Not Stale” label. Thanks for keeping our repository healthy!

Important to keep in mind, closed tickets still exist, they maintain all the same info, are searchable, and can be reopened with one click. Further, if it turns out that this change has an unexpected negative impact, this can always be removed! 

Leave Feedback

Feedback on the following by January 29, 2021 would be the most helpful: 

  • What concerns (if any) do you have about implementing this? 
  • Does 180 days of inactivity seem like the proper time threshold?
  • Does giving 7 days to respond feel like enough time? 
  • Is the message clear yet friendly enough? Would you make any changes? 

#core-editor

WordPress 5.7: What’s on your wishlist?

With the 5.6 release scheduled for December 8th, let’s start planning for 5.7!

We always aim to fix bugs, add new tools, and make WordPress better than ever for users. Components of Full Site Editing are still at the top of the WordPress goals list; what other tickets do you think need some attention in this release cycle?

Share Your Feedback!

  • What do you want to see included in 5.7?
  • What are the current UXUX User experience pain points?
  • What features can we add or iterate on?
  • Component Maintainers: what tickets do you think will be ready to ship by late January and need some review/feedback/approval/etc?

Note: Adding your ticketticket Created for both bug reports and feature development on the bug tracker. here won’t necessarily guarantee inclusion. But no one can fix things they can’t see, so bravely share your thoughts!

Deadline December 15, 2020

#5-7

Bug Scrub Schedule for 5.7

With 5.7 officially kicked off, time to schedule the 5.7 sessions. These 5.7 specific ticketticket Created for both bug reports and feature development on the bug tracker. scrubs will happen each week until the final release.

Early Scrubs:

Focus: early tickets, tickets that require more time or early testing.

Alpha Scrubs:

Focus: features and enhancements.

Beta Scrubs:

Focus: issues reported from the previous beta and defects.

RC Scrubs:

Focus: issues reported from the previous RC

Check this schedule often, as it will change to reflect the latest information.

APAC-friendly scrubs will be led by @lukecarbis.

What about recurring component scrubs and triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. sessions?

The above 5.7 scheduled bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrubs are separate and in addition.

For your reference, here are some of the recurring sessions:

  • Design Triage: Every Tuesday 16:00 UTC in the #design channel (for both coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and GutenbergGutenberg 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/).
  • AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Scrub: Every Friday 14:00 UTC in the #accessibility channel.
  • APAC-friendly Scrub: Every Tuesday at 05:00 UTC in the #core channel. This scrub will continue during the cycle, alternating focus between core and editor.
  • Testing Scrub: Every Friday 13:30 UTC in the #core channel.

Want to lead a bug scrub?

Did you know that anyone can lead a bug scrub at anytime? Yes, you can!

How? PingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” me (@hellofromtonya) on slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. and let me know the day and time you’re considering as well as the report or tickets you want to scrub.

Planning one that’s 5.7-focused? Awesome! We’ll add it to the schedule here. You’ll get well deserved props in the weekly Dev Chat, as well as in the #props Slack channel!

Where can you find tickets to scrub?

  • Report 5 provides a list of all open 5.7 tickets:
    • Use this list to focus on highest priority tickets first.
    • Use this list to focus on tickets that haven’t received love in a while.
  • Report 6 provides a list of open 5.7 tickets ordered by workflow.

Need a refresher on bug scrubs? Checkout Leading Bug Scrubs in the core handbook.

Questions?

Have a question, concern, or suggestion? Want to lead a bug scrub? Please leave a comment or reach out directly to me (@hellofromtonya) on slack.

#5-7, #bug-scrub

WordPress 5.6 Beta 4 delayed from November 10th to November 12th, 2020

During the November 4th core chat, some questions were raised about the readiness of the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. auto-update feature, scheduled to land in WordPress 5.6. Questions ranged from the implementation of it to the scope of the output desired. A separate post is coming with more information on that discussion and the planned next steps.

In order to allow some more time to refine the work done so far, WordPress 5.6 BetaBeta 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. 4 will be delayed from today, November 10th, to Thursday, November 12th, 2020.

At this moment, no delay is expected on the release: everyone is working to make WordPress 5.6 available on December 8th.

Thank you to @francina who helped me craft this draft. 🙂

#5-6, #auto-updates, #core-auto-updates

Block Editor Handbook: restructuring project update (15 January)

This post is the first in a series that will be published regularly on the Make/CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blogblog (versus network, site). The purpose of this series is to keep everyone up to date on the progress of the BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor Handbook restructuring project.

Currently, we are working on improving the handbook’s homepage. The goal is to make this page a real “Getting Started” page.

Someone coming to this page should be able to have a good overview of what the block editor is all about. They should also be able to find references to how to extend the block editor, how to contribute to it, or to the documentation of its main concepts.

The issue related to the handbook homepage improvement is here and here is the corresponding pull request.

Thanks to all the contributors who helped on the project this week 👏🏻.

#block-editor, #developer-documentation

Dev Chat Agenda for January 13, 2020

Here is the agenda for this week’s meetings to occur at the following times: January 13, 2021 at 5:00 UTC and January 13, 2021 at 20:00 UTC.

Blogblog (versus network, site) Post Highlights

Next Releases

  • WordPress 5.6.1 (Release to be scheduled)
  • WordPress 5.7 (Upcoming BetaBeta 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. 1 Release on February 2nd)

Components check-in and status updates

  • Check-in with each component for status updates.
  • Poll for components that need assistance.

Open Floor

Do you have something to propose for the agenda, or a specific item relevant to our standard list above?

Please leave a comment, and say whether or not you’ll be in the chat, so the group can either give you the floor or bring up your topic for you, accordingly.

This meeting happens in the #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#5-7, #agenda, #dev-chat

Editor Chat Agenda: 13 January 2021

Facilitator and notetaker: @annezazu

This is the agenda for the weekly editor chat scheduled for Wednesday, 13 January 2021, 14:00 UTC.

This meeting is held in the #coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-editor channel in the Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. and all are welcome to join!

Even if you can’t make the meeting, you’re encouraged to share anything relevant for the meeting in the comments below:

  • If you have anything to share for the Task Coordination section, please leave it as a comment on this post.
  • If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.

#core-editor #core-editor-agenda