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.
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.
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.
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:
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.
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.
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.
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:
(June 25, 2005) - Initial draft is posted, and mail has been sent to wp-hackers. See Discussions section for more details
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.
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.
This section contains a list of development discussions which could evolve into future WordPress features or general improvements.
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: