Re: Arabeyes Charter Proposal

[Isam Bayazidi <bayazidi at arabeyes dot org>]

fSalam, 

Here is my comments on the proposal which in general seems to be fine, my 
commants begins with *:

On Tuesday 12 March 2002 10:37 pm, Chahine M. Hamila wrote:
> Arabeyes Charter
> ================
>
>
> Roles and Responsibilities
> of the Core Team
> --------------------------
>
>   General Coordinator
>     - Coordinate with core team

* What does that mean ?

>     - Maintain the site, cvs, bug tracker, etc.
>     - Resolve conflict, should they arise
>     - Maintain meeting minutes and agendas
>     - Moderate meetings and schedules
>
>   Localization Coordinator
>     - Manage translation teams
>     - Set priorities and deadlines
>     - Coordinate with related i18n coordinators of other projects
>
>   Public Relations and Recruitment
>     - Campaign educational institutions and rally for support
>     - Recruit new volunteers into the project
>     - Represent Arabeyes in public and to the media
>     - Initiate external contacts with companies and other projects
>     - Serve as mentor to new members of the project
>     - Enhance Arabeyes’ image and prestige

* prestige ... clearification please ..

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

>
>   Research and Development Coordinator
>     - Coordinate development projects to ensure harmony and
>       staying in focus
>     - Set development priorities and deadlines
>     - Serve as liaison to technical committees and standardization
>       organizations
>     - Define the research directions
>
> Are not necessarily part of the Core Team:
>
> Mirror Administrators:
>     - Mirror the Arabeyes Website and resources in different
> geographical locations
>     - At least two are necessary
>
> Core Collective Responsibilities
> --------------------------------
>
>   - Approve individual project licenses
>   - Coordinate external relations
>   - Motivate volunteers
>   - Propose and implement policies (technial and otherwise)
>
>
> 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 ..

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

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

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

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

>
> B. General decisions:
>
>   1. General decisions are taken by simple majority votes.
>   2. All non explicitly written voting exceptions will abide by this
> section.
>
> C. Project decisions:
>
>   Project decisions are essentially taken by each Project Coordinator
> within a system he manages in the frame of the project he manages.
>   Core Votes as in B.1 take precedence over Core Coordinators’s
> decisions which in turn take precedence over the project coordinator’s
> decisions. An exception is when the project is owned by the coordinator,
> i.e. the project coordinator is the main author, in which case rule A.2
> applies.
>
> C. Inclusion of a new member in the core team:

* that should be section D.

>   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 .. 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. 2) asking this person to 
write a short brief to identifiy him/her self.

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

>
> E. Core Coordinators elections:

* that should be section F.

>   Elections of Core Coordinators abide by rules B.
>   Core Coordinators are tacitly reconducted every two years unless a
> core member expresses will for an explicit vote.
>    Elections are also triggered by changes in the Core Team.

* I see this conficting with Section D ( was C), why elect when you can 
include members, why include when you can elect. See ?
* the election secion lacks alot of definition about who can elect, who can 
get nominated, how , and so ..


> F. Project Coordinators:

* Should be section G.

>    Are first nominated according to rules B.
>    A Project Coordinator can set the rules of functionning of the
> project as he sees fit, including nominating another project
> coordinator. This last initiative though would have to go through the
> approval of the Core Team.
>
> G. Licenses

* Should be section H.

>   License are accepted on a case per case basis according to a vote by
> rules B.
>
>
> 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

>
> Mohamed Elzubeir : General Coordinator
> Isam Bayazidi : L10N Coordinator
> Nadim Shaikli: Public Relations and Recruitment
> Chahine Hamila: RnD Coordinator
>
> - There will most probably be unwritten usage over time. Though it is
> important to follow such practices, none of them will be considered
> mandatory unless validated, by vote or by plebiscit, as a a written part
> of this charter.

-- 
Yours,
Isam Bayazidi
Amman - Jordan
====================================================
 Think Linux + Think Arabic = Think www.arabeyes.org
====================================================