User:Toofishes/Arch Linux Project Guidelines
From ArchWiki
This page and set of guidelines is mostly taken from some of the lessons presented in the following video: How Open Source Projects Survive Poisonous People. If you haven't seen it already, it is well worth a watch (you can get away with just listening though).
Some of the projects these guidelines should apply to:
Contents |
[edit] Basic Project Requirements
[edit] Define a mission statement
Yes, this sounds a bit corny, but it should be done. As presented in the video and on their website, the mission statement for SVN is simple and concise: The goal of the Subversion project is to build a version control system that is a compelling replacement for CVS in the open source community.
Each Arch Linux project should have a mission statement that attempts to encompass what it will accomplish- no more and no less. This will keep development focused on what is important, and keep feature bloat from happening, which is very important if we want to KISS.
[edit] Document your projects
This is something that is currently lacking in many of the ongoing Arch Linux Projects.
(TODO - a lot more from here on down)
[edit] Design decisions
[edit] Major features
[edit] Bug fixes
[edit] Mistakes
[edit] Effectively Managing Projects
[edit] Keep a readable ChangeLog
[edit] Use commit emails
(maybe an RSS feed of sorts could work for smaller projects without their own ML)
[edit] Use branches for large changes
[edit] Lower barriers to project entry
[edit] Keep names out of source files
[edit] Have well-defined processes
[edit] Stay focused
look at mission statement, don't be fooled by 'bugs'
[edit] Example Projects
Project: pacman
Mission Statement: To be a simple package manager with dependency, provision, and conflict support that is intuitive to use.
Project: AUR
Mission Statement: A site where Arch Linux community members can freely share packages with others.