Re: Arabeyes Charter Proposal

[Mohammed Elzubeir <elzubeir at arabeyes dot org>]

On Wed, Mar 13, 2002 at 12:29:15PM +0100, Chahine M. Hamila wrote:

> > >     - Coordinate work with Mirror Administrators
> >
> > * That seem to be more related to the general coordinator responsabilities
> > and he/she knows the technical details that the mirror admins will work and
> > ask for

All mention of mirrors should not be part of a charter. If this is a
desired thing (and I can certainly see it as important), it should be an
item on the agenda, discussed, voted on, and then implemented. However,
the charter does not need mention of mirrors or as such.

> > * suggest emailing core (or core members) instead of GC, as it is a public
> > voting system.
> 
> yes, just left it for flexibility. In any case, the vote is defiitely public, so
> even if one sends his vote to the GC, the votes must be attributed publicly by
> name of course. I would keep this part as 'usage' for flexibility reasons, and
> to let time decide of the best way to tune it.

I don't think it matters. Like the above says, the votes will eventually
be made public, so it doesn't matter. This is simply to reduce noise in
the core list.

> > what about
> > having an odd number of core members, this way a tie would only happen if a
> > member declines to vote .. and that won't happen often
> 
> Maybe, but it would work anyway. In any case, before we become odd, there should
> be a change in the core team which I don't see coming right now;)

Inclusion of new core members should fulfill a specific need and a
position. Balancing the number (to odd) is not a good enough reason
(IIRC, I wanted to include a new member because of that reason and
someone pointed out that they must have a specific need first).. and I
agree.

> > * if 50% of the core members wanted to discuss an already set rule, or
> > desision that should be OK and fine ..
> 
> I meant it in relation to the public, not within core itself. Of course,
> discussing an issue can't be prevented within core, though voted decisions take
> effect as soon as they pass.
> 

Core is only 4. If 2 members wanted to revoke an already voted on issue,
then we would end up in an infinite loop ;) I suggest upping that to
3:4. In reality, if we voted on an issue already, there should be no
need to go back to it again to change it.

> > * possible votes are : Yes, No, pass(decline to vote) .. one should have the
> > right to decline voting.
> 
> Yes.

And with that, I may point out that even w/ an odd number, the
possibility of a tie still exists (re: parting vote).

> > * This whole point is not needed .. is not a general rule or case .. it is
> > very specific ..
> 
> It is on the contrary very much needed. Inclusion of a new member can jeopardize
> the whole project if done lightly, so it must be a certain decision, and in some
> time, if an opposition within the core team can become threatening enough for
> the stability of the team a way to fix that, in the worst cases that radically,
> is needed. The stability of the whole project requires a minimal concessus among
> the people who run it.

I tend to agree w/ Chahine here. The reason I initially liked the
unanimous vote for Core inclusion was to ensure the harmony of the core
team (as to, no members others did not want). However, it does not
consider the good of the project overall, in the case of a
stubborn/emotional/non-rational member. In general, this is an unlikely
scenario, but a charter should be written considering that people are
not always going to be rational ;)

> 
> > Things that should be also considered in the addition of the
> > new member are: 1) previously notifing the member in discussion about the
> > proposal of adding him to core, no need to discuss that person if he
> > doesn't/can't  one to be in core for any reason.
> 
> That's where "to answer specific needs" comes.

Specifics don't need to be in the charter. 

> > * the election secion lacks alot of definition about who can elect, who can
> > get nominated, how , and so ..
> 
> Candidates are within core, voters are core members. It is flexible enough for
> now to be left as is, part of 'usage'. If the org grows to the point of needed
> some explicitly procedural way, we will change this charter.

I am not in favor of making it so 'we will change this charter'. A
charter should last a good amount of time. If changes need be done, then
they get amended to it.

> Now, I will make the changes keeping in mind what you mentionned:) but I'm
> waiting to hear for at least one of the two other core members to answer before
> we can consider it passed then:)
> 

Otherwise (other than the specifics of mirrors/backups/and other
technical details), this charter sounds much saner than 
using the 'manifesto' (which is an overview of the project) to govern
the way by which we do things.

Later
-- 
-------------------------------------------------------
| Mohammed Elzubeir    | Visit us at:                 |
|                      |  http://www.arabeyes.org/    |
| Arabeyes Project     | Homepage:                    |
| Unix the 'right' way |  http://fakkir.net/~elzubeir/|
-------------------------------------------------------