GovernanceIssues: Difference between revisions

← Older edit

GovernanceIssues (view source)

Revision as of 13:07, 3 September 2013

4,058 bytes added , 3 September 2013

no edit summary

Gerv

Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti

4,925

edits

@@ Line 1: / Line 1: @@
 __NOTOC__
-This is a list of open Mozilla community governance issues. Please add suggestions to the [[GovernanceIssues/Scratchpad|scratchpad]].
+This is a list of Mozilla community governance issues. Please add suggestions to the [[GovernanceIssues/Scratchpad|scratchpad]].
 We also have a page listing [http://www.mozilla.org/about/policies/ existing policies].
@@ Line 6: / Line 6: @@
 Most of these issues are being tackled by [[User:Gerv|Gerv]].
-==Open Issues==
+==Active==
-===Disable Dormant SCM Accounts===
+===Discussion Forums Changes===
+Issue: There are several issues with the current technical implementation of our discussion forums - primarily spam, but also the unresponsiveness of Google re: Google Groups and so on.
+Proposal: We should look at alternative technical options.
+* [[Discussion_Forums/Problem_Statement|Problem Statement]]
+* [http://groups.google.com/group/mozilla.governance/browse_thread/thread/7d418189694b88d1# mozilla.governance thread on mailing list spam]
+Status: There have been [[Discussion_Forums/Proposal|plans in the past]], which have got derailed by lack of IT time. Community IT is now [https://wiki.mozilla.org/IT/Community/WG/Discourse standing up] an [http://discourse.mozilla-community.org/ instance] of [http://www.discourse.org/ Discourse] which we hope to evaluate and use as a gradual replacement for the current system.
+Next Steps: Test Discourse instance.
+===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?
+Proposal: Require people with direct access to our Github repos to sign the Committer's Agreement (who haven't signed it already).
-Issue: We have many source code management system accounts which are no longer used. This increases our security attack surface.
+Status: Gerv has access to the necessary Github APIs (for Github committers) and LDAP dump information (for existing Hg committers).
-So Far: We have a [http://groups.google.com/group/mozilla.governance/msg/73389b3f4c4f5de9 policy], [http://hg.mozilla.org/users/gerv_mozilla.org/active-accounts/ code to generate a list of dormant accounts], and an initial list.
+Next Steps: Gerv needs to write code to reconcile and match people across those two data sources. Then we need to contact all the people who haven't signed the agreement yet and ask them to.
-Next Steps: Waiting on LDAP infrastructure changes.
+===Stale Reviews===
-===Harmonize and Simplify Commit Access Policy===
+Issue: Some review requests remain open and unloved in Bugzilla. This is bad for the (often new) contributors who make patches and see them ignored.
-Issue: Our commit access policies are currently very diverse. We should harmonize them and make them consistent, understandable and easy to implement.
+* [http://spreadsheets.google.com/ccc?key=pcR-hFir9x0Pn-TxV3j2Zbg Spreadsheet mapping Bugzilla components to modules], prepared by Dirkjan Ochtman.
-* [https://wiki.mozilla.org/Commit_Policy:Current_Procedures reed's long list of what happens now]
+Status: Bugzilla started whining about outstanding requests on a weekly basis, and data was captured to see if this has significant effect on the queue. It had some effect, but we then levelled off and have since been slowly creeping back upwards. Bugzilla now bans reviews requested "of the wind", and suggests appropriate reviewers for review requests.
-So Far: A [[Commit_Access_Policy|draft]] of a unified policy has gone out for feedback, and received it.
+On 24th August 2013, a patch was committed to Bugzilla so that Bugzilla now tracks the day a person was last seen. That will allow us to implement {{bug|751862}} (ban requests from requestees who haven't been around for ages) and {{bug|751863}} (cancel requests of requestees who have not been around for ages).
-Next Steps: Final sign-off on policy; waiting for LDAP infrastructure changes.
+Next Steps: Implement those two bugs.
-===Switch To New Committer's Agreement===
+===Non-Copyleft Licensing===
-Issue: Transition to the new agreement by nagging those who have not signed and eventually disabling accounts.
+Issue: various parts of Mozilla have started using non-MPL licenses for new codebases.
-* There is a private Google Docs spreadsheet tracking the progress.
+Proposal: Have discussion about formally permitting this, and then work out if we want to make the effort to switch over legacy codebases.
-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.
+Status: after consultation and discussion, it was agreed that the Apache License 2.0 would be an option maintainers could choose in some circumstances for new codebases. The licensing policy was updated accordingly.
-Next Steps: waiting for LDAP infrastructure changes.
+Next Steps: Decide if we want to try and get some existing BSD-using codebases or frameworks switched over. There's [[License_Policy/Mozilla_Project_Licensing|a list]] of which projects use what. The Playdoh framework is an obvious candidate.
-===Governance Bug Triage===
+==Pending/On Hold==
-Issue: There are numerous open bugs in the Governance component in Bugzilla, which need to be triaged and, where possible, resolved.
+===Community Governance Reboot===
-* [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]
+Issue: the Module Ownership system does not cover all of the activities that Mozilla now engages in. This means that the MoCo org chart is the ''de facto'' governance structure, which makes it impossible for non-employees to take on positions of responsibility.
-So Far: Open bug count reduced from 24 to 7.
+Status: An [[Activity_Map]] was built in January and February to map out all the things Mozilla does, so we can see where community governance needs to be put in place. (It may need reviewing and updating when this project restarts.)
-Next Steps: triage ongoing.
+Next Steps: We need to decide what the future governance structure will look like, in broad terms, before we go ahead and try and create it. It will, at heart, involve Putting People In Charge Of Stuff, but there are a number of ways that can be achieved.
-===Monday Meeting===
+===Commit Access Levels and GitHub===
-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.
+Issue: How do we map our ideas of commit access levels onto the model used by GitHub, if at all? {{bug|760153}}.
-* [http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/68685672ffb76f6b/37cf986d3962a47 thread in mozilla.dev.planning on moving the meeting time]
+Proposal: We don't; let's just make sure everyone with direct commit access has signed the Committer's Agreement.
-* [https://wiki.mozilla.org/Community_Calendar Community Calendar]
-* [http://groups.google.com/group/mozilla.dev.planning/msg/89fa03e13375ae9f dria's summary of the meeting's purpose]
-So Far: Timing has been changed; Ten Forward has been rearranged; Gerv has written [[WeeklyUpdates/Guidance|guidance]]; Jono is the new host and is making many other changes.
+===Change Bugzilla Workflow===
-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.
+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.
-===Create More Non-Code ("Activities") Modules===
+* [http://steelgryphon.com/testcases/bugzilla-workflow-9.png mconnor's proposal]
+* [[BugzillaWorkflowImprovements|Wiki page of ideas]], discussion and links
+* [https://bugzilla.mozilla.org/show_bug.cgi?id=264721 Bug on adding 'READY' state] to b.m.o.
-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?
+Other suggestions: open up EXPIRED, or collapse EXPIRED, WONTFIX and INVALID into INACTIVE or some other word.
-* [https://wiki.mozilla.org/Module_Owners_Activities_Modules List of existing Activities Modules]
+Status: there are two proposals - a [[BMO/Workflow_Proposal|safe-ish one]] and a [[BMO/Workflow_Proposal_2|more radical one]]. lhenry, the new Bugmaster, is evaluating which (if either) of these proposals is worth pushing.
-* [http://groups.google.com/group/mozilla.governance/browse_thread/thread/208ee06876dc8517# 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
+==Resolved==
-"We should make modules to unambiguously place an activity in the arena of stuff which we apply open source and transparent principles to." - Gerv
+===Shouldn't-Be-Private Mailing Lists===
-So Far: A call for ideas was issued; the following proposals were made: [http://groups.google.com/group/mozilla.governance/msg/3594d1e366ed64c5 Websites] (David Boswell), [http://groups.google.com/group/mozilla.governance/msg/fc99b634c1c0b628 Education] (Gervase Markham). Other suggestions that have been made in the past include "Events and Speaking", "AMO", "Mozilla Style Guide", "Transparency".
+Issue: Mozilla runs a large number of mailing lists, as well as our public [http://www.mozilla.org/community/developer-forums.html discussion forums]. We should audit that list to make sure no project discussion is private when it should be (at least) read-only public.
-Next Steps: Mitchell to propose a module for Community Metrics.
+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.
-==On Hold==
+Status: an initial look suggested that this was not a big problem. Although the analysis was not exhaustive, it was sufficient.
 ===Improve Module Owners List===
@@ Line 81: / Line 97: @@
 * [http://www.mozilla.org/owners.html Current, despot-generated list]
 * [http://groups.google.com/group/mozilla.governance/browse_thread/thread/86e8bc621062a8b6# Module Owners List Action Plan] from mitchell (July 2008 :-( - some objections were raised)
-* [http://www.mozilla.org/mailnews/review.html Two] [http://www.mozilla.org/mailnews/review-mail.html documents] from Dan on the MailNews review system, which include modules and owners.
+* [https://developer.mozilla.org/en/Mailnews_and_Mail_code_review_requirements 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: [http://blog.lizardwrangler.com/2008/06/06/incubator-repositories-proposal/ 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 [http://www.mozilla.org/hacking/commit-access-policy/ 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 [http://www.mozilla.org/hacking/reviewers.html 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.
+* [[Commit Policy:Current Procedures|reed's long list of what happens now]]
+Status: [http://www.mozilla.org/hacking/commit-access-policy/ 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.
-Next Steps: reconsider objections raised. Try and get consensus on switching list format. (dmose very much in favour.)
+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.
-===Triage Stale Reviews===
+===Governance Bug Triage===
-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.
+Issue: There are numerous open bugs in the Governance component in Bugzilla, which need to be triaged and, where possible, resolved.
-* [http://spreadsheets.google.com/ccc?key=pcR-hFir9x0Pn-TxV3j2Zbg Spreadsheet mapping Bugzilla components to modules], prepared by Dirkjan Ochtman.
+* [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]
-Next Steps: blocked on above. Then add mapping to list, and write nagging scripts.
+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.
-===Discussion Forums Technical Refresh===
+===Disable Dormant SCM Accounts===
-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.
+Issue: We have many source code management system accounts which are no longer used. This increases our security attack surface.
-* [http://groups.google.com/group/mozilla.governance/browse_thread/thread/7d418189694b88d1# mozilla.governance thread on mailing list spam]
+Status: Done; 400+ accounts disabled, only a couple erroneously :-)
-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.
+===Monday Meeting===
-===Shouldn't-Be-Private Mailing Lists===
+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.
-Issue: Mozilla runs a large number of mailing lists, as well as our public [http://www.mozilla.org/community/developer-forums.html discussion forums]. We should audit that list to make sure no project discussion is private when it should be (at least) read-only public.
+* [http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/68685672ffb76f6b/37cf986d3962a47 thread in mozilla.dev.planning on moving the meeting time]
+* [https://wiki.mozilla.org/Community_Calendar Community Calendar]
+* [http://groups.google.com/group/mozilla.dev.planning/msg/89fa03e13375ae9f dria's summary of the meeting's purpose]
-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.
+Status: Done; timing has been changed; Ten Forward has been rearranged; Gerv has written [[WeeklyUpdates/Guidance|guidance]]; Jono is the new host and is making many other changes. Meetings are now fairly awesome.
-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.
+===Create More Non-Code ("Activities") Modules===
-==Proposed==
+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?
-===Change Bugzilla Workflow===
+* [https://wiki.mozilla.org/Module_Owners_Activities_Modules List of existing Activities Modules]
+* [http://groups.google.com/group/mozilla.governance/browse_thread/thread/208ee06876dc8517# Discussion thread on the "Policies" activities module]
-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.
+"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
-* [http://steelgryphon.com/testcases/bugzilla-workflow-9.png mconnor's proposal]
+"We should make modules to unambiguously place an activity in the arena of stuff which we apply open source and transparent principles to." - Gerv
-* [[BugzillaWorkflowImprovements|Wiki page of ideas]], discussion and links
-* [https://bugzilla.mozilla.org/show_bug.cgi?id=264721 Bug on adding 'READY' state] to b.m.o.
-==Resolved==
+Status: A number of modules have been proposed and created; Mitchell will create more as she feels the need.
 ===Update Super-Review Policy===
@@ Line 128: / Line 175: @@
 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)