GovernanceIssues

This is a list of open Mozilla community governance issues that Gerv may be attempting to resolve.

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

Open Issues

Non-Code ("Activities") Modules

Whether we need any more modules of this sort, and who might own them. Work out what makes a good module, and who makes a good module owner. Mark says: make sure it's not just a mirror of Mozilla staffing structure, and not just an addition to a job title. Examples: SFX, mozilla.org (content vs. technical split?).

Also contains the question of whether we need to separate policy creation and implementation.

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

Next Steps: create list of possible additional modules.

Commit Access Policies: Dormant Accounts

Mitchell drove through the main part of the policy for the core repositories, but work remains to be done on dormant accounts.

• Mitchell's final posting; there were several previous threads on different topics. It notes that the Dormant Accounts section is a placeholder.
• Thread on dormant accounts

Next Steps: investigate what is technically feasible. Draft language for dormant accounts.

Commit Access Policies: Harmonization

Which policies apply to which repositories? Do we want to harmonise?

• Initial email from Mitchell
• reed's long list of what happens now

Next Steps: work with reed to make sure the list is complete. Read it carefully and make a proposal.

Other Module Ownership Issues

The discussion at the all-hands brought up issues other than non-code modules, such as whether some modules were too big, and whether we need to actively search for 'outside peers'.

• Mark's summary of all-hands discussion on module ownership

Next Steps: get Mitchell's opinion on whether any issues in Mark's summary are worth chasing up.

Module Owners List

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

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.

Committer's Agreement

Finish the 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.

Next Steps: send email to all who have not signed, this time giving a deadline after which accounts will be disabled.

Monday Meeting

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

Next Steps: Reopen discussion on the purpose of the meeting.

Bug Triage

Go through open governance bugs and attempt to resolve - either immediately, or via this list. At the moment, it doesn't look like there's anything major on there.

• List of open mozilla.org/Governance bugs (24 18 at time of writing)

Next Steps: triage ongoing.

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: start discussion with IT about technical options.

Being Resolved

Super-Review Policy

mconnor is working on updating the super-review policy.

• Mike's latest draft

Open Issues

• Is there a "review policy" item, other than the one above?