Possibility of having small FOSS projects in introductory CS courses

mhoye mhoye at mozilla.com
Fri Aug 1 15:43:26 UTC 2014


On 2014-08-01 3:12 AM, Manish Goregaokar wrote:
> So this semester some rather interesting things are planned for the 
> CS101 course taught by Professor DB Phatak 
> <http://en.wikipedia.org/wiki/Deepak_B._Phatak> (a great supporter of 
> FOSS) in my university.\
> [...]
> Are there any such (preferably C++) projects/bugs that we have in 
> Firefox that could conceivably be solved by first year students doing 
> an introductory course? Many of these students have learned some C++ 
> (or Java) in school, which might help.
Hi, Manish!

We're always excited to see students getting involved in free software, 
and Mozilla in particular, and we certainly have classes of bug called 
"good first bugs" that are a nice way to get involved.

The idea behind "good first bugs" is that the major challenge of the bug 
isn't the code itself, but learning how to get your development 
environment spun up, participating in development on IRC and Bugzilla, 
learning how to navigate our patch review and submission process.

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.

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.

This is bad for everyone, when it happens - the student and professor 
both get discouraged, the value of their work (and the course) gets 
harder to see, Mozilla's engineers feel like they've wasted their time. 
And if the student doesn't keep working on the patch despite all that, 
Firefox doesn't benefit.

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.

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.

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.

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


- mhoye

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20140801/b55b9756/attachment.html>


More information about the firefox-dev mailing list