WordPress.org

Codex

Development Planning

The WordPress community often has ideas about the future direction of WordPress. Many proposal are mailed to the wp-hackers mailing list, where the developers discuss the features and develop them into specifications.

Contents

Goal

The goal of this page is to facilitate collaboration on feature specifications.

Currently, many feature requests remain as mailing list debates, where status isn't tracked, and specification refinement doesn't occur. Part of the problem is that it's difficult to keep track of who has requested what, what things have already been discussed into the ground, and what the latest status of a potential feature is.

Process For Feature Requests

This describes a process for feature requests. Note that not all features will follow this process. Rather, this provides a set of steps that someone can use to request an enhancement to WordPress to maximize the odds that the feature will be implemented.

Research The Idea

If there is an enhancement you'd like to see in WordPress, your first step should be to do a little research. In particular, see if someone else has already had the idea, and if so, help them through this process (or take over if they are stalled). Places to search:

Discuss The Idea

Now that you're convinced you have a truly novel idea, your next step should be to discuss your idea with the development community. Bounce the idea off of other developers on IRC and/or the wp-hackers mailing list.

Log Your Idea

It's very easy for an idea to fall through the cracks if you rely solely on mailing lists or IRC. A quick way to make sure your idea is on record is to list it on this wiki. List your idea below, or on the page for the upcoming version of WordPress.

File a Feature Enhancement in Trac

If you really want to make sure that your idea doesn't fall through the cracks, the best way to inject your idea into the planning process is to file a ticket in the Trac bug tracker (big bonus points for including a patch!). Be sure to flag the enhancement as an "enhancement" using the "Type" field, and be sure to follow the bug submission guidelines. Don't get too worried about the fact that Trac is often referred to as the "bug system". It works very well for feature requests, too.

Write a Formal Proposal

Developers really appreciate clear and well-organized specifications when implementing a new feature. Therefore, if you are requesting a new feature, it's in your best interest to ensure that there is a good specification for it.

A well-written proposal will have the following sections:

Summary 
A concise but complete summary of the feature. A reasonably smart developer should be able to read this and have an 90% understanding of the feature in question without having to read the rest of the specification.
Status 
Who is working on what, and how far along they are. Be sure to include the date in any status proposal. For example:
(June 25, 2005) - Initial draft is posted, and mail has been sent 
to wp-hackers.  See Discussions section for more details
Also, be sure to include a link back to the enhancement request in Trac, and add a comment to the Trac ticket pointing to your proposal. (You did file your feature request in Trac, didn't you?)
Current Behavior 
How the feature currently behaves. If someone stumbles upon your proposal looking for documentation on how a feature currently works, please point them to the right place.
Implementation Strategy 
Details regarding how the feature should be implemented, including specific files/functions to modify, and other design considerations.
Work Estimate 
How much work will this feature require.
Commitments 
List of developers committing to implement this feature, or at least help implement this feature. Should include timeframes and specific activities whenever possible.
Open Items 
Any parts of the specification that are known to be incomplete, and other things left to be considered and acted upon.
Discussions 
Links to mailing list, IRC logs, and other places where this feature has been vetted.

Create a user page for the initial draft of your proposal (example: [[User:Glutnix/Advanced User Permissions System Proposal]]), and put a "{{Proposals}}" template tag in your document.

When there are multiple proposals for the same feature, it's also helpful to have a page that serves as a summary for the feature area. These pages should document "Current Behavior" as well as contain a list of proposals in the area.

Submit a Patch

If you are familiar with PHP and MySQL, and you desire to help in fixing the bugs and issues that exist in WordPress, the most effective way to submit a patch.

Proposals

This section contains a list of development discussions which could evolve into future WordPress features or general improvements.

Feature Area Discussions

These are general summaries of feature areas, and not specific feature proposals, per se. Use these pages to further organize the development of new features, especially when there are multiple proposals that cover the same area: