Everyone remain calm

54 Replies to “Everyone remain calm”

1. >I wanted to point out that these plans were not made with agreement from me or, as far as I can tell, from Ben.
   Then who makes these decisions? Who takes part in these aviary meetings. Currently decisions are made in those aviary meetings, where it is difficult to tell who is responsible and whether the responsible persons are qualified to make these decisions.

2. Thanks alot for clearing that up, and I agree with everything you said in that post.

3. Three cheers for a voice of sanity and reasoning. Thanks for the clarifications Brendan.

4. Bernd: this was a daily 4pm bug meeting, where the only agenda item was “get patches needing review reviewed and landed”. I had to miss it due to a prior engagement, and Ben missed it too. Of course, no decision should have been made there about yanking features, but that didn’t stop an attempt from being made.
   All’s well in the end, except for the lingering bad odor, which I agree needs to be dissipated. Hence my blog, and continuing work by many of us to increase transparency and preserve design leadership by the design leads, even as they hear and respond to all useful feedback.
   /be

5. Good words, Brendan. If there’s a common thread here, it’s an overemphasis on short-term usability over long-term usability. Removing view source may improve Firefox’s UI short-term by some tiny amount, but it makes the Web less usable long-term when there are fewer authors learning HTML (and also more misguided attempts at DRMed HTML). Similarly, removing the style sheet switcher may improve Firefox’s UI slightly short-term, but it makes the Web less usable long-term if we all (even Lynx and screenreader users) have to scroll past cluttersome and inconsistent site-specific style switchers on every multi-style page.

6. I’m increasingly skeptical about the wisdom of the alternative style sheet UI removal decried by Daniel, and I’ll make sure that feedback from the preview release on this removal is heard and fairly evaluated.
   That makes me happy ^_^. Glad you posted all this Brendan, it’s quite comforting :).
   ~Grauw

7. About Firefox UI: we’re trying something with both SeaMonkey and Firefox (and Thunderbird) now that couldn’t be done in the old days when Netscape paid most module owners, along with a good number of professional UI (or UE, they used to call it) designers: individually accountable product design leads.
   See also Boris’ post referenced above, and Ian Hickson’s response, which essentially agreed with him.
   I think some issues should be addressed explicitly. I can think of good answers for the following questions, but I can’t speak for Mozilla.org:
   1) I know Open Source doesn’t technically preclude top-down decision making, but I think there’s an expectation, maybe a tradition, of a different process. How do you reconcile that?
   2) Isn’t there a value to ‘bottom-up’ input? Doesn’t summarily dismissing it cost the project something? (You may say it’s not summarily dismissed, by that’s my impression, and looking at the link in your original post, others seem to agree.) The options aren’t: ‘Take thousands of voices into account’ or ‘Ignore everyone’; there’s a middle ground. Many groups have developed mechanisms for larger scale decision making.
   3) When your input and the product of your labor are not incorporated into the project, why would anyone contribute? What good is it doing? How could someone choose a new task now, and have confidence that the fruits of their labors would end up in users’ hands?
   4) We’re dealing with human beings, and I suspect we drive some away needlessly: People have egos and want basic respect. Blatent disregard doens’t cultivate a community; it makes volunteers look like (and feel like) suckers. Isn’t this an impractical policy?
   Again, there are probably good answers, and there are always necessary compromises, but let’s address them explicitly.
   (As a side note: Posting Moz.org communication in all these different blogs on all these webpages makes it impossible to follow. Why not something centralized? Whatever happened to Usenet, for example?)

8. Sorry this is unrelated but I can’t find where to submit this feature idea:
   Filtering ALL, UNREAD, HAS ATTACHMENTS, TO DO on individual message folders is great but it would be awesome if you could do TO DO on all folders.

9. Thanks for commenting. I personally appreciate hearing that your seeing the concerns we all have had over the past few days.

