On Sep 13, 2012 7:18 PM, "David Bruant" <[email protected]> wrote: > > Le 12/09/2012 19:24, L. David Baron a écrit : > > So I think one of the assumptions you're making is that it's good to > > agree on priorities. > Yes. I don't remember the full context, but it seemed like Brian King's > assumption too. > > > I think I disagree with that assumption. I think we do need to have > > agreement on the high-level goals of the project, but I think it's > > actually good to disagree over which aspects of it are higher > > priority. That people within an open-source project disagree over > > priorities is one of the things that lets open-source software have > > higher overall quality than closed-source software. > > > > This is because there are tons of different things that affect the > > quality of software, and different users care about different ones. > > We need to worry about getting behavior correct, having clear user > > interface, being fast, not using too much memory, not crashing, etc. > > > > In a tightly-managed project where the priorities are clearly > > defined by someone in charge (whether that's an individual, a small > > group of leaders, or a more democratic model like you seem to be > > proposing), you're still going to end up with a set of official > > priorities. Such priorities end up as official sanction to ignore > > some aspects of quality in favor of others, for example, being > > willing to sacrifice any amount of memory use in order to get a > > speed improvement. > I agree with you. Reading back what I've written on this thread, I > realize that I've mostly talked about how to start a new Mozilla > initiative (B2G, WebMaker, actions to follow a new business model...) or > how to decide to "stop" one (SeaMonkey, Thunderbird...). > Figuring out priorities within or between existing products/programs > seems to be a slightly different topic for which I agree with everything > you're saying. As an example, memory was always one "priority", but > there was no one to embody it; it was an excellent decision to create > MemShrink to fix this.
And MemShrink was, for the most part, one of those small groups with a vision that bz mentioned. Nick realized that our memory usage regressed significantly in Firefox 4, convinced some other engineers that this was a big problem, and he got his manager and another manager to let their employees spend some time fixing it. That's the severely abridged version of course. But there was never a strong top down push to address memory usage from people like Mitchell or Gary or Damon or Asa. At least not one that I remember ;-). And the only reason we needed permission from management to do this is that the relevant people are all employees. Pardon the brevity etc etc. I'm typing this on my phone when I should be vacationing :-P. _______________________________________________ governance mailing list [email protected] https://lists.mozilla.org/listinfo/governance
