Mozilla Education: what getting involved looks like

by David Humphrey

This past Thursday and Friday I led a short workshop on getting started in Mozilla from a professor's point of view. I've put up the outline of what I presented, along with notes and links. You are welcome to improve and correct this, since I'll likely use it again.

It was an interesting time, since we had everything from "never worked with open source before" to "active in many open source projects."  It reinforced for me that there is no true linear approach that is going to work for all professors, nor students.  It was also nice for our converstations to get pulled off topic, as interesting questions arose from things I had planned.   For example:

How does one manage risk when having students work on real projects with Mozilla?
Great question!  From personal experience I was able to share that I have student projects from last term that are still waiting for review (the course ended a month ago), others that managed to get as many as 9 bugs closed, still others who totally vanished mid-project leaving Mozilla asking "where's so-and-so?", and everything in between.  Doing real things means that successes are more significant, that failures can cost more, and that there is rarely a "do this and everything will be OK" guideline.  Having said that, there are things I've learned:

  • Don't let students pick projects.  Offer projects that have been recommended by the community, and which you know will be reviewed, accepted if done well, have support from the community, etc.

  • Don't (or don't only) mark end products: mark process.  I've had students get to the end of a project, and the conclusion was, "This can't be done."  Failure is data, and good failure will have a long paper trail and evidence of participation and honest attempts.

  • Work out in the open where people can see what you're doing.  That's true for the profs, and also for the students.  People will read your blog, properly filed bugs will get attention, wikis aren't called collaborative for no reason, irc is bi-directional, etc.

  • Don't put students into oncoming traffic.  That feature that's so hot Mozilla would slip the ship date for it--that's not the right one for your student

  • Don't put your students in the parking lot.  Things that are so far from shipping (or at least landing on trunk) are unlikely to get you the kind of community contact you're after.
    A lot of this hinges on an implicit assumption on my part: the Mozilla community will engage with a serious attempt to connect.  I could give you lots of examples proving this, but here are a few from the time while I was leading the workshop:

  • Joe Drew pinged me on irc to let me know that he'd found two good bugs for student projects, and marked them appropriately using the student-project keyword.

  • Mark Finkle wrote a great post with links to a lot of great resources for new Fennec add-on developers.  It was nice timing, given that one of the profs was there to start working on Fennec.  "Does Fennec want new people working on this stuff?"  Yeah, and enough that they are documenting it for you.

  • Two guys named Mike took time out of their day to sit down and explain their work, and how it might connect to the interests of these profs.
    Making the point and having it made for me are not the same thing, and I was glad these profs had a chance to feel what it's like for themselves.

We're excited about how much progress we're making, getting profs and students hooked into Mozilla.  We're also really excited to see where you fit, and what you getting involved might look like.  Let us know how you see yourself conneting with Mozilla Education.