MozillaWiki

2005Offsite/MozillaProjectDynamics: Difference between revisions

Page Discussion

2005Offsite/MozillaProjectDynamics (view source)

Revision as of 16:02, 13 March 2006

2,028 bytes added ,  13 March 2006
Noting that census-@t-mozillafoundation.org was created
(Noting that census-@t-mozillafoundation.org was created)
 
(29 intermediate revisions by 9 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 =


== Zak-s Brief Summary ==
== Zak's Brief Summary ==
People's major concerns are:
People's major concerns are:
* CULTURE
* CULTURE
Line 22: Line 22:
== Really Ugly Notes ==
== Really Ugly Notes ==


  Mitchell-s intro
=== Mitchell's Intro ===
  ================
* Greater responsibility
  Greater responsibility
* More complexity
  More complexity
* More interconnections
  More interconnections
* What concerns, fears, etc.
  What concerns, fears, etc.
* Outline your concerns, fears, interests, etc.


  What people want
=== Chase ===
  ================
* Keeping our identity.
* Hold on to the thing that we care about.
* Serving the users.


  Chase
=== Doug ===
  -----
* Don't bundle irrelevant or low-quality stuff.
  Keeping our identity.
* Don't compromise principles for opportunity.
  Hold on to the thing that we care about.
  Serving the users.
  Keeping our culture.
  CULTURE


  Doug
=== Michael ===
  ----
* Is there a Mozilla brand/identity
  Don-t bundle crap.
* Is there mostly just a Firefox brand/identity for the largest audience?
  Don-t compromise principles for opportunity.
  PRINCIPLES


  Michael
=== Ben Goodger ===
  -------
* Identity is partly tied up in the software development methodology
  Brand
* Identify what parts of the methodologies should be quantified.
  Is there a Mozilla brand/identity
  Is there mostly just a Firefox brand/identity for the largest audience?


  Ben Goodger
=== Frank Hecker ===
  -----------
* We need to identify which roles people have
  Identify is partly tied up in the software development methodology
  Identify what parts of the methodologies should be quantified.


=== Ben Goodger ===
* There are good lessons from the Mozilla world
* We need to share what we have learned with others


  Frank Hecker
=== Mitchell ===
  ------------
* Is part of our identity/culture how we build software?
  Identify which roles people have
* Are there areas to improve?


  Ben Goodger
=== Hecht/Aaron/General Chaos/... ===
  -----------
* Do we need the review process?
  Good lessons in the Mozilla world
* No transparency in the review process.
  Share what we have learned with others
* Reviewers who are responsive get DOS-d
* Perhaps have a review manager
* Perhaps omit bugzilla from the header to avoid filtering


  Mitchell
=== Roger ===
  --------
* Have patch facilitator(s) who track the bugzilla review request queue, and assist in driving patches that fall off the radar.
  If part of our identity/culture is how we build software?
  Are there areas to improve?


  Hecht/Amin Leventhal/Chaos/...
=== Mitchell ===
  ------------------------------
* What about having managers
  Do we need the review process?
  No transparency in the review process.
  Reviewers who are responsive get DOS-d
  Perhaps have a review manager
  Perhaps omit bugzilla from the header to avoid filtering


  Roger:
=== Schrep ===
  Have a review manager.
* People have already been having some management


  Mitchell
=== Chris Hofmann ===
  --------
* 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.]
  What about having managers


  Schrep
=== Axel Hecht ===
  ------
* Review queue is just part of the problem
  People have already been having some management
* Perhaps just have mentoring to help people get familiar
* Find people who can review better


  Chris Hofmann
=== Schrep ===
  --------------
* Two issues here:
  The problem of project management isn-t going away
* 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


  Hecht
=== David Baron ===
  -----
* Blame is directed at reviewers.
  Review queue is just part of the problem
* Often those requesting review can make things much easier for the reviewers.
  Perhaps just have mentoring to help people get familiar
* Provide context for the reviewers.
  Find people who can review better
* Use your expertise to reduce effort for the reviewers


  Schrep
