<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 2014-08-01 3:12 AM, Manish
      Goregaokar wrote:<br>
    </div>
    <blockquote
cite="mid:CACpkpxnSkVY7ABvmbxOdj2qb2giLhRBbrCAmjyA_nDt7RM=HCQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>So this semester some rather interesting things are planned
          for the CS101 course taught by <a moz-do-not-send="true"
            href="http://en.wikipedia.org/wiki/Deepak_B._Phatak">Professor
            DB Phatak</a> (a great supporter of FOSS) in my university.\</div>
      </div>
    </blockquote>
    <blockquote
cite="mid:CACpkpxnSkVY7ABvmbxOdj2qb2giLhRBbrCAmjyA_nDt7RM=HCQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>[...]<br>
        </div>
      </div>
    </blockquote>
    <blockquote
cite="mid:CACpkpxnSkVY7ABvmbxOdj2qb2giLhRBbrCAmjyA_nDt7RM=HCQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>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.<br>
        </div>
      </div>
    </blockquote>
    Hi, Manish!<br>
    <br>
    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.<br>
    <br>
    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. <br>
    <br>
    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>
    <br>
    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>
    <br>
    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.<br>
    <br>
    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>
    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>
    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>
    Which is all to say, good luck, and I'd be happy to talk to you more
    about this, and help how I can.<br>
    <br>
    <br>
    - mhoye<br>
    <br>
  </body>
</html>