10. quanxi:
    1) I know Open Source doesn’t technically preclude top-down decision making, but I think there’s an expectation, maybe a tradition, of a different process. How do you reconcile that?
    Sorry, I don’t know what you mean. Linus (or Andrew Morton, nowadays) picks and chooses kernel patches, sends many back just because they’re formatted badly, etc.
    There is no committee- or group-mind way to incorporate changes to a particular piece of code and keep its quality up, AFAIK. You can have two leads instead of one, and if they’re mental twins (Ken and Dennis of Unix fame), they’ll each do exactly as the other would have done; or else they’ll divide the labor and own sub-modules individually.
    Perhaps you had a *specific* different process in mind, with some successes to its name?
    2) Isn’t there a value to ‘bottom-up’ input? Doesn’t summarily dismissing it cost the project something?
    We get bottom-up input all the time on all modules and owned things, including Firefox UI. We don’t have to respond to all such input — much of it is garbage (Sturgeon’s law has not been repealed). That which is good, we believe, gets incorporated.
    If we fail to do a good enough job, we face forks and/or loss of developers, but so far Firefox is not losing developers — it’s simply not converting all SeaMonkey developers to the new app architecture expounded in the roadmap.
    If you believe a particular input was dismissed summarily, unfairly, mail me about it. There ought to be a bug on file, or a newsgroup thread, or something to point to. If a mistake was made, I’ll help get it fixed. If we don’t agree on ends or means, however, you may have to live with something we don’t consider a mistake.
    Again, Firefox cannot and will not be all things to all people (neither was SeaMonkey, but more people got away with more random UI there, pleasing perhaps themselves, at least in the short run). The right answer to many inputs of the form “why doesn’t Firefox do X” *is* “X should be an extension.” But not View / Source or other things I’ve blogged about here.
    (You may say it’s not summarily dismissed, by that’s my impression, and looking at the link in your original post, others seem to agree.) The options aren’t: ‘Take thousands of voices into account’ or ‘Ignore everyone’; there’s a middle ground. Many groups have developed mechanisms for larger scale decision making.
    You’re mixing two things up here: responding to inputs, and making decisions using a large scale of human minds. I do not believe the latter results in quality in a single app, or other integrated design. I welcome counterexamples (not of the form “All X server extensions, or all Linux/Unix commands or daemons”, etc. — cite something like a web browser if you can).
    3) When your input and the product of your labor are not incorporated into the project, why would anyone contribute? What good is it doing? How could someone choose a new task now, and have confidence that the fruits of their labors would end up in users’ hands?
    You can write extensions. We actually evaluate extensions based on quality and popularity, and will continue to do so, to harvest the best into default status.
    If you insist on getting something into the default build of a product used by millions of people that has a single person leading its UI design, you’ll have to convince that person. Period, end of story. There’s no free lunch, and doing work on spec does not entitle you to have that work incorporated at the cost of others’ labor and risk into a larger work.
    4) We’re dealing with human beings, and I suspect we drive some away needlessly: People have egos and want basic respect. Blatent disregard doens’t cultivate a community; it makes volunteers look like (and feel like) suckers. Isn’t this an impractical policy?
    Who ever said that was a policy?
    If someone (name names, in email if necessary) was rude or disrespectful, let me know. If someone was not rude or disrespectful, but failed to respond, let them know — if they continue to ignore you, let me know. If you think someone owes you something, you and I are not going to see eye to eye, however.
    (As a side note: Posting Moz.org communication in all these different blogs on all these webpages makes it impossible to follow. Why not something centralized? Whatever happened to Usenet, for example?)
    Good point — news://news.mozilla.org/netscape.public.mozilla.seamonkey has been used less than it should be, especially for Firefox stuff (as the name would imply, it was originally for the app-suite project issues).
    We could try to use news://news.mozilla.org/netscape.public.mozilla.browser, which exists, but I believe the Firefox community already uses the https://forums.mozillazine.org/ server-side lists. Have you browsed those at all?
    /be

11. I just wrote to guanxi (sorry for misspelling your name):
    There’s no free lunch, and doing work on spec does not entitle you to have that work incorporated at the cost of others’ labor and risk into a larger work.
    This applies to the layout module and others that Boris works on, and I’m pretty sure he would agree with me. It may be that he responds better to all demands, suggestions, and patches than Ben does on Firefox, but I would bet real money that layout is subject to orders of magnitude fewer conflicting, frivolous, or wrong-headed demands, requests, and patches than Firefox UI is.
    /be

