GovernanceIssues

This is a list of open Mozilla community governance issues that Gerv is working on.

We have a page listing existing policies (may need updating).

Open Issues

Non-Code ("Activities") Modules

Issue: Do we need any more Activities modules? Who might own them? We should work out what makes a good module, and who makes a good module owner. Possible examples: SFX, mozilla.org (content vs. technical split?). Do we need to separate policy creation and implementation?

• List of existing Activities Modules
• Discussion thread on the "Policies" activities module

So Far: A call for ideas was issued; the following proposals were made: Websites (David Boswell), Education (Gervase Markham). Other suggestions that have been made in the past include "Events and Speaking".

Next Steps: discuss with Mitchell.

Commit Access Policies: Dormant Accounts

Issue: We have many SCM accounts which are no longer used. This increases our security attack surface.

So Far: We now have a policy, and we are in the middle of implementing it. Scripts have been written to extract the dormant list, and refined based on a first round of feedback.

Next Steps: get updated list of active accounts from IT; disable inactive accounts.

Commit Access Policies: Harmonization

Issue: Our commit access policies are currently very diverse. We should harmonize them and make them consistent, understandable and easy to implement.

• reed's long list of what happens now

So Far: Gerv has assessed the current state of things, and written a draft of a unified policy.

Next Steps: public review (ongoing).

Committer's Agreement

Issue: Transition to the new agreement by nagging those who have not signed and eventually disabling accounts.

• There is a private Google Docs spreadsheet tracking the progress.

So Far: Since summer 2008 lots of calls to sign the new one have been issued, and many people have moved over. An ultimatum was issued and the deadline given in that ultimatum has now passed. We are now moving on to disabling the SCM accounts of those who have not signed the new agreement.

Next Steps: blocked on dormant accounts work - getting a final list here will allow us to reduce the list to active untransitioned people. We can then disable those accounts.

Bug Triage

Issue: There are numerous open bugs in the Governance component in Bugzilla, which need to be triaged and, where possible, resolved.

• List of open mozilla.org/Governance bugs

So Far: Open bug count reduced from 24 to 7.

Next Steps: triage ongoing.

Monday Meeting

Issue: Clarify the purpose of the meeting, and determine whether the current timing is optimal.

• thread in mozilla.dev.planning on moving the meeting time
• Community Calendar
• dria's summary of the meeting's purpose

So Far: Timing has been moved. Gerv has had discussions with surman and beltzner about possible improvements to content and format.

Next Steps: Gerv is working on a proposal for change.

On Hold

Discussion Forums

There are several issues with the current technical implementation - the unresponsiveness of Google re: Google Groups and so on. Need to look at whether to take the web interface part back in house, and/or put in place other anti-spam measures.

• mozilla.governance thread on mailing list spam

Next Steps: it doesn't look like there's a suitable alternative web interface out there. :-( So it's hard to see how to proceed.

Module Owners List

Issue: it's often out of date, because it's maintained through despot, which takes a lot of work. We would like to make it hackable, parseable, easier to maintain and therefore more accurate.

• Current, despot-generated list
• Module Owners List Action Plan from mitchell (July 2008 :-( - some objections were raised)
• Two documents from Dan on the MailNews review system, which include modules and owners.

Next Steps: reconsider objections raised. Try and get consensus on switching list format. (dmose very much in favour.)

Stale Reviews

Issue: Review requests remain open and unloved in Bugzilla. This is bad for the (often new) contributors who make patches and see them ignored. Fixing the Module Owners List and mapping it to Bugzilla components allows us to nag module owners about their reviews - cancel, do or delegate.

• Spreadsheet mapping Bugzilla components to modules, prepared by Dirkjan Ochtman.

Next Steps: blocked on above. Then add mapping to list, and write nagging scripts.

Governance Community

Issue: The community of people discussing governance issues itself could do with broadening and expanding. Too often, those most affected by governance decisions do not take part in the formulation of policy. Why is this?

Shouldn't-Be-Private Mailing Lists

Issue: Mozilla runs a large number of mailing lists, as well as our public discussion forums. We should audit that list to make sure no project discussion is private when it should be (at least) read-only public.

So Far:

Proposed

Bugzilla Workflow

Issue: the current Bugzilla workflow may not be optimal for the Mozilla project. Now that it's configurable in Bugzilla, we could have a discussion about what is best, implement it in the software, and educate the community to use the new workflow.

• mconnor's proposal
• Wiki page of ideas, discussion and links
• Bug on adding 'READY' state to b.m.o.

Revise MPL

Issue: the MPL has a number of features which are inconvenient from a practical perspective. An update to the MPL could e.g. remove some of the more pointless notification requirements. We should also retire MPL 1.0 with the OSI.

Resolved

Super-Review Policy

Issue: super-review policy is out of date. mconnor is updating it.

• Mike's latest draft

Resolution: mconnor updated the super-review policy.