Thanks for taking this task, it really requires someone who can do it
I am currently involved into three kinds of contribution-related topics:
1. mentored bugs;
2. Mozilla Student Projects;
3. attempting to get something started with high schools.
My answers will be very different for all three avenues.
1. Mentored bugs
In my experience, these bugs often involve students but seldom involve
- Contributors help us improve Firefox.
necessary work to build Firefox locally. At some point, contributors
also need to learn about our test system.
- Ramp-up time mostly reused from one contribution to the next.
- I generally spend a lot of time answering all the questions of
contributors, as well as guiding them towards documentation and
appropriate channels. I also give them feedback on their code, help them
debug it, and sometimes test it,
- Contributors get to write on their resume that they have contributed
to Firefox. I would like to have Open Badges for that, too.
- Skilled contributors often end up requesting more difficult/open ended
bugs, and I do my best to provide this. I mentor these bugs, too,
although they are not entered as "mentored bugs" on Bugzilla, as they
are too difficult. On the other side of the spectrum, it has happened to
me to suggest switching to easier bugs or Mozilla Student Projects.
2. Mozilla Student Projects
These projects generally involve academic mentoring, although I often
have little contacts with the academic mentors, except at the end if
they ask me for an evaluation of the students.
- On the projects I have mentored, contributors create new open web
applications meant to be distributed through the Firefox Marketplace.
- Getting started requires next to nil effort.
- Same things for the second bug.
- I perform code reviews, feature reviews, I answer their questions or
lead them to persons who can do it better than me, I blog about their
projects. At times, I have guided new contributors towards existing
- I blog about the projects. I attempt to make sure that the projects
end up on the Firefox Marketplace.
- There are many topics, with distinct levels of difficulty.
3. High school stuff
Still in the process of brainstorming it. I will know more in a few months.
> 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?
On 3/8/13 8:40 PM, Michael Hoye wrote:
> Hi, everyone.
> 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.
> - mhoye
> education mailing list
David Rajchenbach-Teller, PhD
Performance Team, Mozilla