At the dev chat last week, we talked a bit about WordPress 3.8 and the features-as-plugins process. Here’s a recap of what was discussed:
Expectations
A lot of features are in development right now, at varying stages. Given the huge list of new features, there’s no way they’ll all be in WordPress 3.8. That’s okay, and it’s by design.
The features-as-plugins model makes it easy to wait for a feature to be ready before including it in a release. It also allows for a lot of experimentation. Some ideas might not otherwise be developed into potential features, while others are large and complex, and might take multiple cycles to complete. But experimentation can lead to a fully scoped or even fully developed feature that never makes it into core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. because, after hashing out the details, it’s realized it isn’t something that belongs in core. Don’t let that discourage you — trial and error is part of the process and will result in better features and a better WordPress. Features that don’t get included in core can continue to live on as awesome plugins, and the whole ecosystem benefits. In the past, the core team would have suggested that a feature start as a plugin 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 anyway; this formalizes that process.
Ultimately, the decision on whether a feature makes it into core rests in the hands of the core team. To ensure you’re on the right track, keep in contact with the next release’s lead and the lead developers. The release lead The community member ultimately responsible for the Release. should understand what problem you’re trying to solve and why the direction you chose is the appropriate one to solve that problem.
Timeline
For features to be included in a release, they must be ready for the release’s first meeting — that is, day one when the development period begins. At that point, the release lead will review current projects, and along with core developers, determine if they’re fully baked and ready for merging into core.
They’ll be looking for a number of things, including a strong and well-tested user experience, fully-baked design, positive feedback from the community, core-quality code, no major bugs or issues, and a belief that the feature belongs in WordPress core. Every feature is different, so “ready” will mean different things depending on the specific feature, but a release lead must feel comfortable taking on primary responsibility for a feature and the core team must be comfortable taking on responsibility for the long term.
If the core developers decide a feature isn’t ready for core, they’ll let the feature lead know why and what can be done to prepare the feature for a future release.
Features that have been approved for inclusion will have a merge window of about two weeks (timeline still being decided) to get their code into core and wrestle with any latent issues getting it merged. However, as stated above, features must be ready for merging at the start of the merge window.
Who’s responsible for features?
After a feature gets merged into core, the feature team remains responsible for the feature, with added support from the core team. As with any part of WordPress, feedback comes from the entire community. However, after merging into core, a feature will receive a lot more visibility than in the plugin phase. Focus is important to ensure the feature ships.
Keep in mind that while the team remains responsible for the feature in core, ultimate decision-making rests in the hands of the core team, as with any part of core. The release lead will obviously work closely with the feature lead and entire team.
tl;dr
- Sometimes features won’t end up in core. That’s okay! Not everything belongs in core. It’d still be a great, community-built plugin that helps to improve the ecosystem. Maybe it serves as a prototype, or lessons learned, or even a base for a future initiative.
- Don’t expect your feature to make it for 3.8. These are features being built with the potential for inclusion in a future version of WordPress. They are not “3.8 features.”
- To be included in 3.8, features must be “ready,” as defined by the core team, at the start of 3.8 development, shortly after 3.7. Be sure to keep in close contact with the release lead.
Questions? Comments? Ask away!
#3-8, #core-plugins
You must be logged in to post a comment.