The RPMforge.net project is an independent community-driven project to provide the infrastructure and tools to allow users, developers and packagers to meet and work together to provide and improve RPM packages. As a community we expect participants to underwrite the following rules. Even though some of these are subject to interpretation, common sense in applying these can help work towards a common goal.

• Strive for compatibility with original core and update packages from each distribution
• Will not replace core library (non-leaf) packages from each supported distribution
• Consistency and coherency in how we lay out SPEC files
• Work towards automating as much as possible
• Work together with other similar initiatives in an open and amicable fashion
• The project itself is the main motivation, other interests stay secondary
• In discussions, only voice your opinion if not already voiced by someone else
• In voting, express your rationale for every vote
• Don't flame when people do not agree, everybody is working for the same cause
• We are all volunteers, so keep things light and humourous, allow people to make mistakes

• RPMforge will be a SPEC repository at first and an RPM package repository at some time later. This allows us to focus on policy and procedures before being pressured into everything else that makes up a repository.
• RPMforge is to become a broad repository with enhancements, not replacing core packages. This leaves room for niche repositories that ship their own kernel, glibc or newest Gnome.
• A limited set of packagers will have subversion access. Anyone can suggest new packages at suggest@lists.rpmforge.net, contributors can help out fill in these suggestions by adding SPEC files and links to SRPMs, and packagers will sign off each of these threads. This allows contributors desiring to become packagers to draw positive attention.
• We will introduce the concept of builders and build environments later. In the meantime we encourage people to rebuild our SPEC files and contribute changes for different distributions and architectures within the limits of common sense.

This is an unfinished list of things we plan to do:

• Extend pydar to become a python based system to manage build environment and build packages. Straight-forward for co-testers, adequate for complex needs.
• Tools for distributing builds to server farms.
• Tools for managing repositories and packages.
• Tools for tracking and merging package changes, bugs and feedback from various other community packaging efforts.
• Select trusted builders and packagers and hand out dist/arch combinations