Constitution

[Casper Hornstrup]

I have looked at the successful Debian project for inspiration
on how to make decisions in a large distributed project like
ReactOS. I have drafted a constitution for the ReactOS project
which is similar to the Debian project constitution. You may
find it here: http://www.reactos.org/wiki/index.php/Constitution.

The constitution explains the decision making entities, their
abilities and the decision making processes of the ReactOS
project.

Feel free to comment, suggest changes, etc.

Casper

[Brian Palmer]

I like it...

-Brian

-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
Behalf Of Casper Hornstrup
Sent: Sunday, October 16, 2005 1:32 PM
To: 'ReactOS Development List'
Subject: [ros-dev] Constitution


I have looked at the successful Debian project for inspiration
on how to make decisions in a large distributed project like
ReactOS. I have drafted a constitution for the ReactOS project
which is similar to the Debian project constitution. You may
find it here: http://www.reactos.org/wiki/index.php/Constitution.

The constitution explains the decision making entities, their
abilities and the decision making processes of the ReactOS
project.

Feel free to comment, suggest changes, etc.

Casper


_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[Ge van Geldorp]

>   From: Casper Hornstrup
>  
>  I have looked at the successful Debian project for 
>  inspiration on how to make decisions in a large distributed 
>  project like ReactOS. I have drafted a constitution for the 
>  ReactOS project which is similar to the Debian project 
>  constitution. You may find it here: 
>  http://www.reactos.org/wiki/index.php/Constitution.
>  
>  The constitution explains the decision making entities, their 
>  abilities and the decision making processes of the ReactOS project.
>  
>  Feel free to comment, suggest changes, etc. 
Looks good. A few comments:

The Registered Project Members can (by General Resolution) override any
decision made by the Project Coordinator or the Area Coordinators. However,
the Repository Coordinator and Project Secretary can make decisions
"preferably consistent with the consensus of the Project Members". It seems
to me that Registered Project Members should be able to override their
decisions too.

There is a mandatory 1 week discussion period and 1 week voting period for
each vote, with no escape clause. For some votes (whether to release or not
comes to mind) 2 weeks seems a bit long. Can we change it so that the
proposer can ask for shorter periods, with a safeguard that the shorter
periods will be denied if a single Registered Project Member objects?

I really would like Coordinator Elections to be secret (or private, not sure
what the correct English term is). I should be able to cast my vote without
the candidates knowing on who (or even if) I voted. I believe this should be
explicitly mentioned in the Coordinator Elections voting procedure.

Ge van Geldorp.

[Royce Mitchell III]

I think we should consider term limits to the coordinator positions.

I can think of two ways to do it:

1) no one can hold a single coordinator position for more than 2 years. 
After which he/she must take at least a one year break from *that* 
position before he/she can run again.

2) no one can hold any coordinator position for more than 2 years. After 
which he/she must take a break from coordinating all-together before 
he/she can run for a coordinator position.

Personally, I think #1 would be sufficient, but thought I'd present #2 
for completeness sake.

[Brian Palmer]

I wouldn't mind coordinator term limits. But I think that as long as the
coordinators are elected then there should be no mandatory "break". If they
get re-elected it's probably because they did a good job and deserve to be
re-elected.

-Brian

-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
Behalf Of Royce Mitchell III
Sent: Sunday, October 16, 2005 10:09 PM
To: ReactOS Development List
Subject: [ros-dev] Coordinator Term Limits

I think we should consider term limits to the coordinator positions.

I can think of two ways to do it:

1) no one can hold a single coordinator position for more than 2 years. 
After which he/she must take at least a one year break from *that* 
position before he/she can run again.

2) no one can hold any coordinator position for more than 2 years. After 
which he/she must take a break from coordinating all-together before 
he/she can run for a coordinator position.

Personally, I think #1 would be sufficient, but thought I'd present #2 
for completeness sake.

_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[Casper Hornstrup]

I agree that there should be no mandatory "break". What if someone
really good at a job couldn't be elected due to this rule and none
else would want it or there was only persons left which were really
bad at the job?

