Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
GovernanceIssues: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| (7 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
This is a list of | 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]. | 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]]. | Most of these issues are being tackled by [[User:Gerv|Gerv]]. | ||
== | ==Active== | ||
===Discussion Forums Changes=== | ===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 | 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] | * [http://groups.google.com/group/mozilla.governance/browse_thread/thread/7d418189694b88d1# mozilla.governance thread on mailing list spam] | ||
Status: [[Discussion_Forums/Proposal| | 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=== | ===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? | 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). | |||
Status: Gerv has access to the necessary Github APIs (for Github committers) and LDAP dump information (for existing Hg committers). | |||
Issue: | 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. | ||
===Stale Reviews=== | |||
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. | |||
* [http://spreadsheets.google.com/ccc?key=pcR-hFir9x0Pn-TxV3j2Zbg Spreadsheet mapping Bugzilla components to modules], prepared by Dirkjan Ochtman. | * [http://spreadsheets.google.com/ccc?key=pcR-hFir9x0Pn-TxV3j2Zbg Spreadsheet mapping Bugzilla components to modules], prepared by Dirkjan Ochtman. | ||
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. | |||
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: Implement those two bugs. | |||
===Non-Copyleft Licensing=== | |||
Issue: various parts of Mozilla have started using non-MPL licenses for new codebases. | |||
Proposal: Have discussion about formally permitting this, and then work out if we want to make the effort to switch over legacy codebases. | |||
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: 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. | ||
==Pending/On Hold== | |||
===Community Governance Reboot=== | |||
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. | |||
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: 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. | |||
===Commit Access Levels and GitHub=== | |||
Issue: How do we map our ideas of commit access levels onto the model used by GitHub, if at all? {{bug|760153}}. | |||
Proposal: We don't; let's just make sure everyone with direct commit access has signed the Committer's Agreement. | |||
===Change Bugzilla Workflow=== | ===Change Bugzilla Workflow=== | ||
| Line 41: | Line 78: | ||
Other suggestions: open up EXPIRED, or collapse EXPIRED, WONTFIX and INVALID into INACTIVE or some other word. | Other suggestions: open up EXPIRED, or collapse EXPIRED, WONTFIX and INVALID into INACTIVE or some other word. | ||
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. | |||
==Resolved== | ==Resolved== | ||
===Shouldn't-Be-Private Mailing Lists=== | |||
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. | |||
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. | |||
===Improve Module Owners List=== | ===Improve Module Owners List=== | ||
| Line 61: | Line 108: | ||
Status: program retired. | Status: program retired. | ||
===Trim Super-Reviewers List=== | ===Trim Super-Reviewers List=== | ||