2005Offsite/MozillaProjectDynamics: Difference between revisions

Noting that census-@t-mozillafoundation.org was created
(Noting that census-@t-mozillafoundation.org was created)
 
(18 intermediate revisions by 8 users not shown)
Line 1: Line 1:
= Mozilla Project Dynamics =
= Mozilla Project Dynamics =


== Topics to be covered ==
An open discussion on how the Mozilla project could and should run.


= Rough Notes on Discussion =
= Rough Notes on Discussion =
Line 43: Line 43:


=== Ben Goodger ===
=== Ben Goodger ===
* Identify is partly tied up in the software development methodology
* Identity is partly tied up in the software development methodology
* Identify what parts of the methodologies should be quantified.
* Identify what parts of the methodologies should be quantified.


Line 54: Line 54:


=== Mitchell ===
=== Mitchell ===
* If part of our identity/culture is how we build software?
* Is part of our identity/culture how we build software?
* Are there areas to improve?
* Are there areas to improve?


Line 65: Line 65:


=== Roger ===
=== Roger ===
* Have a review manager.
* Have patch facilitator(s) who track the bugzilla review request queue, and assist in driving patches that fall off the radar.


=== Mitchell ===
=== Mitchell ===
Line 74: Line 74:


=== Chris Hofmann ===
=== Chris Hofmann ===
* The problem of review sheparding, management, cooridination isn't going away.  [ Some data that Asa pulled from bugzilla shows that in 2004 over 886 contributors submitted over 17,000 patches to bugzilla.  About 80% of the work was done by the top 100 contributors, and then there is a long trailing edge.  In some sense that is a the sign of a very healthy Open Source project, but also is going to leave long review queues.  Having someone focused on finding the valuable needles in the haystack that we might missing, mentoring to improve patch quality, and coordinating would be valuable.]
* The problem of review shepherding, management, cooridination isn't going away.  [ Some data that Asa pulled from bugzilla shows that in 2004 over 886 contributors submitted over 17,000 patches to bugzilla.  About 80% of the work was done by the top 100 contributors, and then there is a long trailing edge.  In some sense that is a the sign of a very healthy Open Source project, but also is going to leave long review queues.  Having someone focused on finding the valuable needles in the haystack that we might missing, mentoring to improve patch quality, and coordinating would be valuable.]


=== Axel Hecht ===
=== Axel Hecht ===
Line 82: Line 82:


=== Schrep ===
=== Schrep ===
* Are there enough resources? Management won-t fix this.
* Two issues here:
* Project management as handling the big picture
* Making sure there are enough resources to review patches.  Management won't fix this.
* Having help to shepherd and coordinate releases so patches don't get lost


=== David Baron ===
=== David Baron ===
Line 124: Line 125:


=== Frank Hecker ===
=== Frank Hecker ===
* Frank mentions the census - write to Zak <zak@mozillafoundation.org> for more on this.
* Frank mentions the proposed "Mozilla community census" - write to Zak <zak@mozillafoundation.org> for more on this.


=== Michael Kaply ===
=== Michael Kaply ===
Line 135: Line 136:
* But external people do not know who does what
* But external people do not know who does what


  John Lilly
=== John Lilly ===
  ----------
* If you have pages to introduce corporation staff to the community, how many people in the community care about what the page says if the person has not worked through the community process?
  Not many people would care about a page of info on how good someone is
* Instead, relationships should be developed over time by new hires working with the community
  Instead there should be relationships


  Schrep
=== Schrep ===
  ------
* It is important to know who new staff are and what they do
  Knowing who they are and what they do
* It is also important to integrate people carefully.
  How they are integrated - authority / credit without community process
** no easy solution to integrate people
  - no easy solution for this
** new people must understand and follow community guidelines
  - new people follow community guidelines
** culture is important
  - cultural mix
  CULTURE


  Axel Hecht
=== Axel Hecht ===
  ----------
* Power in a floss community comes from their ability to convince
  Power in a floss community comes from their ability to convince


  Zak
=== Zak ===
  ----
To address the problem of finding who is responsible for a given area or key task:
  Perhaps have role-based email that is directed to a list or a person.
* Have role-based email addresses that are directed to the responsible person or group
  Send an introductory auto-response
* An introductory mail should be sent out if:
  Archive the email
** you have not written to the email address within a certain amount of time
  Include group identities
** or if the person(s) responsible for the role have changed
  Define owners of activities
* The introductory mail should:
** Describe why the mail is being sent
** How the project defines the role, activity or task
** Who is responsible for the role/activity/task
* Mail to the role-based addresses should be archived


=== David Liebreich ===
* In some ways, having a project that is difficult to work on helps ensure that we only have participants with the right skills and who are committed.


  David Liebreich
=== Christian/Aaron ===
  ---------------
* ... but this excludes many people who could participate meaningfully.
  High bar as filter for attracting skilled developers


  Christian/Aaron
=== Zak ===
  --------------
* It keeps peer projects away as well.
  But the high bar excludes people


=== General Consensus ===
* We need to need to purge old modules


  ****
=== Myk ===
  ----
* Mozilla has been developer centric
  Need to purge old modules
