This is the final post in our experimental, asynchronous release 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 source 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.org/updates and shared it via Twitter, Slack 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 contributors:

• 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 Core 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 beta & RC easier for non-developers.
• Overhaul the Beta Test plugin, 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 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 plugin to lower the barrier to entry for early adoption.
• Using issues, tags, milestones, projects, etc in GitHub.

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?