The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
The Features as Plugins model was introduced in 3.7 as the way for features to be developed for inclusion in WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.. 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 pluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. 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 pluginPluginA 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 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 leadRelease LeadThe community member ultimately responsible for the Release. 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.
The user interface/experience has been tested through user testing, and appropriate feedback was incorporated. (Be sure and ask the Design team to review it.)
The design is fully responsive, displaying properly on any mobile device, and using graphics that are ready for hi-dpi/retina displays.
HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. validates to the proper doctype.
The code has all of the proper hooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. in place for localization. (Be sure to ask the Polyglots team to review it.)
The feature can be used with just a keyboard.
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.)