I wrote previously about our plan at Mozilla Education to make it easier for Mozilla, students, and academics to connect and collaborate on real-world projects. Thanks to Reed we now have a brand new bugzilla keyword to help us flag such bugs: student-project.
Doing this work in bugzilla is the easiest way for us to get the current Mozilla community involved in the process without introducing a new system. On the flip side, we're working on ways to make it easy for people who are not already working in bugzilla to find these bugs.
If you're reading this and you're already active in bugzilla, you can help us by flagging existing bugs, or filing new bugs with the student-project keyword. I'd tell you to rush so you could be the first, but that honour belongs to Ted, who has already added the first! It's fitting, since Ted has already successfully mentored a lot of students into Mozilla via such projects: now he's armed with a keyword :)
In terms of when and how to use this new keyword, I'll repeat my thoughts here. Good candidates for the student-project keyword:
-
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.
Some other thoughts to consider: -
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.
-
These bugs 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 and learning. 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.
Over the coming weeks we want to try and build a good initial list so that we can get students and academics working quickly when they show up, or as they evaluate whether they could work with us in the near future.
P.S. Using student-project is an excellent way to flag potential Google Summer of Code projects as well.