1. Code
1.1. Source Code
1.1.1. Following conventions
1.1.2. README
1.1.2.1. Overview of project
1.1.2.2. License name
1.1.3. Copy of full license in COPYING
1.2. Standard installation procedure
1.3. Copy of the documentation in one file
2. Looks
2.1. Enough investment into presentation that newcomers can get past the initial obstacle of unfamiliarity
2.2. Lower hacktivation energy
3. Name
3.1. Descriptive
3.2. English
3.3. Unused
3.3.1. Other projects
3.3.2. Trademarks
3.4. .org
4. Site
4.1. Mission statement
4.2. State "free" and license under mission statement (link to it)
4.2.1. MIT = ok in proprietary
4.2.2. GPL = not ok in proprietary
4.3. Features
4.3.1. Mark those in progress
4.4. Requirements
4.5. Development status
4.6. Code
4.6.1. Downloadable
4.6.2. Source Control
4.7. Bug tracker
4.7.1. Visible from front
4.7.2. Can be loaded, that's actually good
4.8. Communication channels
4.8.1. Types
4.8.1.1. etc.
4.8.1.2. Forums
4.8.1.3. IRC Channels
4.8.1.4. Chatrooms
4.8.1.5. Mailing List
4.8.2. Make it clear you are following to receive feedback
4.9. Developer Guidelines
4.10. Documentation
4.10.1. User
4.10.1.1. How to set it up
4.10.1.1.1. Which skills are needed
4.10.1.2. Overview of how it works
4.10.1.3. Guide to doing common tasks
4.10.1.3.1. Tutorial style
4.10.2. Technical
4.10.2.1. Label incomplete areas as incomplete
4.10.2.2. Known deficiencies / issues
4.10.2.3. One page version
4.11. FAQ
4.11.1. Don't pre-build it
4.11.2. Grow it according to real questions
4.12. Goal: create culture and set precedents
5. Communications
5.1. Avoid private discussions
5.1.1. Steer private discussions to the public sphere
5.2. Nip rudeness in the bud
5.2.1. On mixed issues (personal attack + technical criticism) deal with it as two issues with the ad hominem first
5.2.1.1. Don't demand apologies
5.2.1.2. Don't demand acknowledgements
5.2.1.3. Don't restrict bad apples from technical tools
5.3. Conspicuous code reviews
5.3.1. Public reviews
5.3.2. Mechanisms that invite reviews
5.3.2.1. Ex: commit e-mails