GovernanceIssues: Difference between revisions
(Initial list) |
No edit summary |
||
| Line 3: | Line 3: | ||
This is a list of open Mozilla community governance issues that Gerv may be attempting to resolve. | This is a list of open Mozilla community governance issues that Gerv may be attempting to resolve. | ||
==Open Issues== | |||
=== | ===Non-Code Modules=== | ||
Define what the modules are, and find owners for 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. | |||
* XXXPrevious discussions and work | |||
===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. | |||
* [http://groups.google.com/group/mozilla.governance/browse_thread/thread/8d63e16325a7366a# Mitchell's final posting]; there were several previous threads on different topics. It notes that the Dormant Accounts section is a placeholder. | |||
* [http://groups.google.com/group/mozilla.governance/browse_thread/thread/625d7bba7ef3f263# 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? | Which policies apply to which repositories? Do we want to harmonise? | ||
* [https://wiki.mozilla.org/Commit_Policy:Current_Procedures reed's long list of what happens now] | |||
Next Steps: read that list 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'. | |||
* [http://groups.google.com/group/mozilla.governance/browse_thread/thread/d142e16757257f25# 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=== | ===Module Owners List=== | ||
Make it hackable, parseable, easier to maintain and therefore more accurate. | Make it hackable, parseable, easier to maintain and therefore more accurate. | ||
* [http://www.mozilla.org/owners.html Current, despot-generated list] | |||
Next Steps: get consensus on switching list format. (dmose very much in favour.) Create initial wiki version using templates. | |||
===Stale Reviews=== | ===Stale Reviews=== | ||
| Line 43: | Line 50: | ||
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. | 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. | ||
==Committer's Agreement=== | * [http://spreadsheets.google.com/ccc?key=pcR-hFir9x0Pn-TxV3j2Zbg 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. | 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. | |||
* [http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/68685672ffb76f6b/37cf986d3962a47 thread in mozilla.dev.planning on moving the meeting time] | |||
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. | |||
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=mozilla.org&component=Governance&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=---&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= List of open mozilla.org/Governance bugs] (<strike>24</strike> 18 at time of writing) | |||
Next Steps: triage ongoing. | |||
===Discussion Forums=== | ===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. | 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. | ||
* [http://groups.google.com/group/mozilla.governance/browse_thread/thread/7d418189694b88d1# 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. | |||
* [http://groups.google.com/group/mozilla.governance/browse_thread/thread/1c7c826dca44043c# Mike's latest draft] | |||
== Open Issues== | |||
* Is there a "review policy" item, other than the one above? | |||
Revision as of 16:50, 12 June 2009
This is a list of open Mozilla community governance issues that Gerv may be attempting to resolve.
Open Issues
Non-Code Modules
Define what the modules are, and find owners for 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.
- XXXPrevious discussions and work
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?
Next Steps: read that list 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.
Next Steps: get consensus on switching list format. (dmose very much in favour.) Create initial wiki version using templates.
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.
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 (
2418 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.
Next Steps: start discussion with IT about technical options.
Being Resolved
Super-Review Policy
mconnor is working on updating the super-review policy.
Open Issues
- Is there a "review policy" item, other than the one above?