The CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Program team has an evolving process. Often people will come with things that need shaping and working out or forming into roadmaps. In order to do this a simple, light flow is needed. Currently the following is being done:
Step one: clarify need and ownership
Once a need has been made or request shared, get as much initial information as possible. This can help clear up how the next steps should be made. Ensure that nobody else is doing this or wants to champion it. Make sure to have as clear as possible a scope, although that can also be and should be defined in the next step.
Step two: create discovery issue
Before too long create 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/ repo for Core Program and issue that does some discovery into the need. In this you can find out all the aspects from resources through to actual need. A few things to consider:
- If a post, go over it and pull out action points.
- Look at resources and boundaries: timelines, people and systems to manage. Is there for example an expected outcome for v1 and also a repo?
Be sure to pull everyone in who might be useful at this stage, don’t go alone.
Step three: roadmap and system
Now you know the scope you can propose a plan. This will either be done in a project board on core program or in the specific ones for the project supporting. This can take some time to form and should be done ideally in collaboration with anyone that has been identified along the way in discovery. Systems to monitor and manage the roadmap are also generally set up at same time, for example project management.
Step four: share, get feedback
Perhaps one of the most important steps is to share the proposed plan and approach. This then declares for wider community what is going to happen. Those interested will have been following, but this is key to make sure to be visible and also give opportunity for others to join the adventure. You never know who might have useful information to empower or adjust in a valid way the roadmap and plan.
Step five: living roadmaps
The final piece is to have a living roadmap. As part of this continuous reporting should happen. The roadmap is formed at this point and then in the process of delivery. Roadmaps need iteration, there should be key points set to review and if those aren’t met decisions need to happen. For example, course adjustments can happen because the roadmap is a living document. This is all part of seeing the process as not ending with putting the roadmap in stone, but checking it and keeping it alive.
