This is the final post in our experimental, asynchronous releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. retrospective. It took a bit longer than expected, but I think the information here is very valuable. As I reviewed all the responses, there were a few things that became apparent to me.

First is that there are responses from a wide variety of roles in our ecosystem* and I was pleased to see that. Second is that most people responded with great care. Even while being strong advocates, there was acknowledgement of the complexity of this open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. project as well as awareness of everyone’s humanity.

I want to acknowledge the courage it takes to give candid feedback on something you have strong feelings about, and thank everyone for taking the time for such thoughtful replies. As a community, I think we’re all very lucky to work with such passionate and caring contributors/technologists/friends/colleagues.  

As with all retrospectives, this isn’t a To Do List for the year. There are discussions to be had about what is possible, what is complete, and what is on the horizon.

Important Context for this Post

Who Responded

• Responses: 48
• Locations:
  • 23 from the US
  • 3 from Australia and Germany
  • 2 each from Canada, France, Italy, Portugal
  • 1 each from Algeria, Bangladesh, Denmark, Greece, Israel, Norway, Paraguay, Russia, UK
  • 18 unknown
• Contributions: (For those who shared their usernames) most were regular contributors. The remainder are active members of the broader WordPress ecosystem building plugins and sites for clients. 17 had experience leading or helping lead releases.
• Company Sponsored: 13 (that I know of)
• Identified as Women: 7

How Responses Were Gathered and Analyzed

I used a modified Start/Stop/Continue technique for this retrospective. The modification is in the asynchronous nature of the process, and there is room for improvement. I posted it originally here on make.wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org//updates and shared it via Twitter, 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/. DMs, and cross-posting to contributor team sites. I am the only one who saw the complete feedback, to help create psychological safety for anyone responding — though I did ask for usernames, in case the feedback wasn’t clear. I synthesized the responses below, retaining as much of the original language as I could (which is why there is inconsistent grammar throughout).

*Groups Referred to in the Responses

Leadership – Project Leads, Focus/Release Leads, Committers
Contributors – Anyone creating code, design, copy, etc
Ecosystem – Anyone providing supporting products (plugins, themes, training, etc)
Community – Anyone using WordPress but not included in groups above

Start

Two clear trends emerged when reviewing the suggestions for things to start in future releases: Communication Practices and Documentation Practices. The suggestions listed in the Documentation Practices were mentioned by almost everyone. There was a wider variety of suggestions about Communication Practices, but nearly everyone suggested some changes in this area.

DOCUMENTATION PRACTICES

Members of the ecosystem request the following documentation from WordPress Core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org.:

• Developer documentation should be available at the time of RC1.
• Documentation for users should be available at the time of release.

WordPress Core contributors request the following documentation from project leadership:

• A documented roadmap including what informed the roadmap.
• Documented and consistent metrics for decision-making.
• Update and standardize the unwritten parts of the release guidelines so developers know what to expect.
• Document target numbers for open tickets in each milestone.
• Identify personas at the start of major projects (to help standardize design choices).
• A democratic process for feature inclusion.

COMMUNICATION PRACTICES

Most suggested changes to communication practices applied to all groups involved in the release, unless otherwise noted.

Better Signal to Noise Ratios — all these suggestions were directed toward leadership

• Clearer explanation of decisions (including listed pros and cons).
• More effective ways for complaints to be heard from the ecosystem and community.
• More effective ways for critical issues to be shared to leadership.
• Begin a practice of designated dissenters.

Project Communications — mostly suggestions directed toward ecosystem and contributors

• Communicate about planning discussions and decisions (ie release dates, project timing, and any adjustments) on relevant Make sites.
• More effective communication between teams in the project.
• Choose a single site for project info rather than a collection of personal sites.
• More transparent processing of data gathered from featured plugins.
• Start cross-posting updates about the release process and devchat to other sites in the Make network.
• Have a template for CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. to share information about decisions and how they were made (problem it solved, other options considered, benefits to users, negatives to users, who made the rec, who decided on the rec, how to provide feedback).
• Clearer consequences for violating project communication/CoC/etiquette standards.

Community Communications — mostly suggestions for contributors when communicating with the ecosystem and the community

• Committers should advocate for more public communication.
• Engage with users more (since Make isn’t meant for them).
• Engage with other CMS projects more.

Contributor Acknowledgement — all these suggestions were directed toward leadership

• Implement a “thank you mentality”.
• More public appreciation of volunteers, especially from leadership.
• Better acknowledgement of all contributors (not just core/code contributors).

PROCESS PRACTICES

These suggestions were directed toward leadership and contributors. There is a mixture of tactics and processes, with implementation that ranges from quite easy to quite difficult.

Project Management

• Start projects with an open call for release acceptance criteria (and refine privately).
• Find a way to make testing 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. & RCRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. easier for non-developers.
• Overhaul the Beta Test 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, make it user-focused not developer-focused
• Conduct a pre-release audit against WordPress coding standards (existing guidelines aren’t clearly actual rules or advice)
• Start having regular (but not constant) releases.
• Involve internationalization and 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) sooner.
• Decision-makers — or someone who can speak confidently for them — should attend devchat and bug scrubs.
• More effective milestone management (to combat scope creep).
• No new features after beta 1.
• Require minimum beta periods for potentially breaking features.
• Have the About page ready by RC1.

Leadership Training was requested in the following areas:

• constructive critique
• conflict de-escalation (calling in vs calling out)
• public relations
• mass communications

Stop

There was broad agreement on most requested things to stop. In general, these suggestions were directed toward leadership.

COMMUNICATION

• Making decisions in private (many noted that some decisions must be made privately, but in that case recap posts were suggested).
• Marking issues as “invalid” or “out of scope” without additional context (this frequently came up with contributor acknowledgement).
• Poor feedback management practices (taking feedback as personal attacks, deleting/censoring reviews, assuming bad intent).
• Assuming that great developers are also great communicators.

PROCESS

• Disorganized management practices.
• Moving timelines without communication (esp the release date).
• Releasing immediately before flagship events and holidays.

COMMUNITY

• Letting a feature focus consume project-wide focuses.
• Excluding contributions that don’t relate to the current feature/release focus.

Continue

There was also a lot of agreement around what went well in the release, and those are listed below.

• Beginning the work with design.
• Remaining mindful of accessibility (it was noted that there’s room for improvement).
• Remaining mindful of site maintainers and users.
• Having multiple focus leads within a single release team.
• Using the feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. to lower the barrier to entry for early adoption.
• Using issues, tags, milestones, projects, etc in GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/.

Footnote: There were multiple responses voicing concern for relying too heavily on Gary’s technical knowledge and experience. There were also multiple responses voicing support for Josepha’s behind-the-scenes work. Neither of those seemed relevant to the release itself, but it seemed important to document.

A Few Changes Already in Motion

The 5.0 release happened a while ago, and contributors have already started making changes that seemed feasible and compelling.

• Start cross-posting updates about the release process and devchat to other sites in the Make network.
• Update and standardize the unwritten parts of the release guidelines so developers know what to expect.
• Developer documentation should be available at the time of RC1.
• Communicate about planning discussions and decisions (ie release dates, project timing, and any adjustments) on relevant Make sites.
• More effective communication between teams in the project.

Feedback, Please!

To help determine the highest priority item, I have two questions I want you to answer based on the information collected above. Note: Simply having the most votes doesn’t mean I can automatically fix something. This is to help me get some priorities sorted out.

1. If you could magically implement one suggestion listed above, what would it be?
2. If you were personally responsible for implementing one change above, what would you choose?