Modules Scratchpad: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(ScratchPad for non-code modules)
No edit summary
Line 1: Line 1:
Author: [mailto:stuart@mozilla.com Mitchell Baker]
Author: Mitchell Baker
== Background ==
== Background ==


Line 7: Line 7:




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:
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.  If you see something where you think you're the obvious owner, don't get upset if there's no owner; Stuart did a bit of initial work, this isn't intended to be everything we know.  It's a starting point. 


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 have some concrete examples to use when we start to evaluate application of code module ownership principles


to think about which activities make sense as "modules,"  
** 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 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.   
** to improve the list.   




The list below actually contains some suggested code modules where we didn't have any ("tinderbox webtool code"),  some non-code modules and some that fall in between.  Some of these modules are big areas while some are more specific so it's possible to know the correct contact; the tinderbox modules are an example of specificity.  We may also want to have modules that contain submodules. 


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.
Feel free to note things you believe could be a module, who might own it and a description of what you believe that module covers.  For now I suggest aiming at big chunks of activities that might be missing.


What I'm looking for here is anything you believe could be a module, who might own it (or it may be unowned, as is the case for some of the code modules) and a description of what you believe that module covers.


Some of the modules here are internal only and some are external.  I've separated them in to separate sections where I think it is clear that they are really internal only but if you believe they aren't feel free to move them and note why.  Both are fine to list here as I think having accurate lists will help people on both sides.


== External ==
== Modules ==


* '''tinderbox config/release config'''
* '''tinderbox config/release config'''
Line 65: Line 66:
* '''PR'''
* '''PR'''
** Owners:  
** Owners:  
** Notes: inbound request about security issue or whatever. Who can speak for mozilla?
** Notes:  


* '''mozilla.com website'''
* '''mozilla.com website'''
Line 87: Line 88:


* '''community marketing'''
* '''community marketing'''
** Owners: asa
** Owners:  
** Notes: reaching out to firefox users to get more users
** Notes:  


* '''website localizations'''
* '''website localizations'''
Line 100: Line 101:


* '''mozilla store'''
* '''mozilla store'''
** Owners: beard/foundation/marcia
** Owners: beard/foundation/
** Notes: run by the foundation
** Notes: run by the foundation
** Directories: http://store.mozilla.org
** Directories: http://store.mozilla.org
Line 209: Line 210:
** Directories:  
** Directories:  


* '''linux distro stuff'''
* '''linux distro topics'''
** Owners:  
** Owners:  
** Notes:  
** Notes:  
Line 249: Line 250:
** Notes: application graphics, icons, etc., Might have an internal component.
** Notes: application graphics, icons, etc., Might have an internal component.


== Internal ==
* '''event coordination'''
 
** Owners: Mary Colvig
* '''legal'''
** Owners: Mitchell, Lilly, Catherine Brady
** Notes:  
** Notes:  
** Directories:
** Directories:
 
* '''marcom (design firms, etc)'''
** Owners:
** Notes:
** Directories:
 
* '''advertising'''
** Owners:
** Notes: adwords, etc
** Directories:
 
* '''events/event coordination'''
** Owners:
** Notes:

Revision as of 22:23, 7 June 2007

Author: Mitchell Baker

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 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. If you see something where you think you're the obvious owner, don't get upset if there's no owner; Stuart did a bit of initial work, this isn't intended to be everything we know. It's a starting point.

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 actually contains some suggested code modules where we didn't have any ("tinderbox webtool code"), some non-code modules and some that fall in between. Some of these modules are big areas while some are more specific so it's possible to know the correct contact; the tinderbox modules are an example of specificity. We may also want to have modules that contain submodules.

Feel free to note things you believe could be a module, who might own it and a description of what you believe that module covers. For now I suggest aiming at big chunks of activities that might be missing.


Modules

  • tinderbox config/release config
    • Owners: preed, rhelmer
    • Notes:
    • Directories: mozilla/tools/tinderbox, mozilla/tools/tinderbox-configs
  • tinderbox webtool code
    • Owners: morgamic?
    • Notes:
    • Directories: mozilla/webtools/tinderbox
  • build machines
    • Owners: preed, rhelmer
    • Notes:
    • Directories:
  • sunbird
    • Owners:
    • Notes:
    • Directories:
  • lightning
    • Owners:
    • Notes:
    • Directories:
  • camino
    • Owners: Stuart Morgan, Mike Pinkerton
    • Notes:
    • Directories: mozilla/camino
  • product l10n
    • Owners:
    • Notes:
  • PR
    • Owners:
    • Notes:
  • mozilla.com website
    • Owners: pkim
    • Notes:
    • Directories:
  • mozilla.org website
    • Owners:
    • Notes: has despot module already
    • Directories:
  • mpl
    • Owners:
    • Notes:
    • Directories:
  • press
    • Owners:
    • Notes:
  • community marketing
    • Owners:
    • Notes:
  • website localizations
    • Owners: pascal
    • Notes:
    • Directories:
  • partner relations
    • Owners:
    • Notes:
  • branding
    • Owners: beard
    • Notes: logos, branding guidelines, agreements, permissions
    • Directories:
  • spreadfirefox
    • Owners: asa
    • Notes:
    • Directories:
  • addons.mozilla.org
    • Owners: shaver
    • Notes:
    • Directories:
  • mozilla-europe.org
    • Owners: tristan
    • Notes:
    • Directories:
  • foxkeh.jp
    • Owners: kaori
    • Notes: Mozilla Japan character mascot website
    • Directories: http://foxkeh.jp/
  • community giving
    • Owners: sethb
    • Notes: providing resources to community to remove barriers to make peoples work easier
    • Directories:
  • build
    • Owners:
    • Notes:
    • Directories:
  • product management
    • Owners:
    • Notes:
    • Directories:
  • QA
    • Owners:
    • Notes:
    • Directories:
  • release testing
    • Owners:
    • Notes:
    • Directories:
  • manual testing
    • Owners:
    • Notes:
    • Directories:
  • automation testing
    • Owners:
    • Notes:
    • Directories:
  • testing infrastructure
    • Owners:
    • Notes:
    • Directories:
  • release management
    • Owners:
    • Notes:
    • Directories:
  • security
    • Owners:
    • Notes:
    • Directories:
  • documentation
    • Owners:
    • Notes:
    • Directories:
  • developer tools
    • Owners:
    • Notes: dom inspector, etc
    • Directories:
  • webtools (general)
    • Owners:
    • Notes: Is there a single person that looks over all webtools or should they just all be their own toplevel module?
    • Directories:
  • branches 1.5 1.8
    • Owners:
    • Notes:
    • Directories:
  • linux distro topics
    • Owners:
    • Notes:
    • Directories:
  • antiphishing
    • Owners:
    • Notes:
    • Directories:
  • platform (windows, mac, etc) owners
    • Owners:
    • Notes:
  • mobile
    • Owners:
    • Notes:
    • Directories:
  • labs
    • Owners:
    • Notes:
    • Directories:
  • IT/sysadmins
    • Owners: Justin
    • Notes:
  • demos
    • Owners:
    • Notes:
  • design
    • Owners:
    • Notes: UI/architecture
  • graphics
    • Owners:
    • Notes: application graphics, icons, etc., Might have an internal component.
  • event coordination
    • Owners: Mary Colvig
    • Notes:
    • Directories:
Retrieved from "https://wiki.mozilla.org/index.php?title=Modules_Scratchpad&oldid=58978"