User:Toofishes/Arch Linux Project Guidelines

From ArchWiki

Jump to: navigation, search

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.

Personal tools