2005Offsite/MozillaProjectDynamics

Rough Notes on Discussion

Zak's Brief Summary

People's major concerns are:

• CULTURE
  • Keeping and strengthening the good parts of the Mozilla community culture
  • Helping people new to the project (especially those in the corporation) become valid members of the greater Mozilla company.
• PRINCIPLES
  • Adhering to the core principles of the community in the community and corporate activities. (Which implies defining the principles.)
• TRANSPARENCY:
  • Making sure that the producing and managing stakeholders (ie. community, corporation and foundation) know what the others are doing (that are not private).
  • Balancing the need for transparency with the need to get work done and protect privacy.
• COMMUNICATION:
  • Improving communication to improve effectiveness of the project and to improve transparency
• TOOLS:
  • Using tools to improve communication

Really Ugly Notes

Mitchell's Intro

• Greater responsibility
• More complexity
• More interconnections
• What concerns, fears, etc.
• Outline your concerns, fears, interests, etc.

Chase

• Keeping our identity.
• Hold on to the thing that we care about.
• Serving the users.

Doug

• Don't bundle irrelevant or low-quality stuff.
• Don't compromise principles for opportunity.

Michael

• Is there a Mozilla brand/identity
• Is there mostly just a Firefox brand/identity for the largest audience?

Ben Goodger

• Identify is partly tied up in the software development methodology
• Identify what parts of the methodologies should be quantified.

Frank Hecker

• We need to identify which roles people have

Ben Goodger

• There are good lessons from the Mozilla world
• We need to share what we have learned with others

Mitchell

• If part of our identity/culture is how we build software?
• Are there areas to improve?

Hecht/Aaron/General Chaos/...

• 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

• Have a review manager.

Mitchell

• What about having managers

Schrep

• People have already been having some management

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.]

Axel Hecht

• Review queue is just part of the problem
• Perhaps just have mentoring to help people get familiar
• Find people who can review better

Schrep

• Are there enough resources? Management won-t fix this.
• Project management as handling the big picture

David Baron

• Blame is directed at reviewers.
• 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

Uri

• The decision making process is not transparent or always public
• This can cause a good deal of frustration
• More transparency can help a good deal

Michael Kaply

• Hiring creates difficulty
• Hiring breaks the community model

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.

Aaron

• trouble finding the right person for a particular task
  • need intranet-type solution
  • this should include skill list

Michael Kaply

• Do corporation developers get more credit that non-corp developers
• Try to introduce people as much as possible
• We need transparency

Mitchell

• We have not been as transparent as possible
• The corporation should define who is management, what their roles are, what management means in the corporation and to the project
• Being hired by the corporation does not imply that you have more voice in the community
• Good that we separated the foundation from the corporation
• Non-devs are not as well-known in the community

Frank Hecker

• Frank mentions the census - write to Zak <zak@mozillafoundation.org> for more on this.

Michael Kaply

• We really need to know who does what

Mike Connor

• Belzner did a good job and did not behave outside of the constraints of our culture
• People who are directly involved in specific areas know who is responsible for an area.
• People are integrating well with their core team
• But external people do not know who does what

 John Lilly
 ----------
 Not many people would care about a page of info on how good someone is
 Instead there should be relationships

 Schrep
 ------
 Knowing who they are and what they do
 How they are integrated - authority / credit without community process
 - no easy solution for this
 - new people follow community guidelines
 - cultural mix
 CULTURE

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

 Zak
 ----
 Perhaps have role-based email that is directed to a list or a person.
 Send an introductory auto-response
 Archive the email
 Include group identities
 Define owners of activities

 David Liebreich
 ---------------
 High bar as filter for attracting skilled developers

 Christian/Aaron
 --------------
 But the high bar excludes people

 ****
 ----
 Need to purge old modules

 Myk
 ---
 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
 --------
 Beard works within the CULTURE
 Other developers have acted as a filter of Beard

 Dan
 ---
 How do people from outside influence the project?
 Thunderbird for example
 Things are being dragged behind FireFox

 ****
 General disagreement

 Mitchell
 --------
 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?
 What process?
 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?
 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
 ----------
 TRANSPARENCY
 COMMUNICATION
 Can only have buyin from the stakeholders if you do the right job.

 Christian
 ---------
 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.