Posts Tagged with “community”

I’d like to keep improving the ways we describe Mozilla in general. It would be helpful to have some greater specificity around some key concepts we use regularly. “Community” is one such concept.

We talk about “community” at Mozilla all the time. A lot of other people talk about “community” as well. People use the word “community” to mean many different things. Sometimes “community” is used to describe a coherent, structured group and sometimes a diffuse, permeable set of people.

To get greater specificity I started with dictionaries and encyclopedias. The Wikipedia discussion of “community” is very long, and has many sub-parts to it. At first I thought it was too complex to be helpful. But as I’ve started talking more with people about the Mozilla identity and goals, I’ve come to think that some of the Wikipedia characterizations of  different types of communities might actually be really useful. I’m about halfway through describing Mozilla communities and will post that as soon as it’s coherent.

If anyone has definitions of “community” they think are helpful to understanding Mozilla, please leave a pointer.

Stuart recently described the need to allow improved collaboration with groups of people in specific circumstances: changes to Mozilla code that are larger (and possibly more experimental) than individual patches and where the new contributors don’t yet have commit access to the source tree and where existing Mozilla contributors want that collaboration to occur within a Mozilla-hosted source repository.

At the same time, our policies for determining who has commit access are critical to maintaining the quality of our work; we certainly don’t want to change that.

We (Brendan, Stuart and I) have come up with a proposal that we think gives us some flexibility without changing the rules for obtaining commit access to mozilla-central. It includes a mechanism for allowing such collaboration plus a description of the logistics such as how to file a bug for individual access and get it closed. Comments are welcome here or in the mozilla.org Governance newsgroup. (You can also participate through the mozilla.governance Google Group. )

Incubator Repositories

Incubator Repositories are a tool available to module owners in the following circumstances:

1. the module owners are engaged in significant cooperative development with contributors who are not yet experienced enough with Mozilla to have commit access to the Mozilla source tree; and
2. it is impractical to break contributions into bug-sized patches and follow the standard review and check-in process, either because the scope of work makes this difficult, or the work is experimental and a precursor to patches that will eventually end up in Mozilla-central or another reason the module owners can describe persuasively.

In other words, an Incubator Repository is a temporary repository hosted by Mozilla where we allow people to check code in before they have official source code write access for our production code base. An Incubator Repository is not needed for repositories where all contributors have full source code commit access.

An Incubator Repository should meet the following conditions:

• An incubator repository requires 2 module owners to be committed as sponsors.
• The work is important to Mozilla’s stated development roadmap; Incubator Repositories are not a hosting site for potentially-related work.
• The work is not duplicative of work in mozilla-central. There is some possibility that duplicative incubator repositories are possible, we can look at that if the setting arises.
• Incubator branches are temporary. In general, an incubator branch probably shouldn’t last longer than six months. By that time it should be clear whether the work has potential. And if it is an effective branch, there should be enough activity from the contributors to determine which if any of them are ready for commit access. However, setting a one-size-fits-all date for all which must be tracked for its own sake requires a bureaucracy to track and manage that. Instead, we’ll say that six months is the general timeframe. For a branch to last longer, the sponsors should have a good rationale why this is the case, they should ideally make that rationale to the Incubator Repositories module owner, and they must make that case effectively if the Incubator Repositories module owner or peers ask.
• Incubator Repositories are publicly available repositories just like mozilla-central.
• Incubator Repositories incubate both code and people. They are not training branches where the code doesn’t matter. They are not intended to provide examples of coding to evaluate someone’s readiness for commit access; we have policies for that. They are intended to help the sponsors make progress that otherwise wouldn’t be possible while new contributors learn about Mozilla and become known to Mozilla.
• Participants in an Incubator Repository may also develop patches that relate to the work in mozilla-central, for example a patch relating to start-up performance. When this happens, the patch or patches in question should be submitted through the standard process. This not only improves our code, but it provides a chance for the author’s work to become known, which is necessary for commit-access outside the Incubator Repository. The sponsors are responsible for encouraging this process.
• There is no right of potential contributors to have an incubator repository because it is easier for them. There is the ability of existing module owners to sponsor one.
• The sponsors are responsible for the operation of the Incubator Repository.

Logistics and Operational Parameters

