Documentation Team: Membership and Organisational Structure

Contributorship

As soon as you have dedicated your time to the documentation project and have produced at least one accepted patch, you will become a contributor. Contributors will have the following privileges:

In the documentation and on the Haiku Website (on the team page) you will be mentioned as a contributor.
During mailing list discussions and meetings you have the right to vote on issues of documentation guidelines, or other non-policy related issues.

Contributorship lasts until the release of the first version of Haiku R1 (with the Haiku Book R1). After that you will remain credited as contributor to the first release of the Haiku Book, but basically the list of contributors will be emptied and we will start with a new list of contributors for the next major release of the Haiku book. I expect that whenever we reach that moment, there will be a transitional phase designed contributors that just started to work on documentation before the release.

Membership

As soon as you are a contributor, you are on the right track for becoming a team member. To become one, you will have to do comply with two criteria:

Have been active for three consecutive months, starting from the date your first patch is accepted (so essentially from when you are an official contributor). This is to test whether or not you have a certain level of time you can invest in the project. Being active is defined as producing patches, participate in mailing list discussions, coming to meetings, etc.
You will need to have produced at least fifteen accepted patches. The definition of a patch in this sense is to create or update one documentation file (because in the traditional sense, a patch can touch more than one file). Even though some files are very small, I think the fact that someone takes the time to perform the actions are more important than the amount of changes. And having said that, the amount of changes is very difficult to measure in this kind of work. Also note, that there is no difference between technical writers and proofreaders, it all comes down on the numbers.

As soon as you are a team member you will get the following privileges:

In the first version of the documentation you will be credited as team member (even if you decide to leave the team) and you will be listed on the website as a team member.
You will get voting rights on policy issues (administrative and organisational).
You will be nominated for SVN access (which I expect you to get).
You will get editing rights to the WIKI.
You will get the right to accept patches from contributors.
You will be able to get your changes through without any reviews on the mailing list (unless you want to).

These privileges also comes with some duties:

The duty to represent the team when it comes to helping out (potential) contributors.
The duty to remain active to a certain extend. This includes participating in mailing list discussions and meetings, and producing patches.
The duty not to abuse the resources allocated to you (SVN access, administrative access to parts of the website, etc.)

Membership lasts a lifetime (so to say), but it would be appreciated that if for whatever reason you cannot or will not invest time anymore, you will lay down your membership (at which you will be able to regain it at any point of time on your request). You will lose your privileges and your SVN access - unless you are active in another area of development - but you stay on as contributor. As I mentioned, for the first release(s) of Haiku - the complete R1 series - you will be credited as team member in the documentation credits, even if you left the team.

Team Coordinator

The final part of this policy proposal is on the role of team coordinator. For the past few months I've been trying to get this documentation team started, and as such I'm sort of leading the effort right now. Luckily, the creation of an official team will relief me with some of the duties, though I think a position like team coordinator would always be necessary. The duties of a team coordinator would be:

To act as an representative of the documentation team in special circumstances. Any member of the documentation team represents the team, but when it comes to interaction with important parties, such as the administration team or Haiku inc., the coordinator will act as the 'official' voice.
The duty to keep track of contributors and make sure they will be invited to become team members if they comply with the criteria.
The duty to interact with the general release coordinator (as soon as that position is created) to make sure that with the release of a Haiku version, the documentation is up to date and buildable without errors.
The duty to lead meetings, draft up an agenda and write up summaries. These tasks can be delegated to other members, but it's the coordinator's responsibility that each of them are executed.

Coordinatorship lasts until a major release. After that, each of the team members can apply for coordinatorship on the mailing list, after which in an official team meeting, team members can vote for their preferred coordinator. The official procedure should be crafted by the documentation team when the time for a new coordinator is nearing (details such as can a coordinator apply twice, should the voting be anonymous, etc.). The time of major release is defined as the point where a release is done where the number directly after the 'R' changes from the previous release. The idea is that then the 'trunk' will open for the next major version (so when Haiku R1 is released, Haiku R2 will start development), so that the new team coordinator will coordinate the next major release.

The outgoing coordinator will keep a role of coordinating the release in his major revision, so if he was the coordinator for the R1 release, he will still have to make sure R1.1, R1.2, etcetera., are in a good shape.

If a coordinator decides to step down, the nomination and voting process will start over again. If the coordinator needs to leave in a hurry and cannot oversee this process, the most recent previous coordinator will take over this duty, or if there is none, the oldest (as in time of membership) team member will oversee the process. If an outgoing coordinator decides to step down, the current coordinator will either take over his duties, or appoint someone to carry out the tasks.

Transitional Regulations

Because the process of documenting the API has just recently begun, there are some temporary regulations to make this initial phase transition smoothly into a more permanent state. The measures are:

Until there are three official team members (including the current coordinator, Niels Sascha Reedijk), there will be a temporary state of 'aspiring members' to decide on major policy issues. The criteria to become an aspiring member is to produce at least three accepted patches. You can become an aspiring member until there are three members. As soon as there are three members, the aspiring members have three months to become regular members. After those three months, the aspiring membership expires and you become a contributor.
Aspiring members will have the privileges of WIKI access and voting on policy issues. They also will be able to vouch for patches from contributors, but their own patches need to be accepted by team members or get a vouch from other aspiring members.
Niels Sascha Reedijk will act as team coordinator until January 1st 2008, or until there are six (including himself) official team members - whichever comes first. At that point there will be a vote on whether I can keep the role of coordinator for the Haiku R1 release. I will not be able to vote. The majority rules. In the case it is decided that we should enter the process of electing a coordinator, there will be a regular nomination and voting round, in which Niels Sascha Reedijk should be able to participate if he chooses to, regardless of any future policy decisions on whether or not a coordinator can rerun for his position.