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 CREATE THIS PROJECT! 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..."
  • which dev tools to offer is important. We can't make like sourceforge and just offer resources to code projects. In any case, that space is reasonably well-filled already. And most coders will know how to set up computing resources to make themselves a nice environment. What we need is space that accommodates non-coders as well. Art. Communities. Translations. Writers. Tiny hardware projects with PICs and AVRs. Jams. Whatever. Writing a book needs version control just as much as coding does. Artists need wikispace just as much as firmware hackers.
  • TOPP (OpenPlans - Ian Bicking et. al.) would be a fan-TAStic group to work with on this. They're basically making sourceforge-like space/hosting/tools for community groups.
  • Probably there should be a series of checkboxes when you create a new project when you select the kind of resources you need installed - with a few preset buttons that fill in the typical values for, say, a translation, or a content, or a community/event, or a code project, so people can be lazy.

• a clear way to, after a trial period of... say, 4 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 4 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. Bonus: 4 weeks is long enough to actually get something to work and test, which means we can announce real working projects - which people are more liable to jump on and contribute to than "hey, I have a cool idea" spurts.
  • A requirement for moving into active project status should be that the group has something that is either testable or hackable by other users. In other words, some minimal set of documentation. So one of the litmus tests for the admin-types that approve new projects should be having the admins - or someone recruited by the admins - from outside the project actually follow those directions to see if they can use/contribute. Projects. must. be. accessible. I hate seeing projects on sourceforge that sound awesome but are basically illegible .cpp files stuffed in a directory with no instructions... they will never get used.
  • Another requirement for moving into active project status should be that the group has prepared at least their front page for translation... possibly even gotten someone from the translations crew to do just their front page - in any language. This makes the project accessible to more people that speak that second language, jump-starts translation and encourages the formation of a truly multilingual wiki, and also means the team has to be on solid enough ground that they can get an external translator to do a page for them.

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