Education/Projects/MozillaGuidelines

Introduction

We would like to encourage the Mozilla community to help us identify good projects for students and educators. The easiest way to do this without introducing a new system, is to have the community file and mark bugs appropriately in bugzilla. We are going to be introducing a new keyword to make this as easy as possible. The following are some ideas for when and how to use this keyword.

Please see bug 479062.

Guidelines

• Good candidate bugs for "good potential projects" are those that:
  • Are not in the critical path of a release. Having students work on blockers, while possible and known to have worked in some cases in the past, is not a good idea in general.
  • Are not so far from a release that they have no chance of getting review or attention from the community. You want things that will have traction.
  • Are things you'd do if you had time, which probably means you care about them happening, know they could be done, etc. Whimsical ideas that you yourself have no intention of doing/reviewing/mentoring are not appropriate.
  • Are scoped for academic time frames. Students working on a project as part of a course will often spend 10-18 weeks at 1/5th to 1/6th of their time (perhaps 10-15 hours per week). Also note that some courses want students to work in groups, so a project could be spread across several related bugs.
  • Are things you know the community will be willing to help mentor. The easiest test for this is to ask yourself, "would I be willing to spend some time on irc and in bugzilla talking a new person through this?" If the answer is 'no,' then you should probably not do it. You could speak with other people and see if they'd be willing. Remember, if you're having trouble finding people who would be willing to help get someone started, the student will have even more trouble.

• There is no one-size-fits-all approach to picking projects. Some students could be in high school, others could be doing graduate work, and everything in between. Some will be designers, others developers, others writers--there is room for all sorts of project ideas, so don't limit yourself to only looking for pure development.

• Bugs that are marked as being "good potential projects" should be seen and treated as first time work. That is, if you're someone who enjoys or wants to mentor, this is a good opportunity. Similarly, if you see others who are not being as helpful as they could, step in and help to insure that stop-energy and unnecessary levels of criticism don't impede progress. We don't want to fence off student project bugs, but we do want to encourage a healthy and productive first experience.

• A number of people are good at marking bugs as "good first bugs" (159 at the time of writing). These are viewed by many as a nice way to get your feet wet in the Mozilla world, and often involve code clean-up or other janitorial work. This makes such bugs perfect for starting out. However, it can also makes these bugs poor choices for students needing semester long projects for courses. If anything the two are complementary and won't often overlap. Many students seeking to do a larger project would be wise to start with a "good first bug" in order to learn the development model used by Mozilla, and you should encourage students to try them if they need help learning their way around patches, bugzilla, reviews, etc.

• Please do help us triage these bugs. If you see that a bug that was previously being worked on by a student has gone dormant, ask yourself, "is this still a good project?" Did it go dormant because of lack of interest from the community? Are there patches there, and someone just needs to finish it (perhaps marking "help-wanted" would be more appropriate). Should it be offered to another student as is?

• When commenting or doing reviews of such bugs, remember that these are new contributors who are wanting to learn. Code reviews are inherently focused on critical assessment, and for good reason: the bar needs to be high for submissions to the tree. However, new people also need encouragement. Something as simple as, "Thanks for working on this," or, "This is really getting close," help to show that the process of iterating on a bug are technical rather than personal. Above all, save any negative criticism aimed at making fun of the person.