WCUS 2024 Core Committers Meeting Notes

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. US 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.

What is the right way to commit?

A newer 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. mentioned that established committers have been very supportive and helpful getting them set up and comfortable. However, they often question whether they are doing things right. There is baseline documentation in the handbook around committing and some extensive documentation around commit messages, but every committer seems to have a different setup with a different tool set.

Some takeaways

• There’s no wrong way to set up your environment or make commits.
• To increase the amount of documentation around committing, every committer should blogblog (versus network, site) about their set up (and more about committing in general)! A new page has been created in the Core Handbook to serve as a blogroll for these posts and will be updated as new ones are published. Everyone is welcome to publish, including emeritus and committers who were not in attendance at WCUS.
• Using the #core-committers channel for questions around committing process is always appropriate.

Clarity around requesting feedback

The next discussion was around how to properly seek feedback from other contributors and committers. The Make Core Blog has recently felt a bit too “official” for these more casual posts. But in the past, these types of posts were perfect for the Make Core blog. Is this no longer the place for these types of discussions?

The ideal purpose of Make Blogs was discussed a bit, and it was mentioned that there was a 2 part discussion at the 2023 Community Summit focused on this. It was suggested to read through the session notes to see if there were any mentions of this.

Some takeaways:

• There’s value in posting on your own blog to validate your own ideas and understandings vs. speaking on behalf of WP to the community.
• It’s OK to share posts on your blog seeking feedback as long as findings are summarized in the TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker..
• As long as it’s accompanied by a problem statement/theory/points needing validation, posting on the Make blog seeking feedback about that problem seems reasonable.
• It’s always preferred to have a Trac ticket outlining the problem, even if it’s unclear whether it’s something that will actually be fixed (there’s always wontfix and maybelater).
• Moving more “official” communication to the relatively new Developer blog makes sense. This would include the Field GuideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page., developer notes, etc.
• No matter where these discussion points are shared, make sure to be clear about what type of feedback you are seeking.
  • Is this idea unrealistic?
  • Are there blockers that are not apparent?
  • Is there history behind why something is a certain way that is not immediately obvious?
  • etc.

Props @jorbin for pre-publish review.

#committers