[haiku-doc] Re: Proposal: Becoming a Team Member

I long, complicated read but well worth the time spent reading it. Myself only 
being a relatively recent fan of Haiku that's been keeping an eye loosely on 
OpenBeOS I'm not at a position where I can express judgment of how Haiku is 
being run. What I can do, however, is to express my support of the Contributors 
idea. The reason I'm donating time and effort to Haiku is on completely 
voluntary grounds and I don't expect nor do I want anything for it. Although it 
would be fun to be recognized for my contributions to the project, so that some 
day I can have something to show for my support. It's like when you get schwag 
for being on a project, I still have my "Team Member" t-shirt from Project: 
Looking Glass 3D and it's one of my favorites. Not because it's cool but 
because of what it represents. It's a long-winded way to say it but in short to 
be mentioned as a contributor is a nice feather in the cap for anyone. :)

Cheers
/Dave




----------------------------------------
> Date: Tue, 22 May 2007 10:50:42 +0200
> From: niels.reedijk@xxxxxxxxx
> To: haiku-doc@xxxxxxxxxxxxx
> Subject: [haiku-doc] Proposal: Becoming a Team Member
> 
> 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
> 

_________________________________________________________________
Prova Live.com: här kan du skapa din egen onlinevärld - med nyheter, sport, 
väder och mycket annat.
http://www.live.com/getstarted

Other related posts: