Possibility of having small FOSS projects in introductory CS courses
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.
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the firefox-dev