Education/Projects: Difference between revisions

==Overview==

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

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.  

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

* Whenever possible it is best to get students who are working on Mozilla projects to work directly in the community.  This means bugs in [https://bugzilla.mozilla.org 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