Re: Removing Firefox Version Number

Isaac Stitz wrote:
 > On Aug 19, 11:30 pm, Asa Dotzler<[email protected]>  wrote:
 >> As I mentioned in an earlier post which asked a similar question,
 >> Mozilla is not purely data driven. We do use data as one of the
 >> tools in our tool belt, but we also have highly educated, and very
 >> experienced, and super talented people working all over the Mozilla
 >> project. So, we do not require data for all changes
 >
 > So, when *we* suggest that most users want to see the version number
 > to know what the version number is, you tell us we need data to back
 > it up.  Yet, when *you* suggest that users do *not* check the version
 > number to know what the version number is and *we* ask for data to
 > back it up, you say it's unnecessary because you're "highly educated"
 > and "super talented".

I'm sorry you're reading it that way, Isaac. I don't think it's 
unreasonable to explain the Mozilla system to you — that the people who 
have earned domain-specific authority on the Mozilla project are going 
to be the most expert on that particular area and that they are trusted 
to use their judgment (or any other tool of their choosing) to make 
decisions for that area. That is the how this project is organized. It 
may sound kind of harsh, but this isn't a democracy and not all opinions 
are equal.

Let me try to give you an example. Maybe that will help. (Maybe not?) 
I'm a member of the Mozilla community. I have been for 13 years. And I 
have lots of opinions about all kinds of areas in the project. I might 
one day, after using Chrome for a week, form the opinion that Chrome's 
networking library is better than Firefox's and I might go to the 
Networking team or module owner and say "you should switch to Chrome's 
networking library".

That's an opinion I'm totally free to have, and I think the Networking 
team would welcome my participation and even my criticism of our 
Networking library, but I am not an expert in Networking issues and I do 
not have a long track record of helping make Firefox's networking 
library great. I could certainly start learning — it's not magic, but 
it's a knowledge I don't have.

So, if the Networking team, or the module owner for the Networking code 
says "no, that's not what we're going to do. that's a bad idea." I may 
ask them why, but I will not demand that they prove with data that they 
are right and I am wrong. They know enough about both Mozilla's and 
Google's code and they know enough about how to write great networking 
features, and they have earned the responsibility and the authority for 
guiding the development of Mozilla's networking library, and so the 
Mozilla governance structure does not require that they have to prove to 
me that I'm the one that is wrong.

I posted this in a couple of other replies, but in case it wasn't in a 
reply to you, I'll repost. These are two URLS that should help you 
understand better how the Mozilla project operates. If after reading 
them, you have questions about how authority is distributed or decisions 
are made in the Mozilla project, do let me know. We can discuss in 
email, here, IRC, IM, anywhere that works for you.

http://www.mozilla.org/about/governance.html
http://www.mozilla.org/hacking/module-ownership.html

 >>> 2. Why haven't Mozilla conducted an online poll to check if users
 >>> would prefer this? If you have, mind publishing the results?
 >> While a Mozilla module owner is certainly empowered to put things up
 >> toa vote, the Mozilla project absolutely does not require changes
 >> must be subject to polls or popularity contests. That's just not how
 >> this project works. Again, I'd refer you to the links above if this
 >> doesn't make sense to you.
 >
 > No, you're not required to conduct a poll.  Not unless you want to
 > base your actions on real data instead of the whims of the "super
 > talented".

We have a number of paths to "real data". We have an entire team 
dedicated to User Research. We use data when we think it can answer 
questions we have. Other times, we made decisions based on our knowledge 
and experience.

 >>> 4. Asa's responses smack (if not reek) of hubris, and that, though
 >>> cavil, is enough of a reason to be put off.
 >> I'm sorry I've made you feel that way.
 >
 > Maybe if you stopped with the whole "we're super talented and highly
 > educated" attitude you'd make fewer people feel that way.  To coin a
 > phrase, "People do not care how much you know until they know how much
 > you care."

I don't pretend to be super talented or highly educated in the area of 
writing code. But Mozilla does have some super talented and highly 
educated programmers. I don't feel like they don't care about me or 
Mozilla because we do not share the same knowledge and experience.

If I were making demands of Mozilla programmers, telling them how to do 
their jobs and they told me "No, we're not going to do that because we 
know better." I would not call that hubris. I'd hope that they would 
take the time to listen to me and to answer reasonable questions, but I 
absolutely do not pretend that I know more about programming than they do.

I think that's completely reasonable.

I'm sorry if something in my tone makes that seem less reasonable. I do 
have to ask, if you could, for just a moment, put me aside, and just 
read the facts of what I've said and the information about how Mozilla 
works, and if that doesn't make sense to you, ask questions.

Not everyone knows how Mozilla operates. That's OK. Most people don't 
have to. But if you're going to participate in Mozilla, then 
understanding how we're organized and how responsibility and authority 
are delegated and how decision making happens is pretty critical.

 >> Transitions can certainly be uncomfortable, even painful. With a much
 >> larger community today than we had back then, it's going to be
 >> difficult for even more people.
 >
 > That being the case, isn't it all the more important for you to be
 > certain that the transitions you *do* force on people will be
 > beneficial?

Yes. We have done that. The decision to move to rapid releases was not 
an easy one. A lot of people put a lot of thought and effort into it. We 
believe it is beneficial but only time will actually tell. There is no 
certainty here. We're all just doing the best we can to make Mozilla 
successful in its mission.

 > So far you've provided no evidence that this one will be, and it
 > seems like you're causing way more discomfort and pain than this
 > little "bug" is worth.

Mozilla did not provide evidence that Tabbed Browsing was going to be 
successful. We made a good bet based on our judgment that the feature 
was going to be beneficial. Mozilla did not provide evidence that moving 
from SeaMonkey to Firefox was going to be beneficial -- though we had 
good reasons to believe it would be. Many things come down to judgment 
calls and Mozilla has a pretty good track record there.

As far as this bug, no, it's probably not worth it. Not right now 
anyway. But I discovered something interesting a couple of days after 
the discussion exploded. After reading several hundreds very passionate 
comments, it became clear that it wasn't really this version number bug 
that most people were upset about. It was actually the move the rapid 
release process and this was just one tiny aspect of that move that 
caused a lot of people who hadn't before realized that we were 
transitioning to a new model to suddenly realize that.

So, that's part of why I've continued this discussion and why I'm 
replying to you here. I'm very interested in what it is about the 
rapid-release process that is really most concerning to people. I also 
want to explain to people how this little bug fits in with a new model 
that they may not yet fully understand.

If we were doing releases every year or two, no one on the UX or Product 
team would likely suggest moving the version out of the About dialog or 
off of the website our out of Mozilla release announcements. But with 
our new process, lots of things have changed and some old concerns are 
no longer concerns and some new concerns have arisen.

And in that context, some people have also, sometimes violently, 
suggested that Mozilla's entire project structure should be changed to a 
democracy where all of Mozilla's decisions should be subject to a 
popular vote or to the demands of niche audiences. I've also tried to 
explain why that is not the case -- and has never been the case.

That's not because I'm telling you or anyone else that you don't count 
or that your opinions, or even your expertise, don't matter. I'm 
absolutely not saying that. I'm trying to explain to you how decisions 
are made in the Mozilla project. A part of how that works is that 
Mozilla leaders are expected to listen to feedback and criticism and to 
respond to it. But that does not mean that Mozilla leaders are required 
to make decisions based only on that feedback. (I believe that if 
Mozilla did put all major decisions up to a user vote, Firefox wouldn't 
exist today. It was terribly un-popular with not just the Mozilla users 
back in the day, but with many of the key Mozilla contributors.)

 >> Mozilla survived that last big transition. It was a tough decision to
 >> change course like that but I believed then that it was the right
 >> thing to do despite it being difficult. I think the evidence today
 >> heavily supports that it was the right thing to do. The move to
 >> rapid releases, which is responsible for much of the discomfort I've
 >> seen in this discussion about versions, was another tough decision.
 >> I believe that it's the right thing to do despite it being difficult.
 >
 > IMHO, you should save the PR nightmares for something a little more
 > important.  Ironically I've seen far more upset and far less
 > justification over this minuscule About dialog issue than I saw over
 > either of the two *major* transitions you just described.  Like
 > another poster said, choose your battles.

Yes. that's good advice. I'm not talking with you here as a battle 
though. I'm trying to explain to you how Mozilla works as much as 
anything else. I'm also trying to fulfill my responsibility to read and 
respond to as much constructive or well-meaning criticism as I can.

- A