The Features as Plugins model was introduced in 3.7 as the way for features to be developed for inclusion in WordPress core. This model allows a feature to be built, tested, refined, and polished before it is considered as a merge candidate. Features as plugins in progress can be tracked on a dedicated page of the Make WordPress Core blog.
A community member or new contributor, such as yourself, can propose an idea for a new feature plugin during the Feature Plugin Chat, usually held around the time a new release cycle starts.
The chat is for putting forward an idea you have, and plan on taking an active and primary role in developing. Other contributors who are interested in your idea can join the effort. The date and time of the chat are announced in a post on the Make/Core blog, and ideas are added in the comments in the form of a short proposal:
A brief (one paragraph) overview of your feature plugin proposal.
Current plugin status (idea stage, planning stage, under development, existing feature plugin, prior work, etc).
A list of those involved or already interested in your feature plugin (including you).
What you would like help with (scoping, planning, wireframing, development, design, etc).
The feature plugin development period allows for experimentation and, depending on the complexity of the plugin, may take multiple release cycles to complete before being ready to present to the Core team as a merge candidate.
Without experimentation, some ideas might not otherwise be developed into potential features. But experimentation can also lead to a fully-scoped or even fully-developed feature that never makes it into core because, after hashing out the details, it’s realized the feature 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 anyway; this process is now formalized.
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 lead developers and the upcoming release lead to ensure they understand what problem you’re trying to solve, and why the direction you chose is the appropriate one to solve that problem.
For feature plugins to be included in a release, they must be proposed during the kickoff of a release and be ready to merge at the beginning of the merge window. At that point, the release lead will review current feature plugins, and along with core developers, determine if they’re fully baked and ready for merging into core.
The release lead will look for a number of things (see the checklist below), 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. Ultimately, 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 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.
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 will come in from the entire community, more so after a feature is merged into core. The increased visibility requires the feature team to be more focused 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 work closely with the feature lead and entire team.
Touch devices can use the entire feature with no hindrance, with visual records for major flows through all new interfaces on all devices posted on Make/Flow. Make sure it functions properly on mobile by asking the Flow team to review it.
Make sure the feature plugin noops once the feature is merged. This means the plugin won’t break with a Fatal Error after code is merged from the plugin to core. (Use (class|function)_exists() for example.)