• The creation of an Incubator Repository must be approved by the owner (or a designated peer) of the Incubator Repository module. (This is a new module which we will create as part of the implementation of this policy assuming it is approved.)
• The proposal should describe why the Incubator Repository meets the required conditions, who the sponsors are, hoped-for results of the Incubator Repository, the approximate number of people likely to be given check-in access through this process, and any possible effects on other parts of Mozilla.
• The proposal should also be filed as a bug and also posted in the relevant newsgroup.
• The sponsors are responsible for figuring out a reasonable system for getting code from the Incubator Repository into mozilla-central. “Reasonable” generally does not mean dropping six months of work on reviewers and asking for code review. Sponsors may meet this responsibility by using Mozilla code-review techniques in the Incubator Repository or by other means, but they are responsible for getting code review in reasonable increments.
• Anyone checking into an Incubator Repository must have signed a CVS Contributor Form on file with the Mozilla Foundation.
• Once approval for an Incubator Repository has been granted and recorded in the appropriate bug, the sponsor or Incubator participants should file a bug asking for commit access for that person for the Incubator Repository. Details on filing the bug and getting it closed are below.

Incubator Commit Access

Here’s a list of the steps that need to happen to get Incubator Commit Access.

1. Make sure the creation of the Incubator Repository to which you wish access has been approved.
2. File a bug. Product: mozilla.org; Component: CVS AccountRequest. Don’t change the Default Assignee or the Default QA Contact. Your summary should say something about creating an Incubator Account (“Incubator Account Request – John Doe <jdoe@example.com> “). You should also include in the bug a pointer to the earlier bug in which the creation of the Incubator Repository in question was approved.
3. Each of the two sponsors should comment in the bug saying s/he’s sponsoring the Incubator Repository and your participation in it.
4. Make sure to include your CVS SSH public key as an attachment to the bug. (Please mark it as text/plain when attaching it!) Note that you will need to attach an SSH key for all types of access.
5. Complete the Contribution Form and fax it to the location specified on the Form.
6. Update the bug to note that you’ve faxed in the Form.
7. An appropriate Mozilla representative will update the bug to say whether s/he has received the faxed Form.
8. Update the bug when all the needed info is in the bug. This way, Bugzilla can send off mail to the Mozilla representative tending to accounts.
9. The Mozilla representative will double-check that the needed info is recorded and, if so, create an account.
10. The Mozilla representative will then reassign the bug to IT to have your SSH public key added.
11. A Mozilla IT representative will update the bug with account creation information and close the bug.

For the last couple of years the Mozilla Corporation has organized and hosted an event known as the “Firefox Summit.” We’ve done this twice so far; once after the release of Firefox 1.5 and once after the release of Firefox 2. The Summits have been a gathering of the people most deeply involved in creating the just-released product, and likely to be deeply involved in the design and creation of the next version. The summits are part celebration, partly closure, and mostly planning and consensus building for the future efforts.

The Summits bring together a range of contributors, both volunteers and those employed by Mozilla and other organizations. The fundamental goals are to build closer bonds between contributors who rarely meet face to face, and to do serious planning and focusing for the future Firefox work (including the underlying platform). We also try to have some fun, of course. Mozilla funds participation — travel, lodging, food, etc — for our volunteers. Mozilla Corporation employees are expected to attend, others attend by invitation.

We’ll be having another Summit this July. This time we plan to expand the focus a bit to move beyond Firefox and the platform technologies that make work. The main focus will still be Firefox and the technology that underlies it — that’s still the key that so much of our vitality. This includes discussions about how our products and technologies can and should move the Mozilla vision forward. And we’ll undoubtedly have discussions about building strong communities, this is an element that runs through every Mozilla activity.

Eventually it would be great to have a broader Mozilla Summit, discussing not only our technology and products but also the range of other activities that the Mozilla project is, or should think about, undertaking. We’re not ready to plan and take that one quite yet, but it’s time to see if we can broaden the focus somewhat.

We’ll clearly broaden this to include Thunderbird, email, and Internet communications. That’s an official Mozilla product that shares our technology and the Mozilla mission. We’ll undoubtedly broaden this in other ways; mobile, Weave, data, and Prism are obvious candidates.

So while we’ll probably refer to this as the “Summit” or the “Firefox Summit,” its official, somewhat-awkward name is the Firefox Plus Summit. If we knew exactly the scope we could figure out a more precise name. I came up with this name to be clear about what we do know: most discussions in the context of Firefox, not completely Firefox, not aiming to cover the entire possible scope of the Mozilla project.

