View source for Overview of Mozilla Communication

=Mozilla Community=

Any significant and sincere attempt to work with Mozilla must begin with an understanding of the Mozilla community.  Where some technologies are the product and property of a business created by employees and overseen by managers, Mozilla is developed and used in the open as a collaborative public good.  Decisions are discussed and finalized in the open, with the opportunity for public engagement.  Contributions to the project come from around the world, from volunteers, from employees of large companies, from employees of small companies, and also from the Mozilla Corporation itself.

This open, public, collaborative structure makes it possible for students to become engaged in the process of fixing, improving, and advancing Mozilla.  To do so effectively, they must learn how to participate in the community and have their voice and work noticed.  One doesn't need permission to do any of this, but simply the knowledge of how to do it.

==Communication==

Because the community is so large (one of the largest open source communities in the world), and so globally distributed, different communication channels and media are used.  Depending on the type of work you are doing, one or more of these will be most effective.

===IRC===

[https://wiki.mozilla.org/Education/Learning/Irc IRC] is a real-time chat protocol used extensively by Mozilla's most active developers to co-ordinate activities.  You can learn more about how IRC works, and get instructions on using it in the Mozilla context [https://wiki.mozilla.org/Education/Learning/Irc here].  

Almost all open source projects have IRC channels, but Mozilla is large enough that it has its own server, with hundreds of channels.  Learning IRC is one thing, and then figuring out which channel(s) are the most appropriate for certain types of work/questions is another.  The best starting place is the [irc://irc.mozilla.org/seneca #seneca] and [irc://irc.mozilla.org/education #education] channels.  These channels are filled with students and professors from many schools, and also some knowledgeable (and sympathetic) Mozilla community members.  Not every channel is going to be friendly to beginners, but these channels will always be.  You can ask anything about Mozilla, IRC, getting students connected to people within Mozilla, etc.

Here are some other points about IRC for academics:

* IRC can seem somewhat childish, with its use of short forms, nicknames, etc.  However, don't dismiss it because of this.  Being able to communicate with your peers, and Mozilla developers in a real-time chat environment is invaluable
* Getting developers to stop what they are doing and help you on irc is a two-way thing: if all you ever do is ask questions, you're not likely to have your questions answered over the long term.  The best long term strategy is to look for ways to contribute to the channels.  For example, a developer may need help testing a patch, or need some info about an OS they don't have.  Watching for ways to contribute helps build your credibility and place within the community.
* Similar to the previous point, IRC is not email.  Joining irc, asking a question, then leaving right away is not how you should use it.  Many people leave it running all the time so they can read what has happened while they were away.  Maybe you'll know the answer to a question asked a few hours ago--it's fine to answer it now
* Don't overlook the value of sitting idle in the main developer channels.  What an amazing learning opportunity to have the chance to be able to go and "sit" in the "office" of a world-class developer project and listen to how they work.

===Mailing Lists/Newsgroups===

While IRC plays a central role in connecting developers around the world, it is not sufficient on its own.  This is especially true when you need to talk with someone in a timezone opposite to your own.  For more asynchronous communication, using Mozilla's [https://lists.mozilla.org/listinfo mailing lists] (which are also cached as newsgroups by Google) 

Like IRC, subscribing to a number of mailing lists can greatly increase your exposure to, and awareness of, the community and what is being worked on at any given moment.  It's also a good way for you to ask certain questions.

Here are a few lists that might be of interest to you and your students to get started:

* [https://lists.mozilla.org/listinfo/dev-apps-firefox dev-apps-firefox]
* [https://lists.mozilla.org/listinfo/dev-apps-thunderbird dev-apps-thunderbird]
* [https://lists.mozilla.org/listinfo/dev-builds dev-builds]
* [https://lists.mozilla.org/listinfo/dev-extensions dev-extensions]
* [https://lists.mozilla.org/listinfo/dev-platform dev-platform]
* [https://lists.mozilla.org/listinfo/dev-platforms-mobile dev-platforms-mobile]
* [https://lists.mozilla.org/listinfo/dev-tech-xul dev-tech-xul]

See the complete list [https://lists.mozilla.org/listinfo here] for others.  There are also various [https://wiki.mozilla.org/Labs#Discussions Labs Google Groups], many of which will make for good student projects.

===Weekly Calls===

In addition to online communication, a number of weekly status and planning calls are held.  These are open to anyone wishing to join.  Just as idling on IRC can be a great way to learn about the technologies and tools used my Mozilla developers, the weekly calls provide good insight into the workings of the project.

* [https://wiki.mozilla.org/Education/StatusMeetings Mozilla Education]
* [https://wiki.mozilla.org/WeeklyUpdates Project wide weekly update]
* [https://wiki.mozilla.org/Firefox3.5/StatusMeetings Firefox status meeting]
* [https://wiki.mozilla.org/Platform#Meetings Platform meeting]
* [https://wiki.mozilla.org/Thunderbird/StatusMeetings Thunderbird status meeting]
* [https://wiki.mozilla.org/Labs/Weave/WeeklyMeetings Labs - Weave Weekly Meeting]
* [https://wiki.mozilla.org/Labs/Bespin/StatusMeetings Labs - Bespin Weekly Meeting]

===Blogging===

A good portion of the Mozilla community blogs.  People use these blogs to demo experiments they have tried, share something they have learned, discuss their reaction to something, bring attention to things that are happening in the community, etc.  Following these blogs is greatly simplified by the use of various aggregate blog planets:

* [http://planet.mozilla.org Planet Mozilla] - the main blog planet for the Mozilla project.
* [http://education.mozilla.org/planet Mozilla Education Planet] - students, professors, and Mozilla community bloggers who are connected to the education work.
* [http://planet.mozillamessaging.com/ Mozilla Messaging Planet] - blogs about Thunderbird, SeaMonkey, Calendar, etc.

You should start a blog and write about your work to start teaching and working on Mozilla.  You should make your students do the same.  You should both get these blogs added to the [http://education.mozilla.org/planet Mozilla Education Planet] (email [mailto:david.humphrey@senecac.on.ca David Humphrey].  It is [http://vocamus.net/dave/?p=375 hard to overstate the value of doing your work in the open, and on the web].  When people can see the work that is going on, it is easier to comment, provide help, and connect with you.

==Collaboration==

Mozilla is focused on web technologies, and as a result, the way the project works is also heavily influenced by web based tools.  Deciding to use these same tools vs. standard educational tools (e.g., Blackboard) will mean the difference between having Mozilla work with you, and being isolated in an academic silo.  One nice side effect of choosing to use Mozilla's own tools is that you don't have to get anyone's permission at your institution to set up what you need: Mozilla already hosts it all, and allows anyone to create accounts.

===Wikis===

Mozilla uses a number of wikis, each with a different purpose.  Over the past few years, a lot of work has been put into consolidating various sites and other resources into a smaller number.  Here we look at the two most important.

====Mozilla Developer Center (MDC)====

The [http://developer.mozilla.org Mozilla Developer Center] (sometimes called 'MDC' or 'devmo') is Mozilla's main documentation site.  It is aimed both at developers using Mozilla technologies (extensions, XUL, JavaScript, web) and also at people developing Mozilla itself.

MDC is meant to be a polished set of documentation vs. a scratch pad for random information.  You can (and should) create your own account so that you can edit mistakes, or contribute new information.  If you are unsure about a change you think needs to be made, you can ask in the [irc://irc.mozilla.org/devmo #devmo] irc channel.

====Mozilla Wiki (wiki.mozilla.org, wikimo)====

Where MDC is public facing documentation, the [http://wiki.mozilla.org Mozilla Wiki] (sometimes called wikimo) is a common collaboration point for organizing groups of developers, developing documentation which will eventually be moved elsewhere, etc.  You can (and should) create your own account on the Mozilla Wiki so that you can participate in community documentation efforts, and also have a common (i.e., to you, your students, and Mozilla) collaboration point for Mozilla-related education and project work.

===Bugzilla===

Mozilla is the creator of one of the most popular issue tracking systems in the world--[http://www.bugzilla.org/ bugzilla].  Many open source projects use bugzilla to keep track of bugs, enhancement requests, and otherwise keep a historical record of a project's development.  Mozilla is no different, using its [https://bugzilla.mozilla.org own instance of bugzilla].

Anyone can create a Mozilla bugzilla account and file new bugs.  You can (and should) create a Mozilla bugzilla account so that you can participate in bugs, and follow development activity.  Modifying some aspects of a bug requires increased rights.

One of the goals of Mozilla Education is to provide an up-to-date list of potential projects for students, in the form of bugs in bugzilla.  You can see a list of such bugs here:

Here is the list of bugs with the "student-project" keyword:
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&keywords_type=allwords&keywords=student-project&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=REOPENED&chfieldto=Now&order=Bug+Number Available student projects, sorted by bug number] - [https://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=REOPENED&chfieldto=Now&field-1-0-0=bug_status&field-1-1-0=keywords&keywords=student-project&keywords_type=allwords&query_format=advanced&remaction=&type-1-0-0=anyexact&type-1-1-0=allwords&value-1-0-0=UNCONFIRMED%2CNEW%2CREOPENED&value-1-1-0=student-project&title=Bug%20List&ctype=atom atom feed]
** [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&keywords_type=allwords&keywords=student-project&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=REOPENED&chfieldto=Now&order=Last+Changed Available student projects, sorted by Last Changed] - [https://bugzilla.mozilla.org/buglist.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=REOPENED&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailqa_contact2=1&emailreporter2=1&emailtype1=exact&emailtype2=exact&field-1-0-0=bug_status&field-1-1-0=keywords&field0-0-0=noop&keywords=student-project&keywords_type=allwords&long_desc=&long_desc_type=substring&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&status_whiteboard=&status_whiteboard_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=allwords&type0-0-0=noop&value-1-0-0=UNCONFIRMED%2CNEW%2CREOPENED&value-1-1-0=student-project&value0-0-0=&votes=&title=Bug%20List&ctype=atom atom feed]
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&keywords_type=allwords&keywords=student-project&bug_status=ASSIGNED&chfieldto=Now&order=Bug+Number Assigned student projects] - [https://bugzilla.mozilla.org/buglist.cgi?bug_status=ASSIGNED&chfieldto=Now&field-1-0-0=bug_status&field-1-1-0=keywords&keywords=student-project&keywords_type=allwords&query_format=advanced&remaction=&type-1-0-0=anyexact&type-1-1-0=allwords&value-1-0-0=ASSIGNED&value-1-1-0=student-project&title=Bug%20List&ctype=atom atom feed]
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&keywords_type=allwords&keywords=student-project&bug_status=RESOLVED&bug_status=VERIFIED&chfieldto=Now&order=Bug+Number Resolved student projects]

Here are some things to note about using Mozilla's bugzilla in an educational context:

* IRC, mailing lists, blogs, etc. are all useful for keeping people informed about your work; but the best way to get access to the right people is through bugzilla.  Every developer working on Mozilla uses it, and a properly filed bug (e.g., in the correct product, component, etc.) will insure it gets seen.
* Having said that, not all student work belongs in bugzilla.  Extensions, experiments with existing technologies, the creation of new tools, etc. are probably not appropriate for bugzilla.  Knowing the line between what does and doesn't belong takes time, and you can always ask in the [irc://irc.mozilla.org/education #education] channel.
* Learning to use bugzilla properly can take time (many aspects of the classification system, or use of flags are cryptic even to the experienced).  Not being 100% sure how to proceed shouldn't stop you from trying, remembering that you can always ask for help in the [irc://irc.mozilla.org/education #education] channel.  [https://developer.mozilla.org/en/Getting_your_patch_in_the_tree Here is some information] about the process of getting work reviewed and "landed in the tree" (i.e., committed to the hg repository).

Finally, be prepared for no-nonsense, highly technical, sometimes critical environment in bugzilla.  Remember that this is where technical decisions about what gets accepted/rejected in terms of code are made.

Also note that just as you can observe without saying anything in irc and the weekly calls, so to in bugzilla can you "watch" a user or "CC yourself" to a bug.  After you have created your bugzilla account, you can visit any bug, and click "Commit" to have it automatically add you to the bug's CC list.  Doing so will mean that whenever someone adds a comment, attaches a patch, or otherwise updates the bug, you'll be notified by email.  Adding a "Watch" for a bugzilla user is similar, but will mean that you get sent copies of all bugmail for the specified user.  Be careful who you choose, as some users get a lot of bugmail!  To set a watch, do the following:

# On the main Mozilla bugzilla page, click [https://bugzilla.mozilla.org/userprefs.cgi Preferences] (you'll need to be logged in)
# Select the [https://bugzilla.mozilla.org/userprefs.cgi?tab=email Email Preferences] tab
# Scroll to the bottom under '''User Watching''' and add the bugmail address for the user you wish to watch

==='The Tree': Tinderbox, HG, Try Server, Talos===

Since so much of the work going on within Mozilla is focused on the development of various software products, and since development takes place in parallel by developers around the world, a lot of work goes into making sure the source code builds, hasn't regressed in terms of functionality or performance, etc.

For the most part, these details are not interesting in the educational context (at least not at first), but some awareness of them will help you to understand some of what is going on within the project.

First, the 'tree' is the code in revision control.  Mozilla uses Mercurial (HG), a distributed revision control system.  You can get (i.e., clone, see below) a local copy of the hg repositories to work against.  You can also see the latest changes and versions of files by visiting Mozilla's [http;//hg.mozilla.org HG Web] interface.  There are many repositories, but here are a few to focus on initially:

* [http://hg.mozilla.org/mozilla-central/ mozilla-central]: Firefox
* [http://hg.mozilla.org/comm-central/ comm-central]: Thunderbird, SeaMonkey
* [http://hg.mozilla.org/mobile-browser/ mobile-browser]: Fennec Mobile Browser

You can see the health of the tree at any given time by looking at [http://tinderbox.mozilla.org/showbuilds.cgi Tinderbox].  For example, to see the current status of Firefox, you look [http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox here].  You only need to pay attention to the top row and the colours of each.  When you get the source yourself, you'll want to make sure that it is '''green''' and will build.

At the time of writing, the tree was '''CLOSED''' (meaning developers are not allowed to commit new work), the ''OS X 10.5.2 mozilla-central unit test'' machine was orange (meaning a unit test failed after building), ''WINNT 5.2 mozilla-central unit test %'' was "burning" (meaning the build had failed), and all other trees were green (build and/or tests succeeded).

Developers can see graphs of various performance and other data for each build/test run using systems like [https://wiki.mozilla.org/Buildbot/Talos/Machines#Graph_Links Talos].  Developers with commit rights (i.e., who have been granted the right to check-in code), can also test their work against the [https://wiki.mozilla.org/Build:TryServer Try Server].  This allows them to see the effect of building and running tests on all 3 main platforms before actually checking in any code.

Most of this can be ignored as you get started.  But knowing what certain terms mean, and where to look for information as you get more comfortable, is important.