New Proposals
Process for proposing changes to the core that are either large or dramatic:
- Submit an RFC as a Trac ticket (and wiki page)
- Discuss viability and implementation plan prior to bulk of coding
- Submit patches that are limited in size and scope
- How do we review patches?
Comment Martijn: Patches should be sent to the mailinglist, and at least one person should review them.
- Are we only interested in proposals that are inline with our own roadmap? Are we accepting of proposals that don't interfere with our roadmap, but may apply to use cases we don't particularly care about or even fully understand?
Comment Martijn: features that are not inline with our roadmap can and should be done as a plugin. We can always add new hooks if they turn out to be necessary. In order to prevent bloat and keep core lean & mean, it's important to pollute it as little as possible.
See also the mozilla charter: http://www.mozilla.org/projects/firefox/charter.html Quote:
Develop and maintain an extension system to allow for research into new areas without affecting the core and to allow for techies, early adopters, web developers and other specific communities to customize their browsers to suit their specific needs without affecting usability or download size for the mass market.
and
Retaining a tight command and control hierarchy. UI design is not a committee driven process.
- Is the governance we have now a "benevolent oligarchy"? Is this what we want, for now, for the long-term? For example, do we want a voting system?
Comment Martijn: Voting should always be a last resort, it's much better to make decisions based on consensus. See also "Producing Open Source Software", chapter 4.
New Committers
- How do we decide who get's commit rights? After a certain amount of time and number/quality of contributions?
Comment Martijn: Indeed. Also this decision should be made based on consensus, on a case-by-case basis.
