Re: Registration replies

[Nadim Shaikli <shaikli at yahoo dot com>]

--- Abdulaziz Al-Arfaj wrote:
> On Apr 9, 2005 3:42 AM, Nadim Shaikli 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.

It's upto you.  Personally I think a single page would be nicer.
Some other options,

 + Force a re-load of the page (don't think you need javascript for this)
 + Spawn a small page with the pull-down menu (don't need javascript)

But as noted it is entirely upto the implementer :-)

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

Sounds reasonable - we just didn't feel right and/or comfortable adding
people without their consent (make sure to make it plenty clear to them
that they can remove/add/change things by supplying the mailing-lists
URL).  Make sure to also select the 'announce' list for all :-)

> > 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?
 
So the needing/not-needing part you seem to have figured out (yeah it
needs to be part of the project tables on a per project basis which the
maintainer, via the webpages, will change).  As for how to implement this
FIFO (well it doesn't need to be a FIFO per se, it kinda needs to function
like one), again it's upto you but here is an idea.  You set some space in
the SQL table for a single pointer per category (one for 'development', one
for 'translation', etc), call it "last_SELECTED_entry".  The pointer, as
the name denotes, points to what was last selected (project ID number).
Once you have the ID number you simply look forward from that number to
find the next "need help" project within the category noted (development,
translation, etc) and select it.  If none are found you start from ID ZERO
and look forward and if none is found there (meaning none of our projects
in that category need help - yeah right :-) then simply enter '-1' or '0'
or similar (to always look from the start in the future).  In short this
FIFO-like selection will simply use the current project order as its
processing order (seems reasonable to me).

> [...]
> > 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?

Whatever makes sense and/or is similar to things we already do.

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

Wonderful.  Hopefully it not only makes sense but is deemed a "good"
idea ;-)

Salam.

 - Nadim

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com