Confirmed users
63
edits
Modules Scratchpad: Difference between revisions
Jump to navigation
Jump to search
ScratchPad for non-code modules
No edit summary |
(ScratchPad for non-code modules) |
||
| Line 1: | Line 1: | ||
Author: [mailto:stuart@mozilla.com | Author: [mailto:stuart@mozilla.com Mitchell Baker] | ||
== Background == | == Background == | ||
I've got an open bug to explore the extent to which we can use the principles of code modules and module ownership for non-coding activities. This is bug 363451. | |||
Recently Stuart did a massive clean-up and reorg of our code modules and module owners. [The list of current code modules is at [http://www.mozilla.org/owners.html http://www.mozilla.org/owners.html] As part of this Stuart compiled a list of potential non-code modules that we might think about. That list is below. Many, *many* thanks to Stuart for this work (the bug is mine, but Stuart did the initial work -- how great is that?) | |||
This is a preliminary brainstorming list. Some items on it might not make sense. There are undoubtedly other items which should be here but aren't. The purposes of this list are: | |||
to have some concrete examples to use when we start to evaluate application of code module ownership principles | |||
to get an idea of the scope of non-coding activities | |||
to think about which activities make sense as "modules," | |||
to start thinking about the granularity of non-code modules - which might mimic the toolkit example of one large module with sub-modules, which if any very specific activities should be separately identified; and | |||
to improve the list. | |||
The list below contains some code modules and some non-code modules and some that fall in between. Some of these modules are big areas while some are more specific and might even fall under a bigger module. I believe when to draw the line on if something is a module or not is when it becomes confusing if things aren't broken up. An example would be the tinderbox modules listed below. There are the tinderbox configs owned by one set of people while the tinderbox code itself is owned by someone else and the build machines someone else again. Separating them out makes it possible to find the right contact. I believe we may also want to have modules that contain submodules. Marketing would be a good example as there is one owner for general marketing issues but separate owners for various parts of marketing. | The list below contains some code modules and some non-code modules and some that fall in between. Some of these modules are big areas while some are more specific and might even fall under a bigger module. I believe when to draw the line on if something is a module or not is when it becomes confusing if things aren't broken up. An example would be the tinderbox modules listed below. There are the tinderbox configs owned by one set of people while the tinderbox code itself is owned by someone else and the build machines someone else again. Separating them out makes it possible to find the right contact. I believe we may also want to have modules that contain submodules. Marketing would be a good example as there is one owner for general marketing issues but separate owners for various parts of marketing. | ||