My name's Mike Hoye, engineering community manager for Mozilla out of Toronto.
I'd like to take a moment to tell you a bit about myself, but nobody's got time for that, so let's get straight to the biscuits.
Mozilla is huge, and we have a lot of ways that people can join up and contribute, but we don't really have a single place where educators (high school teachers and, college/university profs, for the moment) can get a sense of what it would take to get themselves their students involved.
In short: right now, our "education" page is old and bad, and I think it should be the other thing.
So: somebody comes to us and says, I'm a teacher/professor of (X) at (Y), and I'd like to involve myself and/or my students in some facet of the Mozilla project. What I'd like to do is to present them with a list of possible options, so we can figure out what sort of constraints they're under, what sort of relationship we can have with them, and how to make that a good experience for everyone involved.
So, what I'd like to get from all of you is a sense, in your corner of the Mozilla project of the following:
- What can a contributor bring to your project?
- How much effort does it take to spin up whatever tools or connections you need to spin up, in order to make that first contribution?
- Is the second the same? Different? Do you pay for that ramp-up time every time, or just once?
- What sort of commitment are _you_ willing to make to a contributor, once you're aware they want to participate?
- What sort of recognition or other rewards can you offer a successful contributor, or participant in your process?
- How can you scale that contribution up or down, to fit the abilities and academic context of the prospective participants?
Finally, and I think these two are the most important:
- To the most realistic-slash-pessimistic degree possible, what sort of a time commitment do you think a contributor will have to make, in order for their contribution to be meaningful and rewarding?
This is going to be different for a lot of people, in a lot of places. A single PhD student data-mining Mozilla's history for their doctorate will have different time commitments available than a student who's juggling four other classes that semester, or a prof who wants his kids to know what Open Source and the Web are but also needs to publish papers towards tenure. We need to present a variety of options there with the best assessments of time-cost we can.
- ...and finally: what is the _minimum_ skillset and experience that somebody needs to bring to the table, to make this a rewarding and successful relationship, not just for themselves but for their students and Mozilla as well?
What I'm getting at there is an idea I've been bouncing around for a while, that of the "minimum viable contributor". Basically: for this to be an effective, mutually beneficial relationship, what is the minimum bar you need to be able to meet?
This doesn't have to be something like "2 years JS experience", nor should it; that's too vague, and these criteria should be crystal clear. Just as one example, we could say that as far as teaching a class is concerned: "in order to be successful at helping students file bugfixes against Firefox, you must first have fixed one significant Firefox bug yourself". We put that up as a barrier to entry, so we know that educator is familiar with the people, processes and gotchas of the fix-landing process, and isn't just throwing their students under a bus.
This should, ideally, be something that somebody with a Mozilla LDAP account can check quickly and easily, like Van Halen's brown M&Ms.
Then we can say, this is what you can be a part of, this is how you can evaluate success, this is what's next after that.
So that's what I'd like to start with here.
- What do you have.
- What do you want from somebody, and how can you check it.
- What can you give them, and
- How hard will that be to get.
I'll have more on this soon, but that's a decent start.
Thanks for your time.