Recommandations

The following is a list of recommendations for the management and policy formations of the Arabeyes Project.

Core Management Team

More involvement of Arabeyes members

Recent incidents on the mailing-lists have highlighted the need to involve all members in the formation of Arabeyes policies.

Policy formations

A simple procedure to follow would help alleviate this type of pressure:

1. policy need recognized in a subject area

2. policy drafted by arabeyes member (core or otherwise)

3. policy discussed in forum list

4. policy voted on by core

In other words, in order to "ratify" a policy, a core vote would be needed. This would essentially mean that core would have the right of veto but cannot simply ratify a policy without some sort of consent or discussion among interested Arabeyes members.

Meetings

Core holds weekly meetings (or supposed to), which invite others to sit-ina nd listen. Some people may argue that this is in contradiction of openness and transparency (it is not). It is simply a means to be able to get through an agenda without having too many people talking on IRC.

A good way to get around this is to have every 4th meeting (once a month) an open house meeting, where others are able to freely talk. The agendas would therefor have to be written with that in mind for those "Open House" meetings.

Core Elections

There have been agreement that core members will have to be elected from now on, as Arabeyes has grown mature enough to be able to handle a smooth transition. This would be the final phase of ensuring Arabeyes to be able to sustain itself regardless of the members staying or leaving.

Unfortunately, no concrete steps have been taking in this regard and they need to be done very soon. What is needed is:

1. Amendments to the current charter

2. PHP module to allow for votes based on:

 * person already logged in (ie. member)

 * person is active member (cvs account and committed in past 3 months)

 * anything else that is agreed on

3. A mechanism for people to nominate themselves (or others nominate them)

4. A set date for elections to be held

Delegation

In the past we have met many failures in attempts to delegate tasks from Core to other members. This may be due to the fact that these tasks are rather large ones and are not being 'eased' on. Some of the tasks that can be easier to delegate are ones such as, mailing-lists moderation. It has been noted by Nadim (the current listadmin) that it takes him one hour a day to the routine list moderation work. This is rather unacceptable for one person to have to do and needs to be delegated to different members. Other examples may arise.

Sharing the Load (Youcef)

This is an attempt to organize the core-team's tasks and to share them equally between its members. I tried to enumerate all the duties I could think of. Please add anything I may have (likely) forgotten.

I propose three ways of sharing the tasks

1. By quantity.

This means that one member does some quantity of a given task then hands it over to the next member on the list, regardless of the time spent to do the task.

2. By period.

This means that one member does the task for a given period of time then hands it over to the next member on the list regardless of the quantity done.

3. By field.

This means that member A takes field 1, member B takes field 2 etc, regarless of time or quantity.

The 'list' is the list of the members' names ordered alphabetically, or in any other agreed-upon logical order. If the list is A B C D, and member B is not available for a valid reason, the order should change once to A C B D for that turn only (the keyword here is equally :-) ).

Tasks

1. Email replies to 'contact', 'support', etc.

__Sharing proposed__: by quantity or by field (field='mailing list' or 'subject' (translation, development, etc)).

2. New subscriptions follow-ups.

__Sharing proposed__: by quantity (20 subscriptions).

3. Presence on IRC.

__Sharing proposed__: by period (24 hours or 1 week or ...).

Of course, this does not mean that more than one core member can't be present on the channel at the same time, but this is to ensure that there is at least one core-ite to answer questions, moderate, point to mailing lists, etc.

4. Meetings driving, writing the minutes and the next meeting agenda.

__Sharing proposed__: by quantity (1 meeting) [already in place].

Non regular meetings should be discussed: do they count in this organization ? where to keep the minutes ? etc.  

5. Mailing lists 'moderation' (?).

__Sharing proposed__: by period (1 month) or by field (field='mailing list').

6. New projects adoption (facilitator).

__Sharing proposed__: by quantity (1 project) or by field (translation, development, etc).

7. Website adminsitration (links up-to-date, press releases, documents, etc).

__Sharing proposed__: by period (3 months) or by field (press, links, docs, etc).

8. Events organization (Evolution Party and such).

__Sharing proposed__: by field (to be discussed case by case ?).

Project Automations

There need to be some time spent to seriously consider automating many of the tasks currently performed by core and others. For instance, canned responses sent out to new registrants are not automated and should be (unless certain fields are not properly filled -- a simple check on the length would filter out most bad registrations). This process also takes a considerable amount of time and should not.

The Project's Direction

The Arabeyes Project's overall direction requires some fine-tuning and adaptation to the growing number of members of the Arab open source community. Not every member of the community is likely to want to be a part of the Arabeyes structure. People have different tastes (some like Ferrari's, others Lamborghini's ;). What we need to do is adapt to this kind of change and "dress accordingly".

Community-Driven

Due to the fact that we are finally starting to see Arabic/Linux-related initiatives mushroom all over the net, it is time for us to re-consider our 'umbrella' strategy. I think it should remain in place, but slightly refined to suit the new environment. What I am proposing here is that we aim to be the community's melting pot as opposed to the umbrella for all Arabization efforts. We need to work harder in our coordination with other projects as opposed to attempting to cover them under our umbrella.

Lead in Creating Standards

Arabeyes has set the bar for most contributions for Arabization, but we have lagged behind in setting standards. Extra efforts need to be put into making those standards and implementing them while we can. It is no secret that there are various efforts out there, some of which aim to undermine Arabeyes' role for personal agendas. Instead of fighting those efforts, we need to instead concentrate on ensuring that standards of what we have been doing are widely accepted.

An example of this is for translation and the horrible failure of ["QAC"] so far. Drastic measures must be taken to ensure that there are standards to be followed. Another example is the Standards for Arabic Inclusion and Support document and its related SaisApps.

Plan Suggestions

Despite Core's attempt to play a hands-off approach to most projects to allow others to put in their input, I believe this issue is so important that it cannot do without direct intervention from Core. We can begin by following up with the two above mentioned standards issues.

• YoucefRabahRahal and MohammedElzubeir to follow up on the ["QAC"] and MAKE it happen.
  • Both are to draft a system for the committee and appoint members
• AnmarOueja and NadimShaikli are to follow-up on the SAIS document and ensure that it covers all aspects, detailed, etc.
  • Ensure that the "community" has its say on the document
  • Gain acceptance among the different groups (with their varying sizes)