As the project grows there will be more coordinators. We could end
up in election hell. IMO, giving any Registered Project Member the
right to call for an election at any time, should be enough.

Casper

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of Brian
> Palmer
>  Sent: 17. oktober 2005 07:18
>  To: 'ReactOS Development List'
>  Subject: RE: [ros-dev] Coordinator Term Limits
>  
>  I wouldn't mind coordinator term limits. But I think that as long as the
>  coordinators are elected then there should be no mandatory "break". If they
>  get re-elected it's probably because they did a good job and deserve to be
>  re-elected.
>  
>  -Brian
>  
>  -----Original Message-----
>  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
>  Behalf Of Royce Mitchell III
>  Sent: Sunday, October 16, 2005 10:09 PM
>  To: ReactOS Development List
>  Subject: [ros-dev] Coordinator Term Limits
>  
>  I think we should consider term limits to the coordinator positions.
>  
>  I can think of two ways to do it:
>  
>  1) no one can hold a single coordinator position for more than 2 years.
>  After which he/she must take at least a one year break from *that*
>  position before he/she can run again.
>  
>  2) no one can hold any coordinator position for more than 2 years. After
>  which he/she must take a break from coordinating all-together before
>  he/she can run for a coordinator position.
>  
>  Personally, I think #1 would be sufficient, but thought I'd present #2
>  for completeness sake.
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of Ge
> van Geldorp
>  Sent: 16. oktober 2005 23:56
>  To: 'ReactOS Development List'
>  Subject: RE: [ros-dev] Constitution
>  
>  Looks good. A few comments:
>  
>  The Registered Project Members can (by General Resolution) override any
>  decision made by the Project Coordinator or the Area Coordinators. However,
>  the Repository Coordinator and Project Secretary can make decisions
>  "preferably consistent with the consensus of the Project Members". It seems
>  to me that Registered Project Members should be able to override their
>  decisions too. 
[CSH] Right. How about changing:
* Override any decision made by the Project Coordinator or Area Coordinator. 
* Appoint or dismiss the Project Coordinator or Area Coordinator.

to
* Override any decision made by the Project Secretary or any Coordinator.
* Appoint or dismiss the Project Secretary or any Coordinator.

>   There is a mandatory 1 week discussion period and 1
> week voting period for
>  each vote, with no escape clause. For some votes (whether to release or not
>  comes to mind) 2 weeks seems a bit long. Can we change it so that the
>  proposer can ask for shorter periods, with a safeguard that the shorter
>  periods will be denied if a single Registered Project Member objects? 
[CSH] I thought of having a "quick vote" for decisions which are needed here
and now (like whether or not to release now) and not necessarily need to be
documented anywhere else than the mailing lists for future reference, but how
would you define the two?
Maybe we could allow the Registered Project Member that calls for the vote to
choose any number of days of voting period less than 7 days, but at least 2?
days and no discussion period? Any Registered Project Member already has the
right to demand a revote at any time (maybe there should be some protection
from abuse of that right? One could spam until he/she gets what he/she wants).

>   I really would like Coordinator Elections to be secret
> (or private, not sure
>  what the correct English term is). I should be able to cast my vote without
>  the candidates knowing on who (or even if) I voted. I believe this should be
>  explicitly mentioned in the Coordinator Elections voting procedure.
>  
>  Ge van Geldorp. 
[CSH] We haven't done secret elections before. I could go
either way. If it's
secret then you put a lot of power into one person, the person that collects
the votes (most likely the Project Secretary). What procedure would you suggest?

Casper

[Ge van Geldorp]

>   From: Casper Hornstrup
>  
>  [CSH] Right. How about changing:
>  * Override any decision made by the Project Coordinator or 
>  Area Coordinator. 
>  * Appoint or dismiss the Project Coordinator or Area Coordinator.
>  
>  to
>  * Override any decision made by the Project Secretary or any 
>  Coordinator.
>  * Appoint or dismiss the Project Secretary or any Coordinator. 
Yes, sounds fine to me.