=== Uri ===
  ------
* The decision making process is not transparent or always public
  Are there enough resources? Management won-t fix this.
* This can cause a good deal of frustration
  Project management as handling the big picture
* More transparency can help a good deal


  David baron
=== Michael Kaply ===
  -----------
* Hiring creates difficulty
  Blame is directed at reviewers.
* Hiring breaks the community model
  Often those requesting review can make things much easier for the reviewers.
  Provide context for the reviewers.
  Use your expertise to reduce effort for the reviewers


=== Mitchell ===
* FLOSS projects don-t tend to grow people managers
** sometimes they grow project managers
** mostly they grow developers
* We need to find the right people for the jobs needed.


  Uri
=== Aaron ===
  ---
* trouble finding the right person for a particular task
  The decision making process is not transparent or always public
** need intranet-type solution
  This can cause a good deal of frustration
** this should include skill list
  More transparency can help a good deal


  Michael Kaply
=== Michael Kaply ===
  -------------
* Do corporation developers get more credit that non-corp developers
  Hiring creates difficulty
* Try to introduce people as much as possible
  Hiring breaks the community model
* We need transparency


  Mitchell
=== Mitchell ===
  --------
* We have not been as transparent as possible
  FLOSS projects don-t tend to grow people managers
* The corporation should define who is management, what their roles are, what management means in the corporation and to the project
  * sometimes they grow project managers
* Being hired by the corporation does not imply that you have more voice in the community
  * mostly they grow developers
* Good that we separated the foundation from the corporation
  We need to find the right people.
* Non-devs are not as well-known in the community


  Amin
=== Frank Hecker ===
  ----
* Frank mentions the proposed "Mozilla community census" - write to Zak <zak@mozillafoundation.org> for more on this.
  * trouble finding people
  * need intranet
  * include skill list


  Michael Kaply
=== Michael Kaply ===
  -------------
* We really need to know who does what
  * Do corporation developers get more credit that non-corp developers
  * Try to introduce people as much as possible
  * TRANSPARENCY!


  Mitchell
=== Mike Connor ===
  --------
* Belzner did a good job and did not behave outside of the constraints of our culture
  * We have not been as transparent as possible
* People who are directly involved in specific areas know who is responsible for an area.
  * The corporation should define who is management, what their roles are, what management means in the corporation and to the project
* People are integrating well with their core team
  * Being hired by the corporation does not imply that you have more voice in the community
* But external people do not know who does what
  * Good that we separated the foundation from the corporation
  * Non-devs are not as well-known in the community
  *  


  Frank Hecker
=== 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?
  Census
* Instead, relationships should be developed over time by new hires working with the community


  Michael Kaply
=== Schrep ===
  -------------
* It is important to know who new staff are and what they do
  Who does what
* It is also important to integrate people carefully.
** no easy solution to integrate people
** new people must understand and follow community guidelines
** culture is important


  Mike Connor
=== Axel Hecht ===
  ------------
* Power in a floss community comes from their ability to convince
  Belzner did not impose
  But people who are directly involve
  People are integrating well
  But external people do not know


  Mitchell
=== Zak ===
  --------
To address the problem of finding who is responsible for a given area or key task:
  Hired Belzner as
* Have role-based email addresses that are directed to the responsible person or group
* An introductory mail should be sent out if:
** you have not written to the email address within a certain amount of time
** or if the person(s) responsible for the role have changed
* 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.


  Michael
=== Christian/Aaron ===
  --------
* ... but this excludes many people who could participate meaningfully.
  How do you tell who  


=== Zak ===
* It keeps peer projects away as well.


  John Lilly
=== General Consensus ===
  ----------
* We need to need to purge old modules
  Not many people would care about a page of info
  Instead there should be relationships


  Schrep
=== Myk ===
  ------
* Mozilla has been developer centric
  Knowing who they are and what they do
* As the corporation has built out its management team, they have gained more influence in the project.
  How they are integrated - authority / credit without community process