12. Adam: SeaMonkey is not going away, but we cannot support both it and the new apps, and we won’t be, in the Mozilla 2.0 timeframe. If volunteers want to keep SeaMonkey going then (when APIs may change in ways that break it, and require possibly lots of debugging and porting effort), that’s great. But I will not divide our house more than it is by trying to do two hard things at once.
    The download numbers for Firefox, and the actual unique-visitors/week numbers we get from top sites, are growing tremendously. SeaMonkey is in decline, and will be cannibalized in part by Firefox. There’s no point in crying over this, it’s a fact that spells great success and vitality for Mozilla in the future. If we had not done the new apps, especially Firefox, we (Mozilla Foundation and all the infrastructure we host) would be in trouble right now.
    /be

13. On the lack of response – one thing that’s even more of a problem than it used to be for the suite is getting anything reviewed for Firefox. mconnor was the only person actually doing reviews that weren’t solicited by speaking across a room, on IRC, or by IM, and he seems to have slowed up (which is fair enough – he’s a volunteer). The result is that there are one character (literally) and one line patches for Firefox things (some ‘critical’) which wait months for review and/or only get review when someone bugs people on IRC about them.
    Following from that, every bug under the sun gets nominated as a release blocker, because that increases the chance that the bug will at least get looked at. Unfortunately it sometimes gets looked at by chofmann or asa who (quite appropriately) minus the blocking flag, rather than review+’ing the patch (it’s annoying when they make bug comments like “who can help with this?” when obviously the only people that can help are Firefox devs, and none of them are on the bug – except possibly Ben who’s on every bug in existance, but doesn’t read bugzilla mail). It’s not hard to find examples of this, but one that comes easily to hand is bug 191642.

14. I usually don’t post but I have been thinking about this for a while and it may semi relate to this or not but anyway. I have followed mozilla for a while, long before Firefox or Phoenix as it was originally called came around. At one point I become so excited about Firefox I decided I would finally try to get involved somehow but as time passed and the more I see the less I want to get involved.
    When it comes to development, it seems as if the dev team of firefox’s attitude to criticism of their decisions by the community is that they are designing a browser for the masses and not the community. The general feeling is that the community doesn’t matter at all when it comes to decision making.
    At the same time there are these community initiatives to promote firefox and talking about how important the community is. I just can’t seem to reconcile the two. Why should I put time and energy in any form into firefox if what the community says, no matter how logical appears to be disregarded. I am not talking about specific instances but rather the general feel of the situation.
    Lack of communication plays a role in this to. Everything with Firefox seems to come out of the blue. The new theme, find toolbar, these recent decisions. I almost didn’t post a comment to Asa’s blog when it came to View Source because to me it was like what’s the point, it isn’t like they will listen, no matter what I say.
    I just post this because I care and I think the devs to remember people only complain because they care. If they didn’t care they would just quietly leave. To me it seems that the mozilla foundation cares about the community. You can’t care when you want the browser promoted and not care when feedback comes.
    This is just my general impression as a user who has followed mozilla for a long time and wanted to get involved but because of actions or decisions by devs have later changed my mind. I don’t know if I am the only one that feels this way but I am just going to post and see what happens.

15. If we fail to do a good enough job, we face forks and/or loss of developers, but so far Firefox is not losing developers — it’s simply not converting all SeaMonkey developers to the new app architecture expounded in the roadmap.
    But it’s not gaining contributers at anything like the rate that the flurry of extension development activity would suggest is possible. No doubt NIH syndrome is responsible for much of that discrepancy; people are happier working on their own code than patching other people’s code. But features are being removed because no one is motivated enough to produce even simple patches and get them checked in. The styleswitcher in particular had a number of easy-to-fix bugs that have not recieved any attention (of course, there were also enhancement requests like persistance of choice but almost every feature has enhancement requests).
    My own perception, and it really is a perception rather than something I can reel off a list of bug numbers to demonstrate, is that getting code checked in to firefox is hard. Simple patches seem to sit and bitrot for weeks before they get review and then, eventually, they are rewritten. The core team doesn’t follow it’s own rules about checkins (one specific example being the large number of features changes since the “feature complete” 0.9).
    This contrasts with a module like layout (for example) where, if it happened I was competent enough to patch something, I would feel confident that it would recieve some review attention in a reasonable timeframe and where I would know that everyone was playing by the same rules. This latter point may sound minor but it’s quite important in making new contributers feel like they are able to get more involved with the code without having to be in some inner circle of names. Of course, these well defined rules might include extra checks on code from new people (though in practice that doesn’t seem to be the case), but the fact that the process is followed by everyone gives a good impression.
    I personally find it difficult to get motivated about contributing to a product where the philosophy seems to be that Ben, Blake and a few others do more or less what they want whilst occasional contributers are more or less ignored. It’s quite possible that reality doesn’t match my perception but, given the difference between the success of the extension development community and the core team at attracting new developers, I’m not sure I’m the only person who has a similar view of the situation.

16. I guess I wasn’t alone after all. This post sums it up completely. It’s some coincidence that he wrote it up the same time as I wrote my comment.

17. still wanting work offline back though.

18. If the style sheet switcher isn’t in Firefox 1.0, I’m switching back to plain old bulky Mozilla (assuming it’s still in Moz) or Opera. Why? Because for me, this truly is a killer feature. I can’t use a browser that doesn’t have it.
    That probably sounds petty to you, but some sites are just too much of a bother to look at unless I can remove the style or change to one of their alternate sheets. Now that I’m used to that, I refuse to live with less, when there’s something out there available that does what I want.
    Please don’t remove it. Besides, the CSS 2 spec requires this ability for CSS compliance. One of the goals of the Mozilla organization is to have a browser as close to compliance as possible, right?

19. “I wanted to point out that these plans were not made with agreement from me or, as far as I can tell, from Ben.”
    This is what I wanted to ask about. Ben is the owner of the browser component, that much I can understand. My question is (and I’m sorry if this is an inappropriate place to ask) if there is a disagreement, who makes the *final* decision? Who has the ultimate decision? (is there someone with such a status?) Would you be that person, are you one of a group of people? (is this an area where the drivers are in control? staff?)
    Again, I don’t know if this is the right place to ask, I am just wondering how such matters are (or would be) handled.

20. You wrote:
    SeaMonkey is in decline, and will be cannibalized in part by Firefox.
    Are there any numbers, including the downloads at netscape.com?

21. Brendan,
    Thanks for you response. As I said, I’m most interested in addressing these issues explicitly, which you did.
    I e-mailed you with a detailed suggestion of a solution.
    I generally agree with your response: Decisions must be made, Moz.org doesn’t owe it to anyone to accept contributions, and you can’t please everyone.
    If you insist on getting something into the default build of a product used by millions of people that has a single person leading its UI design, you’ll have to convince that person.
    That sounds right to me. I think it needs to be much more clearly and widely communicated, which is why I posted these questions:
    Many people are working on spec, unaware of this process (is there a process?). Most aren’t developers: Count the bugs triaged/patched but never fixed.
    I have no interest in working on spec, but I have no idea what Ben Goodyear, Neil Rashbrook, or other leads want done.
    I generally think Mozilla is a great success; I think by addressing these issues, it can become even more successful. Thanks for your hard work.

22. Brendan:
    Is there any chance that (as mitchael mentioned) +r/+sr will get faster? Otherwise it’s really sure that SeaMonkey wont live too long which is sad for me.
    Is there any chance that basing on Thunderbird/Firefox there will be a Suite package? As I am advanced user – it’s not a problem for me, but i’m very often installing other people Mozilla Suite – just to give them full internet suite and i think removing such package would be a mistake

23. “Product design can’t be done well by committee, and SeaMonkey’s UI was always worse for the compromises, bloat, and confusion about its intended audience that resulted from past committees.”
    What do you call this, then? Are the removals of view/source, stylesheet switching, and MNG just a harmless side effect of the benefits of monarchy?
    The emperor has no clothes.

24. Although Brendan has quashed most of the hubbub (and the Internet didn’t die on Thursday, either), one thread I’m not seeing addressed is that viewing source and page info isn’t just about learning/inspecting/lifting/debugging. It’s also a vital security precaution avenue, such as checking a dicey page for spoofed link status bar rollovers and a safe (i.e., non-IE) way to look for attempted IE exploits. Granted, not the kinds of things that granny would likely do, but she’s not the only one using these apps.

25. Neomugicha, I’m no emperor, and View / Source has not been removed.
    You can whine about MNG all you like, but doing so won’t make it relevant on the web, or worth the footprint hit.
    Stylesheet switching needs a few bugfixes, which I’m helping get in for 1.0, then it can make a come-back (I’m in favor).
    Monarchs aren’t Emperors, of course, but no one said he was the King of Mozilla, either. Without broad consensus among the technical elite, the project would fail through forks or abandonment. It hasn’t, and if we can avoid more mistakes of the “let’s remove ‘developer features’ such as View / Source” kind, it won’t.
    I’m here to help, and as I said, “developer features” valuable to the Mozilla community and worth including by default won’t be removed while I am around. What more can I say?
    /be

26. guanxi wrote:
    Many people are working on spec, unaware of this process (is there a process?). Most aren’t developers: Count the bugs triaged/patched but never fixed.
    This is a problem, or rather: the bugs with good patches that were never fixed is a problem. I know there are good patches rusting — we’ve had this problem since the beginning of the project, and AFAICT all open source projects have it. Bryner had big fun for months trying to get some attention on a GCC patch he did to greatly reduce the number of relocations due to visible symbols in ELF object files and libraries.
    We need to do better here. Ideas? This came up on n.p.m.seamonkey a half-year or so ago, and roc@ocallahan.org suggested a wall of shame for over-deep review queues. At least with bugzilla’s request tracker, anyone can query. Would you (or anyone reading this) do some queries and post the results to m.seamonkey?
    I have no interest in working on spec, but I have no idea what Ben Goodyear, Neil Rashbrook, or other leads want done.
    For Firefox, Ben keeps https://www.mozilla.org/projects/firefox/ up to date, and he should respond to offers to help from people who demonstrate that they can help (I’m his nagging conscience if he doesn’t).
    For SeaMonkey, I hear that Neil is very responsive to requests for patch reviews, but I don’t know of a roadmap or project page suggesting where people can help. Perhaps someone reading this can comment.
    /be

27. Gandalf wrote:
    Is there any chance that (as mitchell mentioned) +r/+sr will get faster? Otherwise it’s really sure that SeaMonkey wont live too long which is sad for me.
    I hear great things about Neil’s responsiveness. Are you requesting his review, or others? If there are not enough reviewers, that’s a harder nut to crack, but if someone just needs to empty his review queue, and keep after it better, I can nag with the best proverbial mother-in-laws. Of course, group-shame is often more powerful.
    If the patch is marginal or overambitious, though, it’s best to reset your expectations. If you haven’t yet, check out the life-cycle and new-features docs.
    Is there any chance that basing on Thunderbird/Firefox there will be a Suite package? As I am advanced user – it’s not a problem for me, but i’m very often installing other people Mozilla Suite – just to give them full internet suite and i think removing such package would be a mistake.
    The suite will be around for a while, although it won’t be actively developed to have all sorts of new features, unless more volunteers step up and actually carry its full weight (including fixing bugs due to those looming Mozilla 2.0 API changes).
    OS-level inter-app integration of Firefox and Thunderbird is pretty good right now. There are a few more things to do, possibly as an extension, but I’ve been living in both and the combination wins over the suite, in my experience, for many reasons:
    – Independent processes seem to have better memory behavior.
    – Modal dialogs in one process don’t hang up the other.
    – Better integration with *other* apps that want to talk to only the browser.
    There are other benefits, and some costs still, but things will only improve here.
    One thing that’s missing, which we hope to restore: HTML editing. Daniel Glazman’s work for NVu is making its way back to the tree, and that constitutes a new-app-architecture (new XUL toolkit app, like Firefox and Thunderbird), full-featured, one-touch-publishing HTML composer. More on that in due course.
    /be

