Prelude
When we started the PySoy project we wanted it managed by a developer community, rather than one person, to avoid the pitfalls of Soya3D. However, we failed to establish a structure to this proposed democracy which resulted in:
- One or two developers still making most decisions
- New developers joining and unilaterally making design choices which derailed work and often leaving shortly thereafter
- A formation of a clique of developers working outside the public processes to get work done
- An unfavorable barrier to entry for new developers to get involved
We want a community with open doors, giving new developers a formal structure to become experienced developers, and give extra voting weight to the more experienced so the ideas of the ambitious newbies cannot derail others work.
Thus was born the concept of Rank as presented here.
The success or failure of this system will depend on the support of developers, thus we ask all current developers to look over this proposal and voice concerns, worries, or support before we move forward on it.
Rank Levels
Rank 0: Users
PySoy users are a valuable part of our community that we recognise with a formal rank.
Privledges: Users may post ideas and bug reports to the website, contact developers, and attend all-developer meetings.
Limitations: We cannot, however, formally track every PySoy user for voting purposes. Furthermore, offering voting rights to users opens us to the risk of a developer "getting a bunch of buddies together" to swing a close vote. Thus users are not offered voting privledges.
Responsibilities: Users are expected to conduct themselves in a respectful and cooperative manner. On IRC users are expected to follow Freenode's policies. On all communication mediums users are expected to refrain from spam, flames, off-topic discussion, or other forms of obvious abuse. The privledges listed above may be limited or revoked to users who fail to meet these expectations.
Attaining: For the purposes of this document every non-developer is considered a "PySoy user" by default. In a few cases, such as spam blocking, firewalls and bans on blocks of abusive users, etc, legitimate PySoy users may have to request to be acknowledged as such to gain the above privledges (ie, we may have to whitelist a user in a netblock known as a source of spam).
Losing: Any developer (Rank 2+) may revoke a user's access privledges to the PySoy IRC channel(s) for 24 hours. A member of the PySoy Board may revoke access to any user or group of users pending discussion (and possibly voting) by the PySoy Board.
Rank 1: Contributer
Contributing developers have proven their ability to work productivly without a mentor.
Privledges: Subversion access, an @pysoy.org address, access to manage tickets, and #PySoy channel operator status.
Limitations: Contributors may work on any PySoy component but should coordinate non-trivial changes/fixes with that component's Lead.
Responsibilities: Contributors are expected to be catalysts on all forms of communication (IRC, email, website) as their actions reflect the PySoy project and serve as an example for other developers. They are also expected to be active on the mailing list and/or miss no more than 2 consecutive IRC meetings.
Attaining: Users may become a Contributing Developers after an intership period under a Lead Developer. Interns may be given subversion access limited to their mentor's component and limited website access. Internship is complete after a passing Vote for Rank initiated by the Intern's mentor.
Losing: A Contributor may be de-ranked (to Rank 0) by either a majority of the PySoy Board or a 2/3rd majority vote of developers (excluding that Contributor). Developer reduced to Rank 0 may re-join with their mentorship phase refered to as probation rather than internship.
Rank 2: Lead
Lead developers each manage a component of the PySoy codebase. The scope of what they manage is detirmined by the PySoy Board and often changes as new Leads are elected and de-ranked.
Privledges: Administrative access on the website for managing tickets and documentation
Limitations: Set by the PySoy Board for each Lead.
Responsibilities: Lead developers are expected to miss no more than 1 consecutive meeting, manage work being contributed to their component, manage tickets in their component, and maintain active work in their component in addition to contributing to other parts of the codebase.
Attaining: Contributors are nominated by the PySoy Board then voted on by all developers (excluding themselves).
Losing: Leads may be de-ranked (to Rank 1) either by a majority of the PySoy Board or a 2/3rd majority vote of all developers (excluding that Lead).
Rank 3: Director
Each Director is a Lead developer that also occupies a seat on the PySoy Board. Up to 5 Directors make up the PySoy Board. The Board (exclusivly) makes decisions on financial, legal, and branding issues.
Privledges: An additional @pysoy.org address cooresponding to their role, ie, maintainer@….
Limitations: Directors serve for 1 year. Thus, those who do not conduct themselves as representitives of PySoy and properly represent all PySoy developers are unlikely to be re-elected.
Responsibilities:
- Maintainer: Sets policy on source code layout and other cosmetic standards for development, can release security patches and other time-critical releases w/o a vote, manages inter-component API.
- Communications: Serves as a general contact for the PySoy community, schedules/hosts monthly meetings.
- Treasurer: Manage finances, can authorize funds not to exceed 25% of annual budget in any calendar month w/o a vote.
- Marketing: Manage branding, use of funds budgeted for marketing (ie, for Google AdWords), banners, pamplets, and our participation in various events.
- Distribution: Manages the source build environment, binary releases, packaging for distros, and serves as a contact for distros.
Attaining: When a seat is available on the PySoy Board any current Director can nominate a current Lead for that seat. All developers (excluding the canidates being voted on) vote in a Vote for Rank. >50% of "yes" votes is required to take a seat. When one seat is being competed for the canidate each is voted on separately with the highest % of "yes" votes, with the maintainer breaking ties, wins. If all canidates are found unacceptable by a majority vote of all developers the vote may not be conducted again for 30 days.
Losing: A Director may be removed from the Board by a 2/3rd majority vote of all developers (excluding that director). Such a Vote for De-Rank is initiated by 10 nominating votes. Directors also lose rank (back to a Lead) if their term (1 year) ends and they are not re-elected.
Voting
Issues needing a vote are posted as a Trac ticket and, once sufficient nominations are received, the vote is announced to the pysoy-dev list by a member of the PySoy Board. 7 full days, ending on Midnight GMT, is then available for voting. Votes will be collected on the issue ticket and tabulated according to each eligable developer's rank.
Votes for Release are conducted when we're ready to ship a new version (beside releases/patches which only fix security issues). A Director (likely the Maintainer or Distribution Director) creates a tagged release from Trunk for review. Each Lead must sign-off on their component being ready. Leads may commit changes to make it ready which may or may not also be applied to Trunk. A full consensus (no blockers) of Leads must be reached for a release.
Votes for Rank are those to raise the rank of a developer. When multiple developers compete for the same seat the one with the most "yes" votes earns it. The Maintainer serves as tie-breaker. If no Maintainer is available to break a tie the vote is immediatly re-run.
Votes for De-Rank are those to lower the rank of a developer. These require a 2/3rd majority of all developers. For de-ranking a non-director a majority vote of the PySoy Board is also sufficient.
Votes for Change are those which undo, overwrite, or append existing policy. These must be phrased as simple yes/no questions and must receive a majority to pass (default to "no" on a tie).
Votes of Choice are those which multiple options exist which must be voted on (current policy is either void or doesn't cover the proposal). Options are discussed and collected from all developers, then the PySoy Board runs an instant-runoff vote (only directors) on the options nominated by Directors. If two options are tied for elimination the one with the most 2nd choice votes wins. If only 2 options remain and are tied the Maintainer breaks the tie.
Meetings
Meetings are for discussion, not for voting. A rough agenda may be drafted on the wiki but will only serve as a set of guidelines.
Think of a meeting as a social, rather than formal, activity. They are for all of us to get together at once and talk about things covering the entire project. Lead developers may also schedule meetings for their components.
One all-developers meeting should be scheduled each month. Meetings are scheduled and conducted by the Communications Director.
