Languages: English • Italiano • (Add your language)
This page was based on some comments made in 2005 to help explain the release and development strategy used by the WordPress developers. These ideals are more recently reflected in the project's Philosophies document.
The team is acutely aware of the importance of painless, error-free upgrades for users of all skill levels. Maintaining this tradition is of prime importance.
Suggested Reading from Ryan Boren on the importance of keeping the number of options to a minimum (and the creation of free software in general):
http://ometer.com/free-software-ui.html
It turns out that preferences have a cost. Of course, some preferences also have important benefits - and can be crucial interface features. But each one has a price, and you have to carefully consider its value. Many users and developers don't understand this, and end up with a lot of cost and little value for their preferences dollar.
- Too many preferences means you can't find any of them.
- Preferences really substantively damage QA and testing.
- Preferences make integration and good UI difficult.
- The point of a good program is to do something specific and do it well.
- Preferences keep people from fixing real bugs.
- Preferences can confuse many users.
I find that if you're hard-core disciplined about having good defaults that Just Work instead of lazily adding preferences, that naturally leads the overall UI in the right direction. Issues come up via bugzilla or mailing lists or user testing, and you fix them in some way other than adding a preference, and this means you have to think about the right UI and the right way to fix problems. Basically, using preferences as a band-aid is the root of much UI evil.
http://mpt.mirror.theinfo.org/discuss/msgReader$173
- First corollary: Every contributor to the project tries to take part in the interface design, regardless of how little they know about the subject. And once you have more than one designer, you get inconsistency, both in vision and in detail. The quality of an interface design is inversely proportional to the number of designers.
- Second corollary: Even when dedicated interface designers are present, they are not heeded as much as they would be in professional projects, precisely because they’re dedicated designers and don’t have patches to implement their suggestions.
http://ometer.com/features.html
Please don't bother flaming maintainers because your feature hasn't gone in yet. Provide better rationale, yes. Randomly flame about the fact that maintainers have to say "no" a lot, no. Design by committee is far, far worse than rejecting a couple of patches. As Linus says, "If you don't get it, don't bother emailing me."
Special bugzilla rule: if you move a bug from WONTFIX or NOTABUG to REOPENED, you had better add additional, quality rationale at the same time. Here's one way to look at it: If you're too lazy to do the homework and think through the big-picture rationale, I'm too lazy to add the feature. On the other hand, patches that come with well-thought-through rationale are often applied right away.
In addition to saying "no", maintainers have a couple of other obligations in my opinion:
- In the presence of good rationale, maintainers should be willing to change their mind often.
- If you want to provide your own patch set or distribution of the software with different features, the maintainer should not complain.
http://ometer.com/hacking.html
- Use the mailing lists. If you have a question, ask on the list.
- No one is in charge. People often expect someone to be in charge of free software projects; or they expect to get an assignment, then have to complete it by a deadline. It just doesn't work that way. You can't control what other people work on, and no one's going to tell you what to work on, though there will probably be plenty of suggestions. You've got to dive in and make something happen.
- Coordinate with others.
- There is no answer to the question, "when will X be finished?" or "will feature X be implemented?" The answer to both questions is "when and if someone does the work." If the someone is you, then you know the answer. If the someone isn't you, then you'll just have to wait and see.
- Learn about the community.