>   [CSH] I thought of having a "quick vote" for
> decisions which 
>  are needed here and now (like whether or not to release now) 
>  and not necessarily need to be documented anywhere else than 
>  the mailing lists for future reference, but how would you 
>  define the two?
>  Maybe we could allow the Registered Project Member that calls 
>  for the vote to choose any number of days of voting period 
>  less than 7 days, but at least 2? days and no discussion period?
>  Any Registered Project Member already has the right to demand
>  a revote at any time 
I don't think it's necessary to define a "quick" and a "full"
vote in the
constitution. In practice, I expect little confusion about this, it is
usually obvious. And like you said, it can always be "fixed" by a revote. I
think the 7 day periods should be mentioned, like they are now, to emphasize
that they are the preferred periods. Add a clause which states that the
Registered Project Member calling the vote can specify different periods in
his call for vote.

>   (maybe 
>  there should be some protection from abuse of that right? One 
>  could spam until he/she gets what he/she wants). 
Looks like an extreme case to me, so extreme measures are warranted too:
there's the option of unregistering the project member.

>   [CSH] We haven't done secret elections before. I
> could go 
>  either way. If it's secret then you put a lot of power into 
>  one person, the person that collects the votes (most likely 
>  the Project Secretary). What procedure would you suggest? 
No, we haven't done this before, and I didn't like it...
How about the Project Secretary nominates a neutral vote counter (can be
anyone, Registered or Unregistered, including the Project Secretary himself)
which all the candidates have to affirm? Can be done in private emails
between Project Secretary and candidates. That should ensure the neutrality.

Ge van Geldorp.

[Freworld]

Perhaps we should vote on the website rather than on the mailinglist? 
The mailinglist could be used for the discussion about what exactly the 
vote will be and to make the vote public with a link (most people don't 
look at the website but at the mailinglist). With the new login system 
it would be no problem to control that only committers can vote. This 
way we would have a clean overlook what decisions were taken and what 
was decided exactly.

If there is an interest in this I would implement it into the website.

Greetings
Michael

Casper Hornstrup wrote:

>    
>
> >  -----Original Message-----
> > From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of Ge van
> > Geldorp
> > Sent: 16. oktober 2005 23:56
> > To: 'ReactOS Development List'
> > Subject: RE: [ros-dev] Constitution
> >
> > Looks good. A few comments:
> >
> > The Registered Project Members can (by General Resolution) override any
> > decision made by the Project Coordinator or the Area Coordinators. However,
> > the Repository Coordinator and Project Secretary can make decisions
> > "preferably consistent with the consensus of the Project Members". It seems
> > to me that Registered Project Members should be able to override their
> > decisions too.
> >     
> >  
> [CSH] Right. How about changing:
> * Override any decision made by the Project Coordinator or Area Coordinator. 
> * Appoint or dismiss the Project Coordinator or Area Coordinator.
>
> to
> * Override any decision made by the Project Secretary or any Coordinator.
> * Appoint or dismiss the Project Secretary or any Coordinator.
>
>   
>
> >  There is a mandatory 1 week discussion period and
> > 1 week voting period for
> > each vote, with no escape clause. For some votes (whether to release or not
> > comes to mind) 2 weeks seems a bit long. Can we change it so that the
> > proposer can ask for shorter periods, with a safeguard that the shorter
> > periods will be denied if a single Registered Project Member objects?
> >     
> >  
> [CSH] I thought of having a "quick vote" for decisions which are needed here
> and now (like whether or not to release now) and not necessarily need to be
> documented anywhere else than the mailing lists for future reference, but how
> would you define the two?
> Maybe we could allow the Registered Project Member that calls for the vote to
> choose any number of days of voting period less than 7 days, but at least 2?
> days and no discussion period? Any Registered Project Member already has the
> right to demand a revote at any time (maybe there should be some protection
> from abuse of that right? One could spam until he/she gets what he/she wants).
>
>   
>
> >  I really would like Coordinator Elections to be
> > secret (or private, not sure
> > what the correct English term is). I should be able to cast my vote without
> > the candidates knowing on who (or even if) I voted. I believe this should be
> > explicitly mentioned in the Coordinator Elections voting procedure.
> >
> > Ge van Geldorp.
> >     
> >  
> [CSH] We haven't done secret elections before. I could go either way. If
> it's
> secret then you put a lot of power into one person, the person that collects
> the votes (most likely the Project Secretary). What procedure would you suggest?
>
> Casper
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>   
>

