GovernanceIssues

This is a list of open Mozilla community governance issues. Please add suggestions to the scratchpad.

We also have a page listing existing policies.

Most of these issues are being tackled by Gerv.

Open Issues

Discussion Forums Changes

There are several issues with the current technical implementation - primarily spam, but also 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

Status: Plan written, bug filed. We now have 10 or 12 groups switched over, and a contact with Google, but we aren't quite there yet - there are unresolved problems with how the moderation is working. rbryce in IT is actively working on improving the situation.

Next Steps: wait for rbryce to report back.

Mozilla Code Not In Our Repos

Issue: recently, Mozilla community members have been storing Mozilla code in repos other than ours (e.g. github, Google Code). Is this a concern from a community, technical or a legal point of view?

Next Steps: None planned at the moment.

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

Status: Bugzilla now whines about outstanding requests on a weekly basis, and data is being captured to see if this has significant effect on the queue.

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

Other suggestions: open up EXPIRED, or collapse EXPIRED, WONTFIX and INVALID into INACTIVE or some other word.

Status: there are two proposals - a safe-ish one and a more radical one. Just waiting for Gerv to have time to push 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.

Actions: Gerv wrote a small script to extract a list of possibly-concerning mailing lists from mailman. He has had several iterations of the list from mzeier, refining the script each time.

Status: an initial look suggested that this was not a big problem. Although the analysis was not exhaustive, it was sufficient.

Pending

Commit Access Levels and GitHub

How do we map our ideas of commit access levels onto the model used by GitHub, if at all? bug 760153.

Resolved

Improve 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)
• document from Dan on the MailNews review system, which include modules and owners.

Status: new system built, data migrated, owners.html redirected.

Retire Incubator Program

Issue: the incubator program, for creating new Hg repos for collaborating with outside coders, was useful when getting access to our tree was hard. Due to the new Commit Access Policy, it's now much easier, so Stuart agreed with my suggestion that we could wind this program down.

Related bugs: bug 478387, bug 466552

Status: program retired.

Trim Super-Reviewers List

It has been suggested that there remain some people on the super-reviewers list who do not have sufficient recent activity on the project to continue in that role. So, in consultation with Brendan, the list could be trimmed (further; it was trimmed a bit recently).

Status: list reviewed, candidates identified, checked with Brendan, 2 people removed.

Harmonize and Simplify Commit Access Policy

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

Status: new Commit Access Policy written and implemented, and infrastructure updated to match.

Switch To New 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.

Status: List of people made; big efforts over the past two years to get people to sign; ultimatum issued and deadline passed. List of delinquents made and accounts disabled.

Governance 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

Status: Open bug count reduced from 24 to 3. This is no longer an "issue"; the remaining bugs have owners, and Gerv will triage incoming ones.

Disable Dormant SCM Accounts

Issue: We have many source code management system accounts which are no longer used. This increases our security attack surface.

Status: Done; 400+ accounts disabled, only a couple erroneously :-)

Monday Meeting

Issue: the Monday meeting is having an identity crisis. Clarify the purpose and most useful content 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

Status: Done; timing has been changed; Ten Forward has been rearranged; Gerv has written guidance; Jono is the new host and is making many other changes. Meetings are now fairly awesome.

Create More 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

"We should create modules when there is a specific level of responsibility, authority and decision making that it would be helpful to invest in a person." - Mitchell

"We should make modules to unambiguously place an activity in the arena of stuff which we apply open source and transparent principles to." - Gerv

Status: A number of modules have been proposed and created; Mitchell will create more as she feels the need.

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

Regular Governance Tasks

Some issues need revisiting on a regular basis, perhaps once a year. This is a (doubtless incomplete) list:

• Update super-reviewers list
• Check for shouldn't-be-private mailing lists
• Disable dormant SCM accounts (note: last-used dates for SCM accounts are tracked by IT in LDAP)