* What is the role of the management team now?
  - no easy solution for this
* What are the limits of mozilla.com management?
  - new people follow community guidelines
  - cultural mix
  CULTURE


  Axel Hecht
=== Mike Connor ===
  ----------
* Beard works within the CULTURE
  Power in a floss community comes from their ability to convince
* Other developers have acted as a filter of Beard


  Zak
=== Dan ===
  ----
* How do people from outside influence the project?
  Perhaps have role-based email that is directed to a list or a person.
* Thunderbird for example
  Send an introductory auto-response
* (Are) things are being dragged behind FireFox
  Archive the email
  Include group identities
  Define owners of activities


=== Many ===
* General disagreement on the above point


  David Liebreich
=== Mitchell ===
  ---------------
* mozilla.org was a developer organization for years
  High bar as filter for attracting skilled developers
* non-devs not needed to make the project succeed in its current goals
* is our identity how we build and ship software?
* 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


  Christian/Amin
* Who decides when a product is ready?
  --------------
* What process?
  But the high bar excludes people
* Who is involved?
* It is good if that person is full-time and is engaged with the corporation, but not required.




  ****
=== Brendan ===
  ----
* Drivers has not been that active in release management
  Need to purge old modules
* Should tehre only be one person there to make release decisions?
* Of course not, there should be people from the community involved
* There must be a community function/process in all of the project management roles and processes


=== John Lilly ===
* Can only have buyin from the stakeholders if you do the right job.
* Transparency, communication and accountability is always required.


  Myk
=== Christian ===
  ---
* Are all the mozilla employees now part of staff@mozilla.org? Who else is on there?
  Mozilla has been developer centric
  As the foundation 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?


  Canadian
=== Mitchell ===
  --------
* Some people were removed from the list who were not active.
  Beard works within the CULTURE
* People have not been added in a while
  Other developers have acted as a filter of Beard
* 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?


  Dan
=== Don ===
  ---
* Meeting minutes are meant to allow for transparency
  How do people from outside influence the project?
  Thunderbird for example
  Things are being dragged behind FireFox


  ****
=== Michael Kaply ===
  General disagreement
* Sometimes the meeting notes raise more issues than the address


=== Mitchell ===
* Some things are omitted because of a broad readership.
* Disclosure of things like release time can inform media improperly


  Mitchell
=== Brendan ===
  --------
* (I fuzzed out here. Brendan, can you elaborate? --zak)
  mozilla.org was a developer organization for years
  non-devs not needed to make the project succeed in its current goals
  is our identity how we build and ship software
  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?
=== Michael ===
  What process?
* We should choose what to disclose to the community
  Who is involved?
* We should make a formal release to inform the community
  It is good if that person is full-time and is engaged with the corporation, but not required.


=== Mitchell ===
* (I missed Mitchell's response here. Mitchell, can you comment? --zak)


  Brendan
=== Gerv ===
  -------
* The contents of the minutes should not come as a surprise to the community.
  Drivers has not been that active in release management?
* The only things which go in there are things which it's OK for the public to know.
  Should tehre only be one person there to make release decisions?
* 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.
  Of course not, there should be people from the community involved
  There must be a community function/process in all of the project management roles and processes


  John Lilly
=== David Baron ===
  ----------
* There can be a deterrent to communicating, in that the communicator can become responsible for more communication on the issue.
  TRANSPARENCY
* 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.
  COMMUNICATION
  Can only have buyin from the stakeholders if you do the right job.


  Christian
=== Todo for Zak ===
  ---------
<s>Create census-@t-mozillafoundation.org</s>
  Are all the mozilla employees now part of staff@mozilla.org? Who else is on there?
 
  Mitchell
  --------
  Some people were removed from the list who were not active.
  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
  ---
  Meeting minutes are meant to allow for transparency
 
  Michael Kaply
  -------------
  Sometimes the meeting notes care more issues.
 
  Mitchell
  --------
  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.
 
 
 
  Todo for Zak
  ------------
  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.
Zak
461

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/14606...21655"