[Royce Mitchell III]

Freworld wrote:

>   Perhaps we should vote on the website rather than on
> the mailinglist? 
>  The mailinglist could be used for the discussion about what exactly 
>  the vote will be and to make the vote public with a link (most people 
>  don't look at the website but at the mailinglist). With the new login 
>  system it would be no problem to control that only committers can 
>  vote. This way we would have a clean overlook what decisions were 
>  taken and what was decided exactly.
>
>  If there is an interest in this I would implement it into the website.
>  
I like the idea, and was actually thinking of suggesting it, myself. 
Also, some have expressed an interest in private voting for coordinator 
elections, which would be easier with web-based voting.

[Preben Christensen]

Hello,

I've been following the project for some time.

It seems like a lot of the discussion going on lately has been about large 
commits.

Why not write into the constitution that commits over a certain size or 
complexity should be commit to a branch for open discussion, testing and 
comment before commit to the main branch ?

That way nobody can be surpriced over a major rewrite or the like.

Just an idea,
Preben


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.12.2/137 - Release Date: 16-10-2005

[Casper Hornstrup]

I've added the feedback.

* The Registered Project Members may override any decision made by the
Project Secretary or any Coordinator. 
* The Registered Project Members may appoint or dismiss the Project
Secretary or any Coordinator. 
* Optional discussion period.
* 2 to 21 days voting period.
* Secret voting at elections.

http://www.reactos.org/wiki/index.php/Constitution

Casper

[Casper Hornstrup]

I've changed it to conform to the new voting method.
Are there any more comments before we vote on it?

http://www.reactos.org/wiki/index.php/Constitution

Casper

[Royce Mitchell III]

Casper Hornstrup wrote:

>  I've changed it to conform to the new voting
> method.
> Are there any more comments before we vote on it?
>
> http://www.reactos.org/wiki/index.php/Constitution
>
> Casper
>
>   
>  
You ( I think ) and a couple others have listed more details and/or 
requirements for the Project Coordinator position. Should these extra 
things be added now, or do we want to get the basic constitution in 
before discussing more details?

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of Royce
> Mitchell
>  III
>  Sent: 24. oktober 2005 19:51
>  To: ReactOS Development List
>  Subject: Re: [ros-dev] Constitution
>  
>  Casper Hornstrup wrote:
>  
> >  I've changed it to conform to the new voting
> > method.
> > Are there any more comments before we vote on it?
> >
> > http://www.reactos.org/wiki/index.php/Constitution
> >
> > Casper
> >
> >
> >  
>  You ( I think ) and a couple others have listed more details and/or
>  requirements for the Project Coordinator position. Should these extra
>  things be added now, or do we want to get the basic constitution in
>  before discussing more details? 
I believe you refer to more specific responsibilities that will change more
often than something as basic as project member rights and decision making
processes. We should put those in a coordinator description for each
coordinator position in wiki so there is no doubt about what the job
entitles.

Casper

[K McI]

Casper Hornstrup wrote:
>   Maybe we could allow the Registered Project Member
> that calls for the vote to
>  choose any number of days of voting period less than 7 days, but at least 2?
>  days and no discussion period? Any Registered Project Member already has the
>  right to demand a revote at any time (maybe there should be some protection
>  from abuse of that right? One could spam until he/she gets what he/she wants). 
I would also suggest some sort of limitation to amount of times a revote 
on any one certain thing could be called? Like, if a certain question is 
called 3 times in a row within a month and a half of each other, that 
question is banned from recurring for at least a few months or a year 
unless some supermajority requests it be called again.

           -uQ