<div dir="ltr"><div class="gmail_quote"><br><br><br><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><br>
</div>
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.<br>
</div><div bgcolor="#FFFFFF" text="#000000"><br></div></blockquote><div><br></div></div><div>Most of the good first bugs I've come across on Firefox at least aren't enough work to be project-level, either :)</div>
<div>
<br></div><div>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 :)</div>
<div><br></div><div>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.</div><div class=""><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
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. <br></div></blockquote><div><br></div></div><div>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) </div>
<div class="">
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
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."<br>
<br>
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.<br>
<br></div></blockquote><div><br></div></div><div>This is a great idea! :D</div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
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. <br>
<br></div></blockquote><div><br></div></div><div>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 codebase.</div>
<div class="">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
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.<br>
<br></div></blockquote><div><br></div></div><div>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 :)</div><div><br></div><div>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.</div>
<div class="">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
Which is all to say, good luck, and I'd be happy to talk to you more
about this, and help how I can.<span><font color="#888888"><br></font></span></div></blockquote><div><br></div></div><div>Thanks! </div><span class="HOEnZb"><font color="#888888"><div><br></div><div>- Manish</div></font></span></div>
</div></div>
</div><br></div>