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
Disable Dormant SCM Accounts
Issue: We have many source code management system accounts which are no longer used. This increases our security attack surface.
So Far: We have a policy, code to generate a list of dormant accounts, and an initial list.
Next Steps: Waiting on LDAP infrastructure changes.
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.
So Far: A draft of a unified policy has gone out for feedback, and received it.
Next Steps: Final sign-off on policy; waiting for LDAP infrastructure changes.
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.
So Far: Lots of calls to sign it issued, and most people have responded. Dormat accounts were filtered out of the list, and the remaining small group re-pinged.
Next Steps: waiting for LDAP infrastructure changes.
Governance Bug Triage
Issue: There are numerous open bugs in the Governance component in Bugzilla, which need to be triaged and, where possible, resolved.
So Far: Open bug count reduced from 24 to 7.
Next Steps: triage ongoing.
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
So Far: Timing has been changed; Ten Forward has been rearranged; Gerv has written guidance; Jono is the new host and is making many other changes.
Next Steps: Asa has a plan for making technical improvements in the next three months (to March). This should give us better lighting, sound and video.
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?
"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
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", "AMO", "Mozilla Style Guide", "Transparency".
Next Steps: Mitchell to propose a module for Community Metrics.
On Hold
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.
Next Steps: reconsider objections raised. Try and get consensus on switching list format. (dmose very much in favour.)
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.
Next Steps: blocked on above. Then add mapping to list, and write nagging scripts.
Discussion Forums Technical Refresh
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.
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.
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: 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.
Next Steps: contact the owners of possibly-concerning lists, and ask them politely about the purpose of their list and whether public would be a better option.
Proposed
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.
Resolved
Update Super-Review Policy
Issue: super-review policy is out of date. mconnor is updating it.
Resolution: mconnor updated the super-review policy.