Fwd: Possibility of having small FOSS projects in introductory CS courses

Manish Goregaokar manishsmail at gmail.com
Sun Aug 3 08:38:32 UTC 2014

>  It takes a few tries for most new contributors to get their patch
> through. Reviews for code format and quality, suitable tests, that sort of
> thing can all take an extra week or two to resolve, especially if you're
> working on them around other classes. But most of our good first bugs can
> be resolved within a few weeks, well within a term.
Most of the good first bugs I've come across on Firefox at least aren't
enough work to be project-level, either :)

But they serve as a great springboard for the rest of it. A lot of people
(who are rather experienced with programming in general) have asked me in
the past that they want to get involved in Firefox (and recently, one guy
wanted to do the same for Servo) . Despite their experience, I usually
point them at bugsahoy or a good first bug if I have one at hand so that
they can learn the basics of the codebase and the processes on bugzilla
without getting overwhelmed. It usually works out well :)

I think what might work here is that first we give them a GFB to solve
(which is close to their actual project topic), and then they can start
work on the whole project.

>  There are a couple of things that make working with Firefox in an
> academic context challenging, though, and you and your professor should be
> aware of them. The biggest one is that we can't promise to accept a patch
> within a certain time frame. This can turn into a problem for students and
> professors when getting the patch accepted into the main product is part of
> the criteria for a good grade in the course. This has happened in the past:
> a student has done great work on a harder-than-expected bug, but it didn't
> make it through the process by the time grades were assigned so the student
> graded poorly.

Agreed. What I think might work out is to just let them contribute and
grade them on their progress irrespective of r+/checkin status. In fact, it
might even be okay for them to not finish their project as long as they
have made sufficient progress. (Hopefully they will continue with it in the
vacations and move on to become regular contributors. If not, I'm pretty
sure we can find others to finish off their work)

A much better approach for everyone involved is to combine fixing the bug
> with a report to your class about the process. A presentation - maybe even
> a blog post, because working in the open is important! - that says, "This
> is what I was working on and why it's important. This is how the work
> progressed, this is what the process of getting a patch in looks like.
> These are the difficulties I've faced, this is what I've learned, and this
> is where we are now."
> Making three or four "this is my experience and what I've learned so far"
> reports over the term a more important part of the grading process than the
> code itself helps enormously, both in terms of keeping everyone involved
> motivated and in reflecting the open, community-oriented values of the
> project.
This is a great idea! :D

> The second major challenge is finding bugs that are a good fit for their
> contributors. We're getting better at that - good first bugs usually tell
> you what language they rely on ( [lang=c++] whiteboard flags, for example)
> and often have a pretty good outline of what a successful patch would look
> like, and a mentor associated with them who's job (well, a part of their
> job) is to answer questions. And while we can't promise to privilege
> students ahead of any other contributors, we certainly try to hold up our
> end of the bargain and answer new contributors' questions promptly.
We'll probably be sticking to bugs with an online mentor (or ones where we
can find a mentor), but if not there are a couple of Firefox contributors
here (one just joined), and a bunch more in the surrounding area. I bet we
can whip up some local mentorship. And this is not even taking into account
the TAs -- if there are too many projects to handle, we can probably
delegate the task to a couple of experienced TAs and train them with the

> I'm not certain this is a good fit for a 101-level course, though; even
> though GFBs are generally well-contained, Firefox uses just about every
> feature C++ has to offer. so a certain amount of familiarity and comfort
> with the language is important. But maybe? We've got a huge variety of Good
> First Bugs here, ranging from "correct this documentation" to "fix this
> part of the JIT compiler", so it's possible we can find a decent fit for a
> lot of people.
Same here, when I heard of this first. I'm uncertain of how this will play
out, but I really want to help it succeed :)

The main roadblock right now is finding bugs that lie between the "change
five lines of code" easy bugs and the "student project" bugs that would
work as an open source project.

> Which is all to say, good luck, and I'd be happy to talk to you more about
> this, and help how I can.


- Manish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20140803/49d129e0/attachment.html>

More information about the firefox-dev mailing list