Difference between revisions of "Overview of Mozilla Communication"

From CDOT Wiki
Jump to: navigation, search
(Created page with '=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 ...')
(No difference)

Revision as of 10:46, 14 September 2009

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 and your students are doing, one or more of these will be most effective.

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 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 #education channel. This channel is 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 the #education channel will be. You can ask anything about Mozilla, IRC, getting students connected to people within Mozilla, etc.

Here are some other points about IRC for professors:

  • IRC can seem somewhat childish, with its use of short forms, nicknames, etc. However, don't dismiss it because of this. Being able to combine you, your students, and Mozilla developers in a real-time chat environment is invaluable
  • Students may need some hand-holding to use irc effectively. For example, it is wise to have them start using one channel you create (e.g., /join channel name will create a new channel) and/or the #education channel. This allows them to learn the tool and how to communicate effectively online before jumping into the main developer channels.
  • Getting developers to stop what they are doing and help you (and your students) 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 having your students (and you!) sit 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 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:

See the complete list here for others. There are also various 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.

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:

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 Mozilla Education Planet (email David Humphrey. It is 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 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 #devmo irc channel.

Mozilla Wiki (wiki.mozilla.org, wikimo)

Where MDC is public facing documentation, the 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--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 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:

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 #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 #education channel. 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:

  1. On the main Mozilla bugzilla page, click Preferences (you'll need to be logged in)
  2. Select the Email Preferences tab
  3. 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:

You can see the health of the tree at any given time by looking at Tinderbox. For example, to see the current status of Firefox, you look 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 Talos. Developers with commit rights (i.e., who have been granted the right to check-in code), can also test their work against the 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.

Retrieved from "https://wiki.cdot.senecapolytechnic.ca/w/index.php?title=Overview_of_Mozilla_Communication&oldid=26643"