* As the corporation has built out its management team, they have gained more influence in the project.
* What is the role of the management team now?
* What are the limits of mozilla.com management?


=== Mike Connor ===
* Beard works within the CULTURE
* Other developers have acted as a filter of Beard


  Myk
=== Dan ===
  ---
* How do people from outside influence the project?
  Mozilla has been developer centric
* Thunderbird for example
  As the foundation has built out its management team, they have gained more influence in the project.
* (Are) things are being dragged behind FireFox
  What is the role of the management team now?
  What are the limits of mozilla.com management?


  Canadian
=== Many ===
  --------
* General disagreement on the above point
  Beard works within the CULTURE
  Other developers have acted as a filter of Beard


  Dan
=== Mitchell ===
  ---
* mozilla.org was a developer organization for years
  How do people from outside influence the project?
* non-devs not needed to make the project succeed in its current goals
  Thunderbird for example
* is our identity how we build and ship software?
  Things are being dragged behind FireFox
* When you deal with other companies, they need to have a confidential business relationship with a group that is tied to another entity.
* You need a corporate body


  ****
* Who decides when a product is ready?
  General disagreement
* What process?
* Who is involved?
* It is good if that person is full-time and is engaged with the corporation, but not required.




  Mitchell
=== Brendan ===
  --------
* Drivers has not been that active in release management
  mozilla.org was a developer organization for years
* Should tehre only be one person there to make release decisions?
  non-devs not needed to make the project succeed in its current goals
* Of course not, there should be people from the community involved
  is our identity how we build and ship software
* There must be a community function/process in all of the project management roles and processes
  When you deal with other companies, they need to have a confidential business relationship with a group that is tied to another entity.
  CORPORATE BODY


  Who decides when a product is ready?
=== John Lilly ===
  What process?
* Can only have buyin from the stakeholders if you do the right job.
  Who is involved?
* Transparency, communication and accountability is always required.
  It is good if that person is full-time and is engaged with the corporation, but not required.


=== Christian ===
* Are all the mozilla employees now part of staff@mozilla.org? Who else is on there?


  Brendan
=== Mitchell ===
  -------
* Some people were removed from the list who were not active.
  Drivers has not been that active in release management?
* People have not been added in a while
  Should tehre only be one person there to make release decisions?
* What are the criteria for mozilla.org staff going forward.
  Of course not, there should be people from the community involved
* Mozilla.org staff used to speak for the organization
  There must be a community function/process in all of the project management roles and processes
* What is the relation of the mozilla.org staff to the assets of the corporation
* Those left on the list are mostly employees, but just by attrition.
* What does mozilla.org staff do?


  John Lilly
=== Don ===
  ----------
* Meeting minutes are meant to allow for transparency
  TRANSPARENCY
  COMMUNICATION
  Can only have buyin from the stakeholders if you do the right job.


  Christian
=== Michael Kaply ===
  ---------
* Sometimes the meeting notes raise more issues than the address
  Are all the mozilla employees now part of staff@mozilla.org? Who else is on there?


  Mitchell
=== Mitchell ===
  --------
* Some things are omitted because of a broad readership.
  Some people were removed from the list who were not active.
* Disclosure of things like release time can inform media improperly
  People have not been added in a while
  What are the criteria for mozilla.org staff going forward.
  Mozilla.org staff used to speak for the organization
  What is the relation of the mozilla.org staff to the assets of the corporation
  Those left on the list are mostly employees, but just by attrition.
  What does mozilla.org staff do?


  Don
=== Brendan ===
  ---
* (I fuzzed out here. Brendan, can you elaborate? --zak)
  Meeting minutes are meant to allow for transparency


  Michael Kaply
=== Michael ===
  -------------
* We should choose what to disclose to the community
  Sometimes the meeting notes care more issues.
* We should make a formal release to inform the community


  Mitchell
=== Mitchell ===
  --------
* (I missed Mitchell's response here. Mitchell, can you comment? --zak)
  Some things are omitted because of a broad readership.
  Disclosure of things like release time can inform media improperly
 
  Brendan
  -------
  (I fuzzed out here. --zak)
 
  Michael
  -------
  Choose what to disclose to the community
  Make a formal release to inform the community
 
  Mitchell
  --------
 
  Gerv
  ----
  The topics of the minutes should not be a surprise. Instead, users should know about the issues before hand.
 
 
  David Baron
  ------------
  There can be a deterrent to communicating, in that the communicator can become responsible for more communication on the issue.


=== Gerv ===
* The contents of the minutes should not come as a surprise to the community.
* The only things which go in there are things which it's OK for the public to know.
* If they find out that way rather than through a "better" mechanism, it means someone has not communicated on an issue with sufficient timeliness using the "better" mechanism.


=== David Baron ===
* There can be a deterrent to communicating, in that the communicator can become responsible for more communication on the issue.
* ie. Write to the list about some issue and then you get to become responsible for answering questions about it for it for the next few days.


  Todo for Zak
=== Todo for Zak ===
  ------------
<s>Create census-@t-mozillafoundation.org</s>
  Create census@mozillafoundation.org
  Clean up these notes (I would be happy for help)
  Notify people to get them to clean up their notes so that they are not misrepresented.
461

edits