28. Neil Paris wrote:
    Ben is the owner of the browser component, that much I can understand. My question is (and I’m sorry if this is an inappropriate place to ask) if there is a disagreement, who makes the *final* decision? Who has the ultimate decision? (is there someone with such a status?) Would you be that person, are you one of a group of people? (is this an area where the drivers are in control? staff?)
    Generally, staff@mozilla.org handle Mozilla policy, whether crypto, trademark, CVS access, etc. But staff delegate almost all project management decisions to drivers@mozilla.org, who handle tree closures, milestone scheduling, and the like. Things like CVS access policy, now that it has been set up, are also documented, delegated, and work through the bug system.
    Project management is not product design, or architecture, of course, so a lot of drivers’ work consists of trying to get bugs fixed before the last minute, when they tend to be triaged to the next release. With the parallel SeaMonkey 1.7.x and Aviary (for the birds, or foxes) 1.0 releases, drivers have been over-extended, and only asa, chofmann, and I have really focused on Aviary (asa does a bunch of work on SeaMonkey release management, too; so do chofmann, mkaply, and others).
    Super-reviewers, module owners, and other strong hackers who make themselves known by their deeds and words have a lot of say, and staff and drivers hear from them, and consult with them, pretty often.
    In all of this, we aim for consensus, with clear reasoning to back up zero-sum or win-lose decisions.
    We have not always succeeded. I have to agree that a few too many of the Firefox decisions were not made transparently. In the theme change case, there seemed to be good reasons for stealth, and I think the right decision was made, but the way that bomb dropped was not great. Perhaps it was a bomb no matter what, in which case, there’s no good way to be under it. But I think it could have been handled better.
    Another mishandled case: drivers failed to respond to MNG escalations, and module owners made a decision that needed more explanation of why, and under what conditions MNG might come back to Mozilla’s CVS repository as an option, and under what conditions a subset might be included in the default build. Drivers finally woke up, mainly roc, and set clear conditions.
    So when things don’t work, when consensus fails, then drivers may overrule owners or hackers, and staff may overrule drivers. If staff can’t agree, then I am where the buck stops for technical matters, and mitchell handles legal and policy buck-stopping.
    If I can give comment before such escalations make their painful way to me, I try to do so. In all cases, we should work on building consensus, ensuring that the community shares the same vocabulary and understanding of premises, even if not everyone agrees on conclusions or decisions.
    Again, I don’t know if this is the right place to ask, I am just wondering how such matters are (or would be) handled.
    Much of this is discussed on https://www.mozilla.org/ — you’ll have to read the “who we are”, “roles”, and “hacking” sections to get a complete sense. It’s fair to raise it here. If the docs on the site need to say something more clearly, or if they just fail to cover a hot topic, please file a bug on the mozilla.org product.
    /be

29. Honestly, I like the View Source because it gives me a chance to “look under the hood.” If I’m curious as to how something works or if I think there’s an error, it’s just a few keystrokes and I’m in the thick of it.

30. I believe mozilla should be also innovative in its intraproject communication. What we see now is a shallow copy of the cuts that PDT did for the netscape 6.0 release. At that time also decisions have been made without communication and quick and dirty checkins ( bug open patch r/sr —> within 30 minutes) These decisions have to be made in one way or another. Sometimes the decisions are wrong and then you have that developer outcry. Thats normal buisiness. What it is not necessary is that closed decision making. Just imagine a chatroom where people decide and people who are interested have no voice but can watch how the decisions are made. This will be transparent for everybody. I have seen such a system in a scientific community working very well (public meetings of scientific steering communities). There the spectators could also ask questions, but this might not be necessary here. It would also increase personal responsibility. (I hate decisions by a closed anonymous commitee, they lead to bad decisions, that has been experimentally proven in a lot of east european countries.)

31. I’m willing to see DOM Inspector moved to an extension, based on its relative novelty and complexity compared to View / Source.
    I think the way DOM Inspector is handled now is great, and other exensions should be done the same. Have a checkbox available at setup if you want it installed. And have a number of the most useful ones installed by default, unless you uncheck it. This saves the end-user the trouble of downloading 9 extensions after installation (most likely the average user would not download any extensions.)

32. Brendan: speaking of Nvu going back to the tree, Nvu being based on the FF toolkit but not being today a Mozilla product (using the marketing term here), myself being far away both in distance and TZ from the Mozilla Foundation, how it is going to impact the UI Czar model and how are we going to communicate? This is a major issue, and it’s not insulting to say that we seriously lack communication about the work being done in the toolkit. Bugmail is not an efficient channel…
    I had for instance to hack the customizable toolbars code for Nvu because it was not a perfect fit for an app having two totally independant toolbars, the second one not offering text alternatives; that change is almost useless for FF and TB, so will Nvu have to keep a xul preprocessor override? I’m sure you see my point here.
    More generally, new apps based on FF/TB’s toolkit will necessarily introduce compromises. Nothing that cannot solved, of course, but better say it now… Are we ready for those compromises, and if we’re not how and when are we going to become ready?

33. daniel wrote:
    Are there any numbers, including the downloads at netscape.com?
    You’d have to ask netscape.com about their download numbers. I can’t give you usage numbers from top websites, but our download numbers should be available somewhere. Let’s see… https://download-stats.mozilla.org/ is worth a look. I’m not sure how complete it is.
    /be

34. Nobody can say Brendan isn’t responsive! Thanks.

