Modules and Module Ownership: Difference between revisions
(New page: Modules and Module Ownership The Mozilla project operates under the principle of distributed authority, combined with an identified ultimate decision maker should escalation be required....) |
No edit summary |
||
| Line 3: | Line 3: | ||
The Mozilla project operates under the principle of distributed authority, | The Mozilla project operates under the principle of distributed authority, | ||
combined with an identified ultimate decision maker should escalation be | combined with an identified ultimate decision maker should escalation be | ||
required. We do this through our [ | required. We do this through our [http://www.mozilla.org/hacking/module-ownership.html Module Ownership system] which we've used officially with code for many years. This system was initially described in early policy documents from the 1990s and remains our basic organizing and operational principle for the project. | ||
Today the Mozilla project encompasses many activities beyond writing code. | Today the Mozilla project encompasses many activities beyond writing code. | ||
| Line 9: | Line 9: | ||
system. | system. | ||
The list of | The list of [http://www.mozilla.org/owners.html Module Owners for code modules] is auto-generated from one of our databases known as "despot.mozilla.org". | ||
The | The list of [[Module_Owners_Activities_Modules|Module Owners for Activities modules]] is maintained manually as a wiki page. | ||
There is also a list of[[ | There is also a list of [[Modules_Scratchpad|potential Activities Modules]] that a contributor compiled in 2007. There are many activities on that list that we might decide are more like job functions than project roles, but I'm not sure yet. I'm hoping we can derive some guiding principles as we look at the early Activities Modules. | ||
Revision as of 22:32, 27 May 2008
Modules and Module Ownership
The Mozilla project operates under the principle of distributed authority, combined with an identified ultimate decision maker should escalation be required. We do this through our Module Ownership system which we've used officially with code for many years. This system was initially described in early policy documents from the 1990s and remains our basic organizing and operational principle for the project.
Today the Mozilla project encompasses many activities beyond writing code. We're slowly bringing those activities into the official Module Ownership system.
The list of Module Owners for code modules is auto-generated from one of our databases known as "despot.mozilla.org".
The list of Module Owners for Activities modules is maintained manually as a wiki page.
There is also a list of potential Activities Modules that a contributor compiled in 2007. There are many activities on that list that we might decide are more like job functions than project roles, but I'm not sure yet. I'm hoping we can derive some guiding principles as we look at the early Activities Modules.