Re: Arabeyes Charter Proposal

["Chahine M. Hamila" <mch at chaham dot com>]

Salaam,

Isam Bayazidi a *crit :

> <snip>
> >
> > Roles and Responsibilities
> > of the Core Team
> > --------------------------
> >
> >   General Coordinator
> >     - Coordinate with core team
>
> * What does that mean ?

That means he generally gets all other particular coordination reponsibilities
equally, like I10N, PR, RnD, etc...

> >
> >   Public Relations and Recruitment
> >     - Enhance Arabeyes’ image and prestige
>
> * prestige ... clearification please ..

To be taken seriously by the industry, by big projects and by standardization
commitees, we need prestige, i.e. considered to be folks who solidly know what
they're doing and who are better than others when it comes to doing a good job,
things like that. Thing that would make people naturally consider us references
and would naturally refer to us like some authority. This is REALLY important
because otherwise, we end up in an XFree86 like situation where the guys look
down upon us and do not even repond to our minimal requests. Kind of the
'positive, noble' image a good marketing and a good work should give us.

>
>
> >     - 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

Right. Moving it to the GC's role. And removing the mention of mirror
administrators in the charter as this is just a technical aspect of this point.

> > Policy Proposal Procedure
> > -------------------------
> >
> >   1. Write formal proposal
> >   2. Add item to meeting agenda
>
> * As the general coordinator is acting as a secratery for the meetings
> (preparing agneda, setting time and so) I suggest that adding a new item to
> the meeting agenda would be thourhg the GC, notify the GC about adding a new
> item, if the time permits it will be rolled in, if not booked for next
> meeting ..

Yes, seems fine to me.

>
> >   3. Give one to two weeks for discussion (via core mailing list)
> >   4. Schedule a voting deadline and render votes
> >
> >
> > Voting Procedures
> > ----------------
> >
> >   All votes will be rendered during a the core team meetin. If a member
> >   is unable to attend, they may email the GC with their vote(s).
>
> * 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.

> >
> > A. Basic rules
> >    1. In the event of a tie, the General Coordinator invokes a parting
> > vote.
>
> * does that mean that the GC got the final word in case of tie ?

Yes, we need some system to avoid paralisy. This is better than a veto system
that adds paralisy more than it solves it.

> 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;)

> >    2. No one can be individually forced to do whatever he doesn’t want
> > to.
> >    3. Decisions made by the Core Team are not discussable, even when
> > they might appear arbitrary or unjustified. People can politely ask for
> > clarifications or make suggestions, and it will be at the Core Team’s
> > discretion to answer or not, or even forbid any discussion about it.
>
> * 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.

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

Yes.

>
> > C. Inclusion of a new member in the core team:
>
> * that should be section D.

right.

> >   1. Inclusion of a new member in the core team will be proposed to
> > answer specific needs.
> >   2. This procedure cannot succeed without the presence AND a favorable
> > vote by 3/4 of the core team.
> >   3. If a member of the core team puts his own membership in the balance
> > against the inclusion, a vote according to rules B will have to take
> > place. If the vote succeeds, the successful inclusion by a following
> > vote according to rule C.2 of the new member will automatically exclude
> > the subject of the first vote. If this first vote fails, the inclusion
> > procedure aborts.
>
> * 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.

> 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.

> 2) asking this person to
> write a short brief to identifiy him/her self.

We can keep this one as 'usage', in order to avoid unnecessary bureaucracy when
we all know the person to be included for example.

>
> >
> > D. Exclusion of a core member:
>
> * that should be secion E.
>
> >   A successful vote undertaken according to rules B is enough for
> > excluding a member.
>
> * So excluding members are easier than including ones! inclusion requires
> 3/4, while exclusion requires majority!

Yes, again, the point is to maintain as much cohesion as possible within the
core team. For example, you can afford losing a minority of members if you think
the gain is worth it (case of inclusion for example). You cannot in any case
afford losing half the core (case of people reaching a n extremely conflictual
point within core for example). So maintaining the cohesion of core must be easy
and safe.

>
> * I see this conficting with Section D ( was C), why elect when you can
> include members, why include when you can elect. See ?

Elections are done within core, inclusions are changes to core.

>
> * 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.

>
> >
> > Annex:
> >
> > - Proposed coordinators for the years 2002-2003 and following until next
> > explicit vote:
>
> * As we where not elected, we are the foundation group.. no need to set time
> (2002-2003) becuase who knows when Arabeyes would be ready for such a move

No prob, we are flexible, hence the 'tacit' reconduction btw. Let's say that,
unless one of us here wants an explicit vote now, we will consider it to be
'tacitly' voted for the next two years at least, and it will only be voted again
if explicitly asked for later, as mentioned in the elections procedure.

That said, I would like to mention that 'founding' member should have no value
whatsoever. Suppose for example I decide to take my distances with Arabeyes,
and  a guy named Bashir replaces me on the RnD function? Why would I have any
right to poison Bashir's life when he's the one doing the work and I am not? See
the point? foundation is, at best, honorific. It is the folks who are making
Arabeyes run *at the moment* who count.

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:)

Salaam,
Chahine