Modules:Proposal: Difference between revisions
(Created page with 'This is a proposal for unifying the [http://www.mozilla.org/about/owners.html Module Owners List] and the associated [[Module_Owners_Activities_Modules| Activities Module Owners …') |
No edit summary |
||
| Line 3: | Line 3: | ||
At the moment, the Module Owners list is automatically generated from despot, our system for controlling access to the CVS repository we no longer use. Because editing despot is painful and only a few busy people have the necessary permissions, the list has had a tendency to get out of date, with "big bang" updates every few years when the pain of inaccuracy gets too great. | At the moment, the Module Owners list is automatically generated from despot, our system for controlling access to the CVS repository we no longer use. Because editing despot is painful and only a few busy people have the necessary permissions, the list has had a tendency to get out of date, with "big bang" updates every few years when the pain of inaccuracy gets too great. | ||
We need to strike a balance between easy updateability (vital if the list is to remain current) and reliability (i.e. it can't be corrupted by the unscrupulous or vandals). Other useful properties we are aiming for include: | |||
* extensibility (ability to add new fields) | * extensibility (ability to add new fields) | ||
* machine-parseability (e.g. for stale review reminders) | * machine-parseability (e.g. for stale review reminders) | ||
The idea is | The idea is that the list is maintained [[Modules|on a wiki]], using templates - which gives us the updateability, extensibility and machine-parseability. | ||
It can be edited by anyone with a wiki account. It uses two MediaWiki templates ([[Template:Code_Module|Code_Module]], [[Template:Activities_Module|Activities_Module]]) so that the markup in the editable copy is simply, understandable and hopefully machine-parseable. This also follows the principle of DRY. | |||
Then, with regards to reliability, there are two possible ways we could go: | |||
1. Someone (gerv) uses the wiki watch mechanism on the page, and does post-hoc review of changes. If bad changes are seen, they are quickly reverted; | |||
or | |||
2. A static copy of the list, to which people would link, is maintained on mozilla.org. At regular intervals, changes to the editable copy since the last sync are reviewed, and the data copied across. | |||
We (Gerv and Mitchell) think that the first way is sufficient. However, we note the second possibility because some people may want to argue for it. | |||
Revision as of 01:03, 14 July 2010
This is a proposal for unifying the Module Owners List and the associated Activities Module Owners List, and making them easier to maintain and so more likely to be up-to-date.
At the moment, the Module Owners list is automatically generated from despot, our system for controlling access to the CVS repository we no longer use. Because editing despot is painful and only a few busy people have the necessary permissions, the list has had a tendency to get out of date, with "big bang" updates every few years when the pain of inaccuracy gets too great.
We need to strike a balance between easy updateability (vital if the list is to remain current) and reliability (i.e. it can't be corrupted by the unscrupulous or vandals). Other useful properties we are aiming for include:
- extensibility (ability to add new fields)
- machine-parseability (e.g. for stale review reminders)
The idea is that the list is maintained on a wiki, using templates - which gives us the updateability, extensibility and machine-parseability.
It can be edited by anyone with a wiki account. It uses two MediaWiki templates (Code_Module, Activities_Module) so that the markup in the editable copy is simply, understandable and hopefully machine-parseable. This also follows the principle of DRY.
Then, with regards to reliability, there are two possible ways we could go:
1. Someone (gerv) uses the wiki watch mechanism on the page, and does post-hoc review of changes. If bad changes are seen, they are quickly reverted;
or
2. A static copy of the list, to which people would link, is maintained on mozilla.org. At regular intervals, changes to the editable copy since the last sync are reviewed, and the data copied across.
We (Gerv and Mitchell) think that the first way is sufficient. However, we note the second possibility because some people may want to argue for it.