User:Mchua/Braindumps/Volunteers portal

Ahh... Mitchell, your email got me so worked up that I think I might miss my goal of leaving the office before midnight at some point this week. :)

Here's what I think we need, written in a very braindumpy fashion. Ccing Nikki, as she's hoping to take this project on for Summer of Content.

Introduction to OLPC

(1) A place to come in and find out what the heck OLPC is in a nutshell, and the kinds of things we do, the type of help (broadly phrased) that we're looking for.

Sign-up

(2) Great, you're interested in helping - now make sure they can immediately get involved. Tell them "here's how you join the community." Define what it means to "join the community" and tell people how to do it right then and there - currently creation of a wiki account (need to have better materials to walk people through this).

Also advise people to sign up for one of the big "announce" lists so they get notified of big OLPC news events, calls for volunteers, etc. Send them an instant feedback in the form of a "CONGRATULATIONS! you've joined..." message both on the webpage when they click the enter button, and via email.

Personal contact / mentorship

(3) Next- personal contact. An active welcome wagon group that makes sure that every single new user gets a welcome message to their talk page within 24 hours of account creation (talk page revisions should automatically be emailed to new users; I think they are, but this should be checked.) Ideally, welcome wagon will be set up so that new users will be pinged three times by a friendly welcomer - at 24 hours, 1 week, and 1 month.

Also: A mentor pool with experienced community members who offer to serve 1-month mentor terms to newbies that request a guide - the "within 24 hours" welcome message to newbies should all have a huge link pointing to this. Mentors and newbies sign up together by entering their email addresses into a system that sends them a timed series of reminders (1x/week) to check in with each other for that month - no dead wikipages of mentors that don't respond (I've seen too many of these on open source project wikis) and mentoring terms that fizzle out and never end.

Tiny tasks

(4) Now we have to make them useful right away. Have low-hanging fruit out there for them to pick, sorted explicitly by skill/interest and time available - 10 minutes, 45 minutes, 2 hours, 6 hours, a weekend. (This also begs the creation of a "how to write up a good request for someone to do a task, including all the necessary resources and documentation for them to know how to get started" guide)

This also probably requires us to use a really user-friendly, pretty version of RT or some other task tracking system. See http://www.mysociety.org/volunteertasks for (what I think is) a lovely example. And make sure that every single one of these low-hanging tasks has (1) a person or something on the other end that gives them positive feedback when the task is completed well - something to be accountable to - and (2) really clear instructions on how to brag about doing it on their user talk page.

Contribution communities

(5) Now the long-term hook; joining a contribution community (or two, or three) - and then the members of that community can train them on the finer points of wiki culture, IRC usage, hardware hacking, art creation, or whatever. Each of these communities should encourage its members to...

Starting your own project

(6)...start their own projects. Which brings us to Mitchell's email. We need a few things:

• A short guide on what makes a good project, and how to write a good project proposal (really short - the current app to get a git repo is not too bad)

• brainstorm space & friendly mentor-types willing to give feedback on half-baked ideas. however this happens is fine.

• Instant dev tools and space on a sandbox-type space - including a lovely autogenerated project wiki page - that come into being the moment someone decides to start a project. I should type the name of my project into a form field, hit a button, and get a nice email guide saying "congratulations, your project has been made! and you have a wikipage here and a git repo here and can recruit others by telling them to do X..." also, it needs to be not restricted to just code or content projects - running a jam is a project, as is forming a local interest group, as is building a pic peripheral. the magical Create A Project Button should accommodate all these somehow.

• a clear way to, after a trial period of... say, 6 weeks - apply to move your project to the "official" repository/list of active projects. This should happen in cycles of approval once a month - you have to have been in TRIAL for at least 6 weeks prior to approval to get into ACTIVE status. this means that there's a clear deadline for people to aim at, that admin-types can batch-process new projects in, *and* that there's something cool to announce every month - "introducing our new projects..." is always a good headline.

• pings to active projects every 6 months - if there's no activity or no reply, they go into ARCHIVE dormancy and are no longer on the list of active projects. you can bring a dormant project back into being active by going back through the 6-week trial & apply period. it's important to note that no data should be lost at any point - we shouldn't delete the code of crufty abandoned projects, just mark it as archived so people won't expect it to be updated soon. (so note that under this schema, projects can be either TRIAL, ACTIVE, or ARCHIVE. this keeps activation energy for starting a project low, but keeps dead wood down.)

(Note that any of these steps can be skipped, but they provide a path for the most hesitant, timid, "I've never been on a wiki before and I'm really scared of messing up but I'd like to help!" newbie.)

Translation guide

From Nikki: "PS what does 'git' mean? and d.l.o. and mkdir? and..."

Mel: Thank you. This is exactly the kind of stuff we have to explain to people, because non-coders will be really confused when we start spouting acronyms. Let's see.

• git (and svn/cvs) are versioning systems, which let lots of people edit the same thing (usually code) at once without having their edits clash horribly. It's kind of like if the two of us were writing a paper together and decided to host it on Olin's public drive. If you wanted to work on the paper, you'd copy the file from the public drive to your laptop, open it, edit it, and copy it back into the public drive (checking to make sure I hadn't edited it while you were working - and if I had, you'd then have to merge your changes into the document in public instead of just copying it in and overwriting my work). Version control is basically an automatic way to do that.

• mkdir is the Unix command to make a directory. For instance, mkdir nikki would make a directory called nikki in whatever folder I'm currently in. The Windows equivalent is "New Folder."