Proposal: Q4 focuses for the Core Program team

This post comes from a discussion post initially posted in the GitHubGitHub GitHub is a website that offers online implementation of git repositories that 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/ for the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Program team. In order to focus energy and be efficient, one focus is proposed. Additional opportunities for collaboration were identified and those are worth listing to continue supporting. Anything not being focused on this quarter will be documented to review in Q1 2026.

Main focus: Roadmaps

This will be initially a discovery task that ends with recommendations, leading to documentation of a proposed format someone can follow looking to make one. Potentially the tasks could be to:

  • Gather and document all existing roadmaps across teams.
  • Look at how they are built, maintained and communicated.
  • Suggest a lightweight process for teams that lack one.
  • Find a central place for a combined roadmap. Initially considering roadmap/ page as the location with potential iterations. This should not distract or get in way of each team maintaining their own roadmaps, but also provide a way for contributors to see what needs working on.

There might be other tasks form during this. An initial GitHub issue has been made to enter discovery for Roadmaps.

Collaborations

During the initial collection of ideas for goals and focuses there were a few opportunities for the Core Program team to collaborate. Whilst not a direct goal, these will be continuous areas and those linked are done so as people identified to connect with and find out how the Core Program team can continue to support.

  • WP Credits: this team needs feedback but also programming support as it grows and @peiraisotta has supported this connection. One particular idea to work on in future is even a list of opportunities to contribute.
  • Five-for-the-future: @gusa raised on several occasions where opportunities might arise for programming to support this area.
  • Tooling for WordCamps: this is in discovery right now. @harmonyromo is championing this work as what direction it will take is being worked out.
  • Improving recognition of invisible contributions: @estelaris is working on this by starting within the documentation team. @felipevelzani also continues to do work around non-dev contributions.

Next steps and get involved

Now there is a proposed goal to focus on, the next step is to get feedback and then start working on this together. This post is that opportunity. Is there anything you would like to add? Are you interested in collaborating or getting involved in any particular area?

Props to everyone that contributed to the discussions for Q4, release and future, helping form this focus and also those that reviewed this post: @annezazu, @4thhubbard, @peiraisotta, @jeffpaul.

Proposal: team communication flows

This is a proposal that comes from a Slack discussion and now needs some more consideration here on the make site. To summarise, what is being looked for is feedback around how the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Program team can start having some patterns for communication, including some processes.

1. Async not sync

At least initially the suggestion is to have all communication be asynchronous not sync – for example, meetings. What does this mean in practice?

  • Weekly check-in on Monday asking everyone to share what they are going to work on and any blockers.
  • Post on this site to share at the start of the week what has been going on within the team and the plans for week.

Why is this being proposed? The likelihood is that many who will end up on this team are also contributing across other teams that require meetings. The idea is also this helps others know more what is going no with a regular cadence. The post will summarise things such as 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/. conversations and cross team collaborations.

What are your thoughts on this type of communication being proposed? Anything else you would like to see this team do?

2. Repo/Project board

In order to co-ordinate things a bit more in this team, setting up a project board might be helpful. This is something that needs feedback on. Will this distract people or will it help for example? A suggestion is to have a GitHubGitHub GitHub is a website that offers online implementation of git repositories that 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/ repo and use issues perhaps also including discussions. There are a few things need to be done though if this happens:

  • Any topic put on an issue or discussion that requires feedback and input should also be posted on this make site. Silos of conversations are key to avoid. This make site can along with the weekly check-ins can hopefully also help bring visibility to anything.
  • Any project board also needs logging on this make site. This ensures contributors know where to find things.
  • Documentation around where to put topics and why needs to be made, to ensure people get to the right place with their awesome perspective.
  • One option could be to not have discussions at all on this repo and just stick to issues, boards. This could perhaps avoid having conversations in yet another place.

What do you think? Should this happen or what could be the issue with having a project board and repo? Should discussions be included or not? Is there a better option not considered? If this doesn’t happen how should goals and other discussions be logged, planned and co-ordinated with everyone having easy access to it? Your feedback is important and you might have a different idea could really help empower this.

3. Goals

Setting goals for this team feels important. The current recommendation is the following:

  • Set for each release of WordPress specific goals to get done.
  • Once the year rolls around have yearly goals split out into quarters.

By following this cadence just like the project within core shipping can be a focus. What these goals are yet is not decided, that will be done together and through public channels. To give some ideas, initially the goals will most likely propose to be aligned to what has been shared in the announcement post and perspectives shared over the first few weeks within the Slack channel.

What are your thoughts on this cadence for goals? Do you think this is the right path? What other ideas do you have for how this could work?

Next steps

Once feedback has been gathered here, the handbook can be updated with consensus and the team approach.

#feedback-wanted