At WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe last week, CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Committers in attendance (including emeritus) gathered for a brief informal meeting.

There was no formal agenda, but a few goals for the meeting were mentioned at the beginning:

• Allow newer committers to meet more senior ones.
• Allow anyone to raise questions, concerns, or suggestions that have been on their minds.
• Just spend some time together chatting and getting to know each other.

Below are some brief notes from discussions that happened following Chatham House Rule.

6.9 Release Cycle

The current 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 was discussed for a bit. More specifically, what should the targeted features be? With (more) recent changes to contributor availability, it’s possible there could be a 6.9 this calendar year (was later confirmed as the goal by Matt in the fireside chat).

A new or revised short-term roadmap would help committers and contributors alike participate more effectively by providing clarity on the current focus areas, goals, and targeted features. For the long-term, clarity on whether the 4 phases are still accurate objectives.

6.8.x Releases

These should continue to be planned and executed as necessary. If major releases are going to be less frequent, carefully including smaller features and enhancements in minor versions would be beneficial.

If the timeline for the next major release does change, minor releases may not have as many contributor resources. That needs to be watched to ensure continued success of minor releases.

Possible Short-Term Targets 

A handful of possible short-term features and tasks were identified to explore:

• address technical debt
  • there are many areas of the code base that can likely be moved from Core to a canonical 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.. For example, the Links/Bookmarks APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.
  • No-op or remove severely outdated classes deprecated long ago (3.0 times). For example, Snoopy. 
• Perform ticketticket Created for both bug reports and feature development on the bug tracker. triaging without being afraid to say “no” more often.
• Discuss what role themes have in present day WordPress.
  • Should we continue creating default themes going forward?
  • What do we want  as a project from 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. themes?
  • How does the pattern directory, font library, block plugins, etc. replace traditional theme components?
• Audit the importer plugins.
  • Can we possibly archive repositories for importers for services long decommissioned?
  • Should we mark the importers as canonical plugins?
• Better contextual integration points for canonical plugins (suggest installing to the user when performing related actions)
• How can we better collect feedback from users that choose to install canonical plugins?

Bring Back User Testing

Previously, the project conducted user testing. That seems to have stopped, but this practice was very beneficial and informative. It showed how the software is actually used by users and whether the intended experience was achieved.

It would be great to resume this practice. However, users are goal oriented, not feature oriented. The outcome of user testing is usually not fine grained tickets for small, specific things. This requires different skill sets to address findings (foundational problems in experience vs. bugs to fix).

Increased Amount and Quality of Testing

If releases are spaced out more (ie. once per year), testing early and often is more important to avoid a large number of bugs down the home stretch of a release cycle.

There were questions around whether we were doing a good job encouraging the right types of quality testing.

• the testing during release parties can likely be covered more effectively by E2E tests. Contributors are performing the same actions and not truly testing the features that are being shipped.
• This allows for better testing actual features with specific interactions.
• The ideal testing could be detailed prior to the release party.
• When developer notes are published, they could include specific testing instructions.
• A specific dev notedev note 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. outlining the different testing paths and intended outcomes could also be published to the Make Test blogblog (versus network, site).
• Testing during release parties is a great way to get started contributing, but it’s gotten to a point where that testing is not a good use of resources. Too many people doing the same shallow testing at once. 
• Can the 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. testing plugin contextually bring in testing instructions?
• Can the beta testing plugin better engage the user. Some inspiration can be taken from Apple’s Testflight.

Next Meeting

It’s time to schedule the next virtual Core Committercommitter 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. meeting on Zoom. The date and time of this will be coordinated in the #core-committers channel in 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/. 

Props @johnbillion, @flixos90 for pre-publish review.

#core-committer-meetings, #core-committers