[haiku-doc] Proposal: Becoming a Team Member
- From: "Niels Reedijk" <niels.reedijk@xxxxxxxxx>
- To: haiku-doc@xxxxxxxxxxxxx
- Date: Tue, 22 May 2007 10:50:42 +0200
Hi guys,
Long message, but those who have been following me on the mailing list
know that I sometimes have difficulty limiting myself ;-). Please read
through all of it before commenting though, this mail's really
important.
I've been thinking on the subject on whether the system of loosely
associated contributors is sufficient, or if we want to be organized
in a more official team structure. In the end, I came to the
conclusion that if I were to donate time to a project like Haiku, I
would want to have some recognition of some sort, and the prospect of
team membership with certain privileges certainly would reward me. I
tried to come up with a clear proposal which outlines clear paths from
contributorship to membership.
All of the following guidelines are born somewhat out of my own
frustrations of becoming involved with the Haiku project. I don't want
to start a discussion on openness (and as dictator I will forbid
anyone to do that based on this e-mail ;-) ), but I think that it's
very difficult to get the sensation of being involved in this project,
which has demotivated me some times. Note that I don't say that it's
actually difficult to get involved, but it's all about the sensation,
because for an outsider, the inner circle of Haiku exists of some
contributors that have been there for ages, resting on a structure
that has been there for ages and that has been deteriorating ever
since - it has not adapted to the needs of the current Haiku project.
I do think that the fact that the only seemingly 'recent' coder is
Hugo Santos (bless him - and Ryan Leavengood as well) somehow shows
the difficulty in finding an opening. I do appreciate all the efforts
from people like Waldemar who try to open up things by creating lists
of easy tasks, or by Koki and the gang that set the Google summer of
code in motion. The latter for me being the proof that there are more
than a dozen people willing to contribute but unable to find a way in
just like me. Anyway, before this turns into a rant, with the API
documentation (and later the user documentation) I want to create a
system that effectively opens up for people to get involved and be
rewarded with membership. In a reference to Benedict Anderson, that
what makes a community is the 'imagined' bond people have, even if
they don't know every other member of that community personally. With
these guidelines I want to give every contributer a position in the
community, in order to create a Haiku Team feeling.
So what do I propose? 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.
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). This is the fairest criterium I could come
up with. 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.
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.
These are the general guidelines which I want to make 'official' to
get this ball rolling. It might go a bit too far into the future
(especially with the coordinator stuff), but I hope it gives a descent
base to start working from. Because at the moment there is no team,
and I don't want to look like a dictator, I propose to have the
following regulations as a sort of 'transitional phase' in place:
○ Until there are three official team members (including myself),
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.
○ I will act as team coordinator until January 1st 2008, or until
there are six (including me) 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 I should be able to participate
if I choose to, regardless of any future policy decisions on whether
or not a coordinator can rerun for his position.
These are the terms which I think are pleasant to work under, and
which will work well for a small number of people, as well as
providing a basis for growth. I do have to note that I have never been
involved in an Open Source project where this kind of structure is
imposed on the participants (Mozilla might be an exception, but that
structure probably is impossible for a mortal being to understand). So
it would be doing something experimental again. But it will be fun.
Kind regards,
Niels
Other related posts:
