Education/Projects

This page is still a draft mode. Comments and contributions encouraged.

Overview

Mozilla is a global open source community with a rich technical diversity. Its products are used by hundreds of millions of people around the world in many different languages. The size and complexity of Mozilla can seem overwhelming to new contributors, and especially to students, who are still learning many of the skills necessary to work at this scale. However, this also makes Mozilla a good choice for those seeking to do real-world project work.

Why should academics consider working on Mozilla?

• Mozilla's source code is freely available for study, improvement, and extension. Students and educators can work on and with the code without having to sign restrictive contracts or non-disclosure agreements.

• Mozilla uses many different technologies from C/C++ to JavaScript, Python to XML, and every open web technology imaginable. There are all different levels and types of involvement that are possible. Everything from software engineering to user interface design to technical documentation to marketing to translation are possible, along with many other types of involvement.

• Small improvements are valued along with large ones. Projects come in all shapes and sizes.

• Mozilla's products work on every major platform, from Windows to Linux to Mac, as well as mobile devices. As such, leveraging a student's or school's knowledge of a particular platform, operating system, or API is possible.

• The culture of Mozilla is built on peer review and collaboration. When a student completes work to fix a bug or add a feature, the code is reviewed by Mozilla. This means that there is a built-in mechanism for students to get feedback, for educators to insure that students' work is technically sound (i.e., you don't have to understand all of Mozilla to have your students working on it).

• Mozilla is an interesting mix of very old and very new technologies. For those wishing to study and gain experience with software maintenance, Mozilla is an excellent case study. At the same time, others can focus on the latest additions to the web and get experience innovating with new techniques. Both are going on at the same time.

• Mozilla creates world-class software that is used by hundreds of millions of people around the world. When a student can contribute to these products while still in school, she builds her resume and gains valuable experience that is hard to gain in other ways.

Our Goal

A primary goal of Mozilla Education is to make it easy to match students/educators looking for potential projects with the Mozilla community and real Mozilla project work. The following guidelines are given to help facilitate this, and to make how to get involved.

We believe that by making students into contributors, instead of having them play in a sandbox, we can better enable them to do real work and gain experience.

Guidelines

The following guidelines are offered with a view to making the interaction between students, educational institutions, and the Mozilla community as seamless as possible. These are not hard rules, but ideas learned through experience bringing students into the Mozilla project over the past three years.

For Students

• Don't be afraid to pick a project that includes technologies you don't already know. It is normal to not know everything when you start, and to learn on the fly.

• At the same time, pick things within reach for your ability and experience level. You'll be happier working just above your current level, but not so far that you're constantly exceeding your limit with the project and community.

• It's good to ask questions, but not all questions are appropriate in all places. When in doubt, start with those involved in #education on irc, the education mailing list, etc. We can either answer your question, or help you connect with the right people to help you.

• Working in the open is the way to do open source. This means creating a blog, getting added to our Mozilla Education Blog Planet, working in the wiki, putting patches in bugs, etc.

• Working in the open can take some getting used to, especially when you feel like everything is new. Don't be afraid to expose your weaknesses or say you don't know something. You will not encounter negative feedback for such honesty.

• Expect that your work will be critiqued and often rejected. This is normal, and it happens to even the most seasoned contributors. The reasons are technical, not personal, and they are usually something you can fix. Having to do half-a-dozen versions of a patch before getting it accepted is not uncommon, and in no way an embarrassment. Working in a collaborative open source project the size of Mozilla means making compromises, adjusting to meet other people's needs, and improving what you thought was good until it's great.

• When you pick a project, speak to someone in Mozilla Education in order to let them know. This way you can get the bug assigned to you, we can remove it from the list, and make sure you are connected to the right people.

• Use various communication tools to do your work:
  • Your blog - keep a regular record of what you're doing, things you're learning, difficulties you have and solutions you come to, and releases you make. People will read your blog.
  • Bugzilla - this is for technical discussions related to your work. You can ask questions here about your project, post your work (i.e, patches), get reviews, etc. This is not the place for general discussions
  • Wiki - this wiki is a good place to put documents or work that doesn't belong in bugzilla or your blog (e.g., notes you've taken). You are encouraged to put such work under your user space, e.g., User:SomeUser/ProjectNotes.
  • #education - this is the best place to go when you're not sure where to go. You are free to ask technical questions, questions about Mozilla processes ("How do I make a patch and get it reviewed?"), etc.
• When you are done with your project, or need to abandon it for some reason, please let us know so that we can retire it or return it to the pool of potential projects.

For Educators

• Whenever possible it is best to get students who are working on Mozilla projects to work directly in the community. This means bugs in Bugzilla, rather than hosting things on your own site or using your school's system. This helps to insure that project work doesn't happen outside the view of the Mozilla community. When the Mozilla community can see what's happening, they are more likely to give feedback, make corrections, contribute, and finally, to accept the work. This won't always be possible, and not every type of project is appropriate in a bug (e.g., Firefox extensions are not typically done this way).

• Students, and new contributors in general, typically do not yet know what has value in the community. Therefore, having students pick their own projects vs. working on existing bugs, has a lower likelihood of success (i.e., harder to find mentors, harder to get help, harder to get "traction"). We are happy to help you find projects for your students.

• It's a good idea to CC yourself on bugs your students are working on, so that you can follow them. Every time someone adds a comment to a bug, you'll get an email. You can also add a Watch to their wiki pages, and subscribe to their blog feed. Doing so will help keep you informed of everything that is going on, and make it easy to interact yourself.

• Leverage the people in Mozilla Education to help you find the right people to get questions answered, learn about technologies you don't already know, find teaching resources, etc.

• It is a good idea to buffer your students from the community, and vice versa. For example, your students will inevitably have questions that you would can and should answer. Also, students don't always know the limits of working in a community, and can need guidance to become effective communicators. Your help in this regard is invaluable. You can, for example:
  • look at code before they ask for formal review
  • help them formulate questions or responses to comments in a bug
  • look for help from people in the community
  • write effectively in their blog about the work they are doing

For Mozilla

NOTE: references to "good potential projects" below will be changed when bug 479062 is resolved.

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.

• 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.

Potential Projects

This list will be posted when bug 479062 is resolved and we have done some initial triage to identify these bugs, according to the ideas set out above.