We’re just starting to plan for the Summit. This includes invitees, content, how to get the most input into the discussions and how to get the results dispersed to greater audiences. We hope to make progress in the next couple of weeks, and the bulk of the content development will happen as more and more people finish up their work on Firefox 3.

2008 is a year to celebrate — Mozilla turns 10 this year. 10 years of open source history, commitment, product development, community building and accomplishments. An open source project of astonishing scope and diversity. A portion of the Internet that is more open and participatory than almost anyone imagined. A strong voice for what the Internet can be. That’s 10 amazing years.

2008 is a year to celebrate our history, our accomplishments, our community and our future. We have laid the groundwork for another great 10 years — years where we can influence the web for the better, demonstrate what openness, transparency and broad participation look like, marvel at the distributed excitement and fierce dedication to the Mozilla vision for the Internet, and do things we haven’t even dreamed up yet.

I really do mean a year to celebrate. Not one day, not even the actual date the code was released. That’s an important date and we’ll certainly celebrate it. But the code release was one part of what was a much larger effort 10 years ago, and is a much larger story today. 1998 saw some great accomplishments, and we’ll celebrate them this year. The project has seen great accomplishments all through this first decade, and we should celebrate these as well.

I don’t have precisely formed ideas yet for how we ought to mark our anniversary events. In general though, I’m intent on making sure that our activities are:

a) International in scope: notable events that take place around the globe.

b) Participatory. We’ve had crate-your-own parties in the past; that’s a good start. ‘d like to see us do some other things as well this year. Perhaps we might have a way for people to record their experiences with some event in Mozilla’s history. Perhaps we will create a timeline where people can note the various events they feel have been critical to the Mozilla project (this is not my idea). These are only early ideas; there’s lots of room for creativity here.

c) Varied.

d) Fun.

If you’ve got ideas, let me know (or Mary Colvig — mary at mozilla dot com). We may come up with some other tools for making planning easier, but comments here are a good start.

As those of you who read planet.mozilla.org know, last weekend was the Mozilla24 event. A lot of people have written about Mozilla 24 and I won’t repeat a general description. The thing that struck me was the power that the infrastructure can bring, and how the infrastructure really can bring people closer. Typically in the Mozilla world we’re focused on software (obviously!). We recognize the critical nature of the underlying infrastructure that we live on but don’t spend our days building it as we do the software layer. And so the proposal for Mozilla 24 seemed daunting to me, given the massive amounts of infrastructure needed to provide real-time video conferencing across multiple continents. But Mozilla 24 was spear-headed by Mozilla Japan with the significant assistance Dr. Jun Morai. Dr. Morai is known as the “father of the Internet” of Japan, is a VP of Keio University, a member of ICANN and the Internet Society, and a long time friend of Mozilla Japan.

Dr. Morai is also the chairperson of the WIDE project which seeks to put this infrastructure to use for social benefit. I found Mozilla24 to be an eye-opening example of how powerful an idea this is. I attended the Mozilla24 event at Stanford University. It was a very nice facility — thank you Stanford! The room had 3 large screens. Generally one showed the presentation, another showed the audiences in other areas and the third often showed the Mozilla 24 photo stream. What surprised me was how strong the feeling was of “touching” and “seeing” the people in other locations. The images were good enough, the audio was good, and the transmission lag was so small as to be unnoticeable for much of the time. I participated in the last segment, which was the Kids” Summit, followed by a discussion with Dr. Morai and Dr. Cerf. It really was possible to have a discussion, to watch Dr. Morai, the discussion leader and feel as if he was “right there.” At one point Dr. Moral was speaking to the Kids’ Summit participants, suggesting we’d kept them long enough and it was fine for them to go home. After the children from Japan left he turned to the children from Thailand and suggested they were free to go as well. I thought to myself “Wow, I didn’t know the participants from Thailand had gone to Japan; I thought they were all at the University in Thailand.” But of course, they *were* in Thailand. Dr. Morai is simply so comfortable with this technology that it’s impossible to tell from watching him whether he’s talking to people in the same room or someone thousands of miles away.

Of course, Mozilla24 was an enormous amount of work. The Mozilla Japan team showed once again that they are masters of organization, and of bringing Mozilla DNA to well-organized, professional quality events. And the rest of the Mozilla world jumped in to make a rich program.

Mozilla24 has made it clear to me once again how Mozilla is part of a much larger effort to bring openness and participation to *all* levels of the Internet stack. It made me realize once again all the different things that the Mozilla community is and does.