Re: Registration replies

[Abdulaziz Al-Arfaj <aalarfaj at gmail dot com>]

Salam and sorry for the late reply,

On Apr 9, 2005 3:42 AM, Nadim Shaikli <shaikli at yahoo dot com> wrote:
[...]
> 
> The proposed idea is to engage the various project maintainers by having
> them step-in to cultivate future helpers and volunteers. The idea is as
> follows.  When a person registers today he/she has to indicate if they're
> interested in one of 4 categories - Translator, Developer, Artist and
> Public-Relations.  Depending on the category he/she chooses, the user
> will see a pull-down menu with a list of all the active (ie. non-retired
> or completed) projects in that category.  He will be asked to select an
> entry (default is "SELECT a PROJECT" - ie. they HAVE to select something
> else their registration won't be accepted).  

Is it too early for technical questions? This drop-down menu with the
list of related projects, should it be on the same page as the
category selection menu, or on the next page? It is possible to have a
menu right next to the category selection menu and when user selects
translator for example the other menu is dynamically populated with
GNOME, KDE etc... or... we can have this selection on the next page.
First method would involve JavaScript, something which our site is
almost free of. I'm for making the registration process a multi-page
one. I have this to think about:

I noticed most of the people who register (for those who dont know, we
get a LOT of newly registered people) do not even go and subscribe to
the lists we suggest in our welcome email. Is it because they are
lazy? Is it because they dont know how? I dont care. What I have in
mind is just near the end of the registration process, they get a list
of checkboxes of all the mailing lists. e.g. they would say "subscribe
to the Documention and Translation Mailing List", "Subscribe to the
General list". For those of you who have ever signed up with MSN
Hotmail, this will sound very familiar. In fact I plan to copy the MS
model by creating nice little icons for all the mailing lists.

Some of those checkboxes would be preselected by default based on the
category of contribution the new registree picked in the previous
page. i.e. if he chose "developer", the developer list would be
preselected by default.

> The volunteer should also
> be given a "Not Sure" as well as "Have my Own project" options.  Once the
> user selects a project say Gnome (if he had picked translation) then the
> Gnome project maintainer/leader gets the email that 'core' today gets
> asking him to "process" the person.

Thankfully this is simple enough to do.

> The project maintainer is then to
> reply (in his own manner) to the user and get him/her on-board.  We can
> give each maintainer the template we've been using as a form of assistance,
> but the idea is not simply to have them reply to the new volunteers, but
> it is to get the maintainers really involved in how to get various
> interested people (they did select their project after all) contributing.
> Once the project maintainer has enough confidence in the new person, he/she
> can request said volunteer a CVS commit account.
> 
> If a person picked "Not Sure" a Round-Robin mechanism kicks-in.  Let me
> expand.  Let's say we have 4 translation projects - A, B, C, D.  Let's
> assume the maintainer of project C notes on his project page "This project
> doesn't need help" by selecting or setting a check-box, this leaves us
> with 3 projects.  So when a person registers and picks "Not Sure - Assign
> me something" a behind the scenes picker chooses a project for him/her.
> Once a project is chosen it should be advanced so that the next "Not
> Sure" selection picks the next project on the list in order to be fair
> to all, etc (so A,B,D,A,B,D,A... - a circular FIFO if you will).

Where will this information about projects needing/not needing/which
project is next in the FIFO circle be stored? The need help/dont need
help issue is as simple as adding an extra column to the projects
table, and then modifying project.php to allow this to be
displayed/changed. I did work recently on project.php regarding
Ossama's bug report to allow project coordinators to add contributots
to the project (PR 51), and thankfully it makes our job here simpler
because only minimal changes will be needed and both Core members and
project maintainers will be able to change a project's "need/dont
need" status.

As for the circular FIFO thing. Its not tricky, but a little awkward.
Where would this information fit in our database? We will need one
"pointer" for every category right?

[...]
> At the end of the month a summary list (one line entry per new registration)
> of all the people registered during that month and their selections (project
> assignments) should be mailed to 'core'.  This "summary registration" mail
> will help 'core' keep track of what is happening to see if individuals are
> getting the proper attention they deserve.  We should also ask all maintainer
> correspondences/emails to volunteers be it replies and/or "help me" exchanges
> be BCC'ed to "register at arabeyes" or similar.  This would be required simply
> to make sure that progress and the required necessary action is taking place.

Ah, so now we're doing statistics? :-D

Again, this is simple, but the issue is, where does it fit? Perhaps we
could just run a query on our good ole' "user" table, and see what
people registered this past month, and where they ended up? We might
also need an expansion of the user table as well.

What mechanism will do prepare and mail this summary? A cronned script?

This is starting to make perfect sense. I will got on this when we
have enough feedback.

Abdulaziz,