461
edits
2005Offsite/MozillaProjectDynamics: Difference between revisions
Jump to navigation
Jump to search
2005Offsite/MozillaProjectDynamics (view source)
Revision as of 16:02, 13 March 2006
, 13 March 2006Noting that census-@t-mozillafoundation.org was created
(Noting that census-@t-mozillafoundation.org was created) |
|||
| (17 intermediate revisions by 8 users not shown) | |||
| Line 1: | Line 1: | ||
= Mozilla Project Dynamics = | = Mozilla Project Dynamics = | ||
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 === | ||
* | * 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 === | ||
* | * 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 | * 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 | * 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 === | ||
* | * Two issues here: | ||
* | * 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 141: | Line 142: | ||
=== Schrep === | === Schrep === | ||
* It is important to know who new staff are and what they do | * It is important to know who new staff are and what they do | ||
* It is also important to integrate people carefully | * It is also important to integrate people carefully. | ||
** no easy solution to integrate people | ** no easy solution to integrate people | ||
** new people must understand and follow community guidelines | ** new people must understand and follow community guidelines | ||
| Line 162: | Line 163: | ||
=== David Liebreich === | === 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. | |||
=== Christian/Aaron === | === Christian/Aaron === | ||
| Line 179: | Line 180: | ||
* What are the limits of mozilla.com management? | * What are the limits of mozilla.com management? | ||
=== Mike Connor === | |||
* 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 | |||
* (Are) things are being dragged behind FireFox | |||
=== Many === | |||
* General disagreement on the above point | |||
=== 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. | |||
* You need a 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 === | |||
* Can only have buyin from the stakeholders if you do the right job. | |||
* Transparency, communication and accountability is always required. | |||
=== 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 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 | |||
=== Brendan === | |||
* (I fuzzed out here. Brendan, can you elaborate? --zak) | |||
=== Michael === | |||
* We should choose what to disclose to the community | |||
* We should make a formal release to inform the community | |||
=== Mitchell === | |||
* (I missed Mitchell's response here. Mitchell, can you comment? --zak) | |||
=== 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 === | |||
<s>Create census-@t-mozillafoundation.org</s> | |||