35. Thanks as always for the responses Brendan. 🙂
    Regarding one point:
    “Much of this is discussed on https://www.mozilla.org/ — you’ll have to read the “who we are”, “roles”, and “hacking” sections to get a complete sense.”
    The general bits are fine, but specifics are lacking. Although the hacking stuff talks about “mozilla.org” it really means Seamonkey – Firefox (i.e. /toolkit /browser and the aviary branch) has different rules (no superreview needed, although Firefox reviews tend to be more like Seamonkey superreviews – just a quick look rather than a thorough review, and core devs don’t need a review at all).
    “If the docs on the site need to say something more clearly, or if they just fail to cover a hot topic, please file a bug on the mozilla.org product.”
    That’s not really a useful thing to say, is it? A quick bugzilla query shows there are dozens of bugs filed months ago that have never been looked at. I’m sure you don’t actually want people to go through and file hundreds of bugs about all the out of date pages on the site – that would be silly. For example, the roles doc gives the impression that Foundation staff only provide guidance and don’t do any significant hacking, although that kind of matches up with the staff list which is current as of July 2003 and doesn’t list the employed hackers. Most pages in that section haven’t been updated to reflect the changes that happened last year. The branding doc which talks about Firebird being renamed to “Mozilla Browser” is also silly.
    And while I’m whining – I don’t suppose there’s any chance that the “interim roadmap update focused on the “aviary 1.0″ releases” will actually appear before those releases happen, is there? A couple of paragraphs in place of all that old stuff would be better than nothing…

36. Daniel Glazman: Ben is now in NZ, and we’ve had folks contributing crucial code to Firefox in different timezones for quite a while now. I’d be interested to hear why you had to use a XUL pre-processor #ifdef in toolkit, and so would others (perhaps moreso once the 1.0 pressure is off). Try email for now, you know the address.
    Michaell: Don’t worry, there’s no danger of the aviary 1.0 release happening too soon for a roadmap update to sneak in. 😉
    /be

37. Michaell, continuing: Ugh, the branding doc. That thorn in all our sides should have been removed long ago.
    Anyway, short of filing bugs, which gives me, at least, something countable to go beat up others supposedly in charge of the web site with, you could mail website-drivers@mozilla.org. As always, start small, provide patches where you can. Of course, 500 nit-picky to serious bugs would be bad — so I am not encouraging the world to file away. I really meant to address Neil Paris specifically. I’m all for human-scale, crawl-before-you-walk initiatives.
    /be

38. Brendan Eich:
    Sorry, I don’t know what you mean. Linus (or Andrew Morton, nowadays) picks and chooses kernel patches, sends many back just because they’re formatted badly, etc.
    A tangent from an outsider:
    Kon Colivas also maintains a tree. Until recently so did Andrea Arcangeli. As do some distributions. Some rejected features/implementations live indefinitely in alternate trees.
    While “the” kernel has decidedly top-down decision making, getting overruled with regards to the direction the official kernel will go is not quite as big a deal as it might otherwise be.
    As I understand it the firefox browser itself started as a branch/fork by disenchanted developers. But alternate Gecko browsers and extensions don’t seem to be keeping mozilla hackers happy; I’m not sure why.
    Just food for thought; I don’t have suggestions.
    P.S.
    The Comment Preview centers all the posts. I think it needs a <div class=”content”>. Yup, view source. But then I’m not a target user of Firefox.

39. First, a clarification. The view-source “issue” wasn’t an issue as far as I was concerned–I didn’t care whether Firefox had that functionality. It merely forced me to think about why it was that I didn’t care about the issue. My blog post was the result.
    Second, I agree wholeheartedly on the courtesy/respect issue raised by guanxi. It’s a pretty major issue, and directly ties in to my blog entry. A lot of my feelings about firefox stem directly from the frank rudeness of its public face (most often Asa, but at times also others).
    Last, a lot of the patches rotting in Bugzilla don’t have review requests on them because it’s rather non-obvious that such requests need to be made (or how they should be made). There is still no way to query for such patches, in spite of repeated requests for such (I’ve seen a lot of explaining of why it’s not needed, though).

40. I’m increasingly skeptical about the wisdom of the alternative style sheet UI removal decried by Daniel, and I’ll make sure that feedback from the preview release on this removal is heard and fairly evaluated.
    Blake has started a ‘discussion thread’ about this issue in MozillaZine. Very well, except that apparantly he chose not to participate (anymore?) in that same discussion, which makes it rather pointless. How can ‘the community’ know that their concerns are heard and fairly evaluated if these concerns are not even acknowledged?

41. I really hope the offline functionality doesn’t go away. Even if it (supposedly) isn’t perfect, it works almost reliably for me. I would have to go away to Seamonkey too…

42. I sure hope you folks will bring back the Alternate Stylesheet UI.

43. Hm, the link in my above post didn’t work; only HTML styling allowed, I see now. Here is the discussion about the AltCSS removal, started (but not continued) by Blake:
    https://forums.mozillazine.org/viewtopic.php?t=118119

44. I can certainly understand the frustration of someone who writes a patch, and waits forever for
    a review. My guess would be that the reviewer does
    not feel that this is particularly needed or even
    wanted to be included in the package.
    I am not in the postion to write patchs, but I have filed a few Mail/News bugs, that are perfectly
    valid, and against existing features, that were never even confirmed, since they went against someones ideas of what Mail/news should be.
    I am speaking mostly about the use of HTML/CSS in mail and News.
    To cite an example, certain Javascript operators
    ‘Ampersand’ and ‘greater than’ are escaped when script is sent via mail which requires that the
    script be re-written to avoid those characters.
    However, if you believe that javascript has no place in mail/news, you would not confirm this bug nor attempt to fix it.
    Some have tried to improve support for a ‘rich’
    Mail/News product, but for the most part it remains a plain text preferred media.
    (BTW I am not proposing loading up usenet groups
    with unwanted HTML, it should be sent to groups
    and individuals that expect and appreciate it.)
    But as a learning tool (and as a means of expression) it’s the only way to mail.
    Hmmm wonder why this appears centered in the preview

45. The suite will be around for a while, although it won’t be actively developed to have all sorts of new features, unless more volunteers step up and actually carry its full weight (including fixing bugs due to those looming Mozilla 2.0 API changes).
    OS-level inter-app integration of Firefox and Thunderbird is pretty good right now. There are a few more things to do, possibly as an extension, but I’ve been living in both and the combination wins over the suite, in my experience, for many reasons:
    Oh. That’s sure! I still belive in Fx/Tb value even if I’m very disapointed by the new way of coordinating in MF.
    My question was – if there is a plan to take Fx,Tb, Chatzilla and NVU, put them together with some buttons in status bar and release as new Mozilla Suite. Just for people who like Suite and it’s complexity.
    It’s very important for local communities which are most based on Mozilla Suite since their creation (like our – mozillapl.org) and moving away Suite to background will force us to move our own structures like help-desks, forums, localization release cycles into new level. Such information as the one you gave here – detailed as possible, should be spreaded widely asap in my opinion – just to give us some time – otherwise there’ll be huge mess in localization projects.

46. > I think the way DOM Inspector is handled now is great, and other exensions should be done the same.
    Then try to
    – Uninstall
    – Disable
    – Update
    it.
    Bundling some extensions would still be good (and still seems to be planned).

47. Please, please don’t remove View/Source, now or ever. It is a great learning tool.

48. Does anyone do any kind of user testing with Firefox, or is the UI completely at the mercy of Slashdotters and Mozillaziners?

49. Will the AVIARY-branch be merged with trunk?

50. Thanks for clearing things up.
    BTW, here is an idea for the clutter in context menu’s ..sub-menu’s.. I know this is possible in the context menu, because the web-developer is in a sub menu. So why not do this for some of the ‘lesser-used’ items in that menu (like printing and view source) (or better yet, move the stop and reload, backward and forward items in that menu)

51. It’s good to see things are working out. I look forward to testing the Firefox nightlies.
    BTW, on the comment preview page, the linked commenter names are the same color as the background so they cannot be read.
    —
    Brendan, ya need to delete the four spam comments above my comment… “Boston website design” seems like a legitimate company, but geez, blog spam? The “Pay per Click” and “Boston website design” links were posted a minute apart, and are by the same company (the design company advertising the search engine on their site).

52. Please, please don’t remove View/Source, now or ever. It is a great learning tool.
    This isn’t even a consideration – Right?
    —————————–
    Tax Man

53. I like the way the DOM inspector works now.
    ———————-
    Dano
    Car Racer

54. I’m with Dano. The way the DOM inspector works suits me fine.
    ——————-
    Steve S.
    Golfing

Comments are closed.