The Severity of Polish
Alex Faaborg
sarcastic comment I made led to a kind of interesting conversation
about what our values are when it comes to creating finely crafted
software. He suggested that this might make for in interesting thread
in dev.apps.firefox, and I totally agree.
As probably most of you know, Shawn has been knee deep in f-sync stuff
recently, while I've been worrying about bugs like 426976 (removing a
very old and bright red dino head favicon that we ship to represent
"Getting Started"). The two things couldn't be more different, and
this led to the observation:
"Imagine we are all building a sports car, and everyone is heads down
solving some really serious issues with how to build the best engine
possible. We want this car to be the best sports car in the world.
Curiously, the sports car has some really ugly dice hanging from the
rear view mirror. Picking up those fuzzy car dice and tossing them in
the trash would really make a notable improvement to the car that we
are all so passionate about. It wouldn't even be hard, it would only
take a moment. But everyone has their heads down improving the
engine. Besides, the fuzzy dice have always been there, so they don't
really even bother us anymore. Unfortunately, when the car gets
released, every single one produced is going to have those same fuzzy
dice. Some of us already threw the dice away in our own cars, so we
forgot that we even shipped them. But on the bright side, the car is
going to be unbelievably fast."
...the analogy somewhat breaks down when you note that we have to
remember to destroy the fuzzy dice before we do a string freeze for
localization.
For several weeks I've been publishing lists of polish bugs on my blog
hoping to draw more attention to them with our community. If you've
been following any of them you may have noticed that this really
didn't work at all, failing to produce even a single patch. I believe
this is because community members instinctually want to work on things
that are viewed as important, things that will bring them more respect
in the community, things that will help us actually ship. Polish is
somewhere under Trivial or Enhancement, and as we often say: "if you
are not working on blocker bugs, you're not working."
A polish bug is by definition the opposite of a blocker bug. Polish
bugs are small, and blocker bugs are big. Polish bugs are changes to
something we have already shipped, blocker bugs are serious problems
that we could not possibly consider ever shipping with. Polish bugs
are "nice to have," and blocker bugs control the ship schedule.
If you look at companies like Microsoft and Apple, you see two very
different ideologies when it comes to polish and shipping. Microsoft
is filled with program managers who say things like "we must ship on
time, and if we miss little details, so be it, product management is
all about making tradeoffs. If you think polish is actually
important, you are naive and don't understand the realities of
shipping software."
Apple has Steve Jobs: "We must ship on time, but if you don't address
all of the little details I'm going to fire you." (This is obviously a
characterization, but they do appear to be very detail oriented).
I realize this will probably come to many as an unfortunate
comparison, but when it comes to polish we are pretty similar to
Microsoft. Microsoft is very logical: they prioritize issues, and
they ship when the top priority issues are addressed (producing a
product that still has a lot of icons that have weathered 13 years and
5 releases). It would appear Apple ships when their product meets a
level of pixel perfect quality. I would imagine that this must take a
certain level of illogical obsession with perfection (did they
*really* need to refresh the icon for the Utilities folder?)
Last week I asked Beltzner to block the release on removing the bright
red dinosaur icon. He sort of looked at me curiously, like he was
trying to determine between if I was being flippant or if I had
actually just declared how naive I was (I like to think of it as more
of an illogical obsession :).
Overall what I'm wondering is: is creating a polished product
something we even consider to be important? If it is important, what
kind of process actually produces a polished product? It clearly
isn't one that is based only on the logical prioritization of
individual issues.
-Alex
chris hofmann
>
>
> A polish bug is by definition the opposite of a blocker bug. Polish
> bugs are small, and blocker bugs are big. Polish bugs are changes to
> something we have already shipped, blocker bugs are serious problems
> that we could not possibly consider ever shipping with. Polish bugs
> are "nice to have," and blocker bugs control the ship schedule.
and accumulation of many polish bugs in any one area may point at
significant problems that hinder the chances of a successful release.
In some areas we have 20-30 polish bugs. That might mean we could
deliver a significantly better release if we took an extra day, week,
month to grind out polish bugs overall or in any one area.
Are the numbers above more or less than than what we shipped in fx1.5,
2, or 3? Do they represent an improvement or on those releases, or are
we back sliding?
To me thats how to build a rational for real improvement and getting
extra focus and attention on polish bugs, or security bugs, performance
bugs, compatibility bugs, stability bugs, or memory use bugs. Its
really the combination of all those things that people really notice and
drive their decision on which browser to use and how they "feel" when
they use it.
>
> If you look at companies like Microsoft and Apple, you see two very
> different ideologies when it comes to polish and shipping. Microsoft
> is filled with program managers who say things like "we must ship on
> time, and if we miss little details, so be it, product management is
> all about making tradeoffs. If you think polish is actually
> important, you are naive and don't understand the realities of
> shipping software."
>
Maybe that was the case in the past, but I don't think that is a good
characterization now. I'd say that Microsoft really can't ship
software "on-time" anymore. Its been years since they have done that.
They have been bogged down with too much bureaucracy and "rules" that
must be satisfied before a release happens.
We need a few rules and a few guidelines to help make sure we don't make
mistakes, but we should never let that replace good judgment, and good
communication and realistic views about where each area of the product
is before we ship.
> Apple has Steve Jobs: "We must ship on time, but if you don't address
> all of the little details I'm going to fire you." (This is obviously a
> characterization, but they do appear to be very detail oriented).
>
> I realize this will probably come to many as an unfortunate
> comparison, but when it comes to polish we are pretty similar to
> Microsoft. Microsoft is very logical: they prioritize issues, and
> they ship when the top priority issues are addressed (producing a
> product that still has a lot of icons that have weathered 13 years and
> 5 releases). It would appear Apple ships when their product meets a
> level of pixel perfect quality. I would imagine that this must take a
> certain level of illogical obsession with perfection (did they
> *really* need to refresh the icon for the Utilities folder?)
>
> Last week I asked Beltzner to block the release on removing the bright
> red dinosaur icon. He sort of looked at me curiously, like he was
> trying to determine between if I was being flippant or if I had
> actually just declared how naive I was (I like to think of it as more
> of an illogical obsession :) .
>
don't let the passion or obsession die, just channel it!
> Overall what I'm wondering is: is creating a polished product
> something we even consider to be important? If it is important, what
> kind of process actually produces a polished product? It clearly
> isn't one that is based only on the logical prioritization of
> individual issues.
>
I'm not sure it has been, is, or it should be. To me it has been, and
should be, a hybrid of the kind of systems that you describe above.
I also bet if you went looking though the Apple bug list you might find
quite a few less visible "dinosaur" icon like bugs that they just don't
get to for every release to stay on some kind of rational release schedule.
-chofmann
-Alex
Michael Vincent van Rantwijk, MultiZilla
> A few days ago I was having dinner with sdwilsh, and a somewhat
> sarcastic comment I made led to a kind of interesting conversation about
> what our values are when it comes to creating finely crafted software.
> He suggested that this might make for in interesting thread in
> dev.apps.firefox, and I totally agree.
>
> As probably most of you know, Shawn has been knee deep in f-sync stuff
> recently, while I've been worrying about bugs like 426976 (removing a
> very old and bright red dino head favicon that we ship to represent
> "Getting Started"). The two things couldn't be more different, and this
> led to the observation:
That bug report reads: "We are spending a tremendous amount of time,
effort and overall resources polishing every surrounding icon in our
interface, and yet we still have a bright red dinosaur in our default UI."
But is taking all this time justified, or not? Do people really care,
or not? Isn't that, as you call it "bright red dinosaur" also very much
about Mozilla roots?
> "Imagine we are all building a sports car, and everyone is heads down
> solving some really serious issues with how to build the best engine
> possible. We want this car to be the best sports car in the world.
> Curiously, the sports car has some really ugly dice hanging from the
> rear view mirror. Picking up those fuzzy car dice and tossing them in
> the trash would really make a notable improvement to the car that we are
> all so passionate about. It wouldn't even be hard, it would only take a
> moment. But everyone has their heads down improving the engine.
> Besides, the fuzzy dice have always been there, so they don't really
> even bother us anymore. Unfortunately, when the car gets released,
> every single one produced is going to have those same fuzzy dice. Some
> of us already threw the dice away in our own cars, so we forgot that we
> even shipped them. But on the bright side, the car is going to be
> unbelievably fast."
Eh, aren't you guys comparing apples with oranges here? Imagine you are
building a browser, just like: Opera, Microsoft or Apple?
Neither Firefox, Opera, Microsoft or Apples' browser will kill me when I
make a "bad decision" but a car accident might... just because some
engineer made a bad decision.
> ...the analogy somewhat breaks down when you note that we have to
> remember to destroy the fuzzy dice before we do a string freeze for
> localization.
>
> For several weeks I've been publishing lists of polish bugs on my blog
> hoping to draw more attention to them with our community. If you've
> been following any of them you may have noticed that this really didn't
> work at all, failing to produce even a single patch. I believe this is
> because community members instinctually want to work on things that are
> viewed as important, things that will bring them more respect in the
> community, things that will help us actually ship. Polish is somewhere
> under Trivial or Enhancement, and as we often say: "if you are not
> working on blocker bugs, you're not working."
And no wonder because the first thing a browser should do is work, be
functional and not crash. That should be the number 1 priority, and you
only go polish a product when it works.
There's too much emphasis on polishments, if you ask me, especially if I
have to believe comments like: "We are spending a tremendous amount of
time, effort and overall resources polishing every surrounding icon in
our interface".
But is that justified because so many people install themes, just look
at the numbers over at mozdev.org so whatever you do, we go ahead and
install yet another new theme.
To me polishing the a browser is good for one thing only and that is:
The first impression. Why? Because all your work is destroyed after
the first crash. Period.
> A polish bug is by definition the opposite of a blocker bug. Polish
> bugs are small, and blocker bugs are big. Polish bugs are changes to
> something we have already shipped, blocker bugs are serious problems
> that we could not possibly consider ever shipping with. Polish bugs are
> "nice to have," and blocker bugs control the ship schedule.
There are three different groups: You as developers, we as add-on
developers and the end-users. So what do we all have in common? What
do you and I want? A nice looking browser, one that "just works" or one
that works and looks nice? Most people would pick the latter, but is
spending all this time justified when the browser still crashes?
To you probably yes, to me and end-users NOT.
> If you look at companies like Microsoft and Apple, you see two very
> different ideologies when it comes to polish and shipping. Microsoft is
> filled with program managers who say things like "we must ship on time,
> and if we miss little details, so be it, product management is all about
> making tradeoffs. If you think polish is actually important, you are
> naive and don't understand the realities of shipping software."
>
> Apple has Steve Jobs: "We must ship on time, but if you don't address
> all of the little details I'm going to fire you." (This is obviously a
> characterization, but they do appear to be very detail oriented).
For your info: Steve Jobs wants developers to fix bugs from now on,
rather than introducing new features.
Again three groups here: Products that work, and products like iTunes
(just do a search for iTunes begin slow, even on genuine Apple hardware)
and product that work and look pretty.
Do you (MoCo) seriously like the Apple design? Then go hire great
industrial designers, and people with a PhD in UI design, because that's
what Apple did.
> I realize this will probably come to many as an unfortunate comparison,
> but when it comes to polish we are pretty similar to Microsoft.
> Microsoft is very logical: they prioritize issues, and they ship when
> the top priority issues are addressed (producing a product that still
> has a lot of icons that have weathered 13 years and 5 releases). It
> would appear Apple ships when their product meets a level of pixel
> perfect quality. I would imagine that this must take a certain level of
> illogical obsession with perfection (did they *really* need to refresh
> the icon for the Utilities folder?)
>
> Last week I asked Beltzner to block the release on removing the bright
> red dinosaur icon. He sort of looked at me curiously, like he was
> trying to determine between if I was being flippant or if I had actually
> just declared how naive I was (I like to think of it as more of an
> illogical obsession :).
But I don't want that "red bright dinosaur: to go, simply because this
is about roots and where Firefox comes from, as in Mozilla.
> Overall what I'm wondering is: is creating a polished product something
> we even consider to be important? If it is important, what kind of
> process actually produces a polished product? It clearly isn't one that
> is based only on the logical prioritization of individual issues.
>
> -Alex
I guess that questions depends on who you ask, because the number 1
priority for end-users will always be "do not crash" and whatever you
add is fine, or not like the "awsomebar" which to me is quite a
remarkable addition since everything in the browser has to be over
simplistic.
So let's sum up what I want: A browser that works, a browser that will
not crash, a browser that had less bloat and a browser that looks nice
when everything else works. But hey, that's just me ;)
Michael
John J. Barton
...
> A polish bug is by definition the opposite of a blocker bug. Polish
> bugs are small, and blocker bugs are big. Polish bugs are changes to
> something we have already shipped, blocker bugs are serious problems
> that we could not possibly consider ever shipping with. Polish bugs are
> "nice to have," and blocker bugs control the ship schedule.
Some time back I made essentially the same argument to claim that "error
messages never get fixed". It's not about the ship schedule, but whether
these kinds of issues ever get fixed. It's not about caring enough, but
rather about natural forces and their consequences.
> If you look at companies like Microsoft and Apple, you see two very
> different ideologies when it comes to polish and shipping.
Well, unlike Microsoft and Apple, in the mozilla world individuals can
take direct action on the issues that concern them. So go fix that red
dyno thing while I try to figure out what "security error 1000" means.
jjb
Dave Gomberg
>Overall what I'm wondering is: is creating a polished product
>something we even consider to be important?
This is a superb question. As a long-time lurker and a programmer
with 49 years experience and over 1M lines of code written (43
languages, from Asm to Forth), ask yourself why people LOVE Apple
(and do they LOVE MS)? It is the appearance of a FINISHED product
they love. No warts.
I worked for five months for a major database maker on the SF
Peninusla. There I encountered the MS mentality. It's nuts, if
you want to make a quality product. It is OK if you want to make money.
Is FF about making money?
--
Dave Gomberg, San Francisco NE5EE gomberg1 at wcf dot com
All addresses, phones, etc. at http://www.wcf.com/ham/info.html
-----------------------------------------------------------------
Justin Dolske
> Curiously, the sports car has some really ugly dice hanging from the
> rear view mirror.
Guess what you're getting for Christmas. :-)
> [...] failing to produce even a single patch. I believe this is
> because community members instinctually want to work on things that are
> viewed as important, things that will bring them more respect in the
> community, things that will help us actually ship.
I'm not sure I'd agree with that premise. I'd tend to suspect that
"scratching an itch" is what drives most folks, and that unfixed polish
bugs are a side effect of "good enough" scratching. It's easy to start
things, but finishing them (let along polishing them!) is a lot harder.
That said, there's probably a whole book to be written on "what
motivates open source contributors"...
> If you look at companies like Microsoft and Apple, you see two very
> different ideologies when it comes to polish and shipping. Microsoft is
> filled with program managers who say things like "we must ship on time,
> and if we miss little details, so be it, product management is all about
> making tradeoffs. If you think polish is actually important, you are
> naive and don't understand the realities of shipping software."
The "on time" issue is, IMO, a red herring. No one has ever shipped
perfect software, and some software products will stay doomed no matter
how much time they're given.
Rather, I think the meaty question here is how to incorporate
polish-level issues into the planning/prioritization process. What kinds
of goals should be set, and how do we measure progress towards those
targets? How should we gauge the relative importance of polish bugs to
other areas that compete for attention, like blockers, security,
standards compliance, new features, etc? [Come to think of it, these are
interesting questions to ask of those areas too.]
I don't know what the answer is. Certainly we could just take a
simplistic approach based on bug counts -- "fix 50 polish bugs for the
next release". But does fixing 50 random bugs help? Can we ship if we
only fix 20? Focusing polish efforts on a few specific areas would seem
more effective, although then you miss isolated bugs that don't fit into
a group.
Justin
Boris Zbarsky
> This is a superb question. As a long-time lurker and a programmer with
> 49 years experience and over 1M lines of code written (43 languages,
> from Asm to Forth), ask yourself why people LOVE Apple (and do they LOVE
> MS)? It is the appearance of a FINISHED product they love. No warts.
Of course there _are_ warts. (Want iPhoto to use your default mail
client to mail photos? Sucks to be you!)
The reason people love Apple right now (can't speak to how things were
10 years ago) is because it's a little less warty than the other
options, but more importantly because it's fashiionable, pure and simple.
Which is not to downplay the importance of polish; I just think Apple as
it functions today is not a great example: some things it does are
polished, but most things it does are not.
-Boris
Dave Gomberg
No one has ever shipped perfect software
I beg to differ. Although not PROOF it is perfect, I shipped 100
copies of a language processor with no discovered bugs. Of course,
since I had to pay for the tape duplication, I did my darnedest to
ensure that I could not find any bugs with careful reading.
Axel Hecht
<...>
>
> For several weeks I've been publishing lists of polish bugs on my blog
> hoping to draw more attention to them with our community. If you've
> been following any of them you may have noticed that this really didn't
> work at all, failing to produce even a single patch.
Quoting blatently out of context, sorry.
I, as I guess many others, read planet in a more aggressive way these
days than maybe a year ago, there's just tons of data. When I saw your
post, I figured "Alex is telling us that we should expect polish fixes
to still come". From the fragment that I read, it wasn't apparent to me
that you were actually trying to get volunteers to pick these up, as in
previous releases, we contracted the visual update out.
This is really just my personal perception, as I remember skimming over
a post of your on polish and being surprised that you were looking for
volunteers. Maybe you were just unlucky in not getting the attention of
folks that would feel great about an easy-to-get-yet-visual bug on their
plate.
Axel
Alex Faaborg
I'm guessing it's not a sports car :)
I should note that I mentioned Microsoft and Apple in the first
message as sort of archetypes, or overly simplified versions of two
fundamentally different approaches. They are obviously both big
companies that both make complicated products, and there are tons of
counter examples in either direction. But what I was trying to
highlight was what appears to be their general philosophy. For
instance, here is a (characterization) of how they approach polish:
http://people.mozilla.com/~faaborg/files/daf/severityOfPolish.png
Microsoft: "It's just the Offline Web Pages folder that you have to go
to a system directory to see. It's a low priority P37 change. It's
also hard to change because the icon is deep inside an old DLL, and
besides, we didn't even update it for Windows XP, 2000, ME or 98, so
it must not be that big of a deal."
Apple: "We are updating all of our customized system folders before we
release"
I had a conversation with a designer from Apple awhile ago about
polish bugs. The culture was so different the person actually didn't
even initially understand the premise my question, saying:
"what do you mean convince the product drivers about individual polish
issues? We initially scope out what we are planning on changing, and
then people finish their work, hopefully on time."
I'm not trying to contend that they always fix every polish bug, but
from the full conversation I inferred several fundamental differences
in their overall approach:
1) Polish issues are grouped together for survival. For instance "we
are updating all of the folder icons" instead of "should the Offline
Web Pages folder block? Should it be a P3 or a P4?" These also
appear to proactive goals instead of reactive requests during a triage
stage.
2) Polish issues aren't usually in direct competition with other work,
because there are different teams responsible, and there isn't a
central prioritization queue. So for instance if the Offline Web
Pages folder doesn't get updated it's because the art department
dropped the ball, not because the trident team was busy on important
stuff.
3) There are reviews for the interface as a whole, where rough edges
are called out and scrutinized
> I think the meaty question here is how to incorporate polish-level
> issues into the planning/prioritization process.
I like John's comment "It's not about the ship schedule, but whether
these kinds of issues ever get fixed. It's not about caring enough,
but rather about natural forces and their consequences"
I totally agree, if you place individual polish bugs, like rewording a
security dialog box, or removing a bright red dinosaur icon, into
direct competition with other specific bugs, they are going to lose
every time you triage and make hard decisions in order to ship. It
isn't because people don't care, but because the way that process is
designed, not addressing the polish issues is always the logical
course of action.
So that would imply that solutions that effectively address polish
issues must all be based on some type of isolation from the overall
process of bug triage.
Here are a few different ways you could isolate polish bugs:
Time isolation (mentioned by chofmann): everyone spends n days at the
end of the ship cycle only working on polish issues
Developer isolation: n people (probably where n is 1) spend all of
their time working on polish bugs
Team isolation: developer isolation where n > 1, sort of a front front-
end team
Prioritization isolation: before we ship we have to address all
blocker bugs, and several predetermined polish goals (like "the main
window must be a pixel perfect match of the photoshopped design
mockup" or "we must land all the new icons we produced")
Review isolation: kind of like our current security reviews, major
feature areas each go through a review of surface level issues, things
like writing tone, visual design, consistency
Another consideration beyond our process is our tools, and the way
that they influence us. Currently bugzilla is designed to track
individual issues, and we have a rule against blocking on any kind of
meta or tracking bugs (things that combine multiple issues). This
obviously stacks the deck against a group of small things that
individually aren't a big deal, but collectively they impact the
overall quality of the product. Perhaps this could be addressed by
creating some type of meta bug that encapsulates a specific set of
bugs (so that it can't quickly grow and become all unwieldy).
-Alex
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Dave Townsend
> For several weeks I've been publishing lists of polish bugs on my blog
> hoping to draw more attention to them with our community. If you've been
> following any of them you may have noticed that this really didn't work
> at all, failing to produce even a single patch. I believe this is
> because community members instinctually want to work on things that are
> viewed as important, things that will bring them more respect in the
> community, things that will help us actually ship. Polish is somewhere
> under Trivial or Enhancement, and as we often say: "if you are not
> working on blocker bugs, you're not working."
I partly agree and partly disagree on this. I think people will work on
what they feel is important to them. If one of the polish bugs you post
happens to be about something they don't like then they will work on it.
I had something of a different result when I posted a list of good
easyish bugs for people to work on in the extension manager, most of
them got patched. In fact I keep meaning to go through and try to find
some more to post about.
Dave
Marco Bonardo
> For several weeks I've been publishing lists of polish bugs on my blog
> hoping to draw more attention to them with our community. If you've
> been following any of them you may have noticed that this really didn't
> work at all, failing to produce even a single patch.
well, that's not completely true, while working on adding the tagging UI
to bookmark properties dialogs i fixed (will fix when patch will land) 2
issues that were in your polish requests, so your post has been useful
to me since i didn't know about one of them. So i think it makes sense
looking at polish bugs when working on a certain part of the UI.
Globally i think that clearly visible polish problems have an higher
visibility on user side rather than backend minor issues that he could
maybe encounter only in rare situations.
-mak77
Mike Beltzner
> Alex Faaborg ha scritto:
>> For several weeks I've been publishing lists of polish bugs on my
>> blog hoping to draw more attention to them with our community. If
>> you've been following any of them you may have noticed that this
>> really didn't work at all, failing to produce even a single patch.
>
> well, that's not completely true, while working on adding the
> tagging UI to bookmark properties dialogs i fixed (will fix when
> patch will land) 2 issues that were in your polish requests, so your
> post has been useful to me since i didn't know about one of them. So
> i think it makes sense looking at polish bugs when working on a
> certain part of the UI.
And thanks for that effort, Marco, as well as to anyone else who took
a swing at the bugs Alex mentioned or any other polish bugs taken down
this cycle. I'm sure that Alex didn't mean to trivialize the amount of
work that's gone in to polish bugs to date, but was rather trying to
highlight what is perceived as a systemic bias against polish bugs in
favour of new feature work at the platform or UI level.
> Globally i think that clearly visible polish problems have an higher
> visibility on user side rather than backend minor issues that he
> could maybe encounter only in rare situations.
Again, agreed, and while I think that drivers have done a reasonably
good job of being open to polish issues early in the cycle, and only
getting restrictive as we move towards a freeze, I can think of a
couple of times when I've gritted my teeth and held my nose while
rejecting a bug for blocking status. At the same time I can recall at
least once or twice where we *did* block on polish items that would be
very visible.
More soon, I have a lot of thoughts on this topic, including a few
proposals as to how we can try to reach a better place in terms of
ensuring we don't get into cycles of "yeah we should fix that when we
have time" ... (time passes) ... "crap, out of time!".
cheers,
mike
Myk Melez
> Again, agreed, and while I think that drivers have done a reasonably
> good job of being open to polish issues early in the cycle, and only
> getting restrictive as we move towards a freeze, I can think of a couple
> of times when I've gritted my teeth and held my nose while rejecting a
> bug for blocking status. At the same time I can recall at least once or
> twice where we *did* block on polish items that would be very visible.
I'm as guilty as anyone (if not more so) of not giving polish the
attention it deserves. Nevertheless, overall I think the problem isn't
individual engineers, drivers, or other folks. Drivers have been doing
a great job of managing the process based on our current priorities.
The problem is that we don't prioritize polish enough as a community.
Part of that is personal: we ourselves aren't bothered much by those
issues. As Alex noted, we've long ago accommodated ourselves to that
extra click, tiny visual distraction, or other minor glitch.
Part of it is historical inertia: we haven't prioritized such bugs in
the past, and the project has been pretty successful, so we haven't felt
much pressure to change our process and priorities.
And part is the consequence of our bug-centered prioritization process,
since any individual polish bug is relatively unimportant and thus easy
to ignore; it's only in the aggregate that they impact our quality.
> More soon, I have a lot of thoughts on this topic, including a few
> proposals as to how we can try to reach a better place in terms of
> ensuring we don't get into cycles of "yeah we should fix that when we
> have time" ... (time passes) ... "crap, out of time!".
One potential solution to the problem would be to have a two-stage
blocker cycle, where we first fix bugs that are traditional blockers
(based on our existing criteria), and then, once that list has bounced
off zero, we repopulate it with polish bugs that block our release.
We'd have to build time into the process to fix those bugs. And it
isn't a complete solution, since not all polish bugs are low enough risk
to be fixed at the end of the cycle. But it would ensure that anyone
who cares about releasing would have a razor sharp focus on those bugs
for that period of time, since it would be the only thing holding up the
release.
Or we could simply expand our idea about blockers to encompass both
traditional blockers and polish bugs.
Ultimately, the specific mechanics are less important. The key is to
decide that we actually do care about polishing our product until it
shines. Once we do that, we can devise the process that incents
everyone working on the product to take polish seriously.
-myk
Nils Maier
...
>
> For several weeks I've been publishing lists of polish bugs on my blog
> hoping to draw more attention to them with our community. If you've
> been following any of them you may have noticed that this really didn't
> work at all, failing to produce even a single patch. I believe this is
> because community members instinctually want to work on things that are
> viewed as important, things that will bring them more respect in the
> community, things that will help us actually ship. Polish is somewhere
> under Trivial or Enhancement, and as we often say: "if you are not
> working on blocker bugs, you're not working."
>
> -Alex
I actually looked at some of those bugs, and I'm likely even skilled
enough to produce some quality patches.
However, what drove me away is that it's actually not much fun to work
on ANY mozilla bugs (not just polish bugs):
* Produce a patch, test it, describe what it's doing. Matter of hours or
days.
* Spend weeks or even months before you get somebody to even have a
first quick look at it.
* Answer some questions.
* Wait months until somebody does a review. (Try to nag people to do
such a review, mostly without any success).
* Wait months until somebody does a super-review.
* Be unlucky and observe that it then takes months again for somebody to
commit said patch (being an entry-level hacker lacking commit privs
yourself).
I stopped nagging quiet some time ago, as it is such a boring,
burdensome task.
I can't really blame the core developers (those with review/commit
power) as it is quiet clear that their workload is already huge if not
overwhelming.
I maybe have to blame me for not nagging enough; however I don't have
more time to spend (or that I'm willing to spend).
To me it appears that the various mozilla projects and modules became to
bureaucratic in some areas and that other areas seriously lack manpower.
Sorry if that was to angry, bitter or offtopic.
Nils
Mike Beltzner
> Ultimately, the specific mechanics are less important. The key is
> to decide that we actually do care about polishing our product until
> it shines. Once we do that, we can devise the process that incents
> everyone working on the product to take polish seriously.
An excellent sentiment, and I think a little rhetorical. You'll be
hard pressed to find anyone who would say that they don't "care about
polish", nor anyone who thinks that it's ok to ship an unpolished
product. But, at what point does it "shine" enough to ship? This, I
think, is something else that is pretty subjective, and where I
anticipate most of our disagreements and debates will occur.
You can take an all-or-nothing approach, but as has been pointed out,
not even Apple actually does that, and in a lot of cases one of the
primary values of our project (being customizable - what if someone
likes fuzzy dice?) often leaves us with hard decisions to make about
the relative importance of polish vs. the ability to customize.
Further, there's a well-documented law of diminishing returns on
creating "bug-free" software - this is doubly true when bugs are a
matter of aesthetics, as is often the case with polish bugs.
You can take a percentage-of-polish-bugs approach, too, but then it's
a tacit admission to not shipping a product that's 100% polished. Does
that mean we don't care about polish as an organization?
In order to change our attitudes here we need to get crisp around:
- what is polished enough to ship?
- are there different severities of polish?
- how can we change our focus on polish?
I think the security group actually has some good lessons for us,
here, in terms of creating a severity ranking and criteria about what
severity levels we can and cannot ship without.
cheers,
mike
Michael Vincent van Rantwijk, MultiZilla
<snip />
> 1) Polish issues are grouped together for survival. For instance "we
> are updating all of the folder icons" instead of "should the Offline Web
> Pages folder block? Should it be a P3 or a P4?" These also appear to
> proactive goals instead of reactive requests during a triage stage.
>
> 2) Polish issues aren't usually in direct competition with other work,
> because there are different teams responsible, and there isn't a central
> prioritization queue. So for instance if the Offline Web Pages folder
> doesn't get updated it's because the art department dropped the ball,
> not because the trident team was busy on important stuff.
But you /are/ asking for help/more people working on this kind of bugs,
right? So if it shouldn't be done by the trident team, who will be
doing this work?
> 3) There are reviews for the interface as a whole, where rough edges are
> called out and scrutinized
Let's add one simple example, have a look at Larry's panel, the one with
the "More information..." button, which makes me think that something
went seriously wrong - because that button should never have been
accepted since it is bad UI (not to mention the page info dialog with
its "more" button. Making people go click-click-click while it should
have been one single click.
I personally was rather disappointed, because I did spent some
time/thinking on it, but hey, that didn't help now did it?
Note: I like what the UI people, including you, are doing. At least in
general, and yes I might sound harsh from time to time (I'm told?) but
that's not intentional because try to speak my language (Dutch) and see
how far you come, but that's no excuse so if I offended you, or anyone
else here, then I apologize for my bad manners/behavior.
Michael
Axel Hecht
I glanced over the bugs that Alex posted, and most of them are just
graphics. At least one of them has l10n-impact though (the app stuff in
the first post).
Those obviously can't land late.
Side note, https://bugzilla.mozilla.org/show_bug.cgi?id=459950 claims to
be polish, too, and IMHO is not. It's fixing half the strings in session
restore, which is sad at this point in the schedule.
I see a difference between "this is some UI we did years ago, and it's
not up to our standards anymore" and "let's land this now, and polish it
in a follow up bug". The latter just wastes time in our l10n community.
Axel
Alex Faaborg
> took a swing at the bugs Alex mentioned or any other polish bugs
> taken down this cycle. I'm sure that Alex didn't mean to trivialize
> the amount of work that's gone in to polish bugs to date
Yes, I certainly didn't mean to trivialize previous effort that have
gone into polish bugs (and it will be great when Marco's patch lands
to fix up a few of them!), what I was trying to get at is the way
polish bugs really face an uphill battle in our process, and how this
ultimately makes it less likely that people will want to work on them
(like the ones I blogged about).
> In order to change our attitudes here we need to get crisp around:
> - what is polished enough to ship?
> - are there different severities of polish?
> - how can we change our focus on polish?
Going through each:
> - are there different severities of polish?
Certainly. An old bright red dino icon in the most primary area of
primary UI is worse than the fact that we use the wrong icon for "Save
File" in the applications prefpane on Windows.
When we nearly shipped the old version of the Firefox application icon
by accident for Firefox 3, that is probably the biggest polish bug one
could possibly have.
You are technically right when you say that Apple doesn't take an "all
or nothing" approach (for instance the tuxedo shirt in their Bluetooth
Setup Assistant wizard looks pretty bad). However their nuanced
approach really is much closer to "all" than it is to "nothing."
> - what is polished enough to ship?
In terms of visual polish, I think we need to do things like:
-make sure UI elements line up correctly
-make sure padding is correct
-make sure elements like our text fields aren't all different sizes
(especially when they are right next to each other)
-make sure elements are using the correct color
-land all of the icons that were produced
For the ship cycle of Firefox 3 all of these visual polish aspects
were triaged out under the logic that they do not individually matter,
and we can fix them in 3.1.
> - how can we change our focus on polish?
There are really two different types of polish bugs:
-The polish bugs that are too big to bother fixing (focus ring,
bookmark menu underlines)
-The polish bugs that are too small to bother fixing (landing new
icons, color, alignment. Most of the stuff in this category is css
changes that can be tested first with userchrome.css)
For the hard polish bugs, I think we need to have a front end
developer dedicated to fixing them.
For the small bugs, I really like Myk's idea of creating a list of
blocker polish bugs that everyone quickly knocks down before the first
release candidate. This might delay the release by a day or two
(anything larger by definition doesn't fit in this category), but it
will really help Firefox look like a finely crafted application.
A few people have asked for a complete list of all of the existing
polish bugs I'm thinking about, I'll get that posted today.
-Alex
On Oct 27, 2008, at 1:59 PM, Mike Beltzner wrote:
> On 27-Oct-08, at 4:37 PM, Myk Melez wrote:
>> Ultimately, the specific mechanics are less important. The key is
>> to decide that we actually do care about polishing our product
>> until it shines. Once we do that, we can devise the process that
>> incents everyone working on the product to take polish seriously.
>
> cheers,
> mike
Quan
Firefox release, please please please someone look at this:
https://bugzilla.mozilla.org/show_bug.cgi?id=454338
It makes the Bookmark Menu look a mess if you have even just the
default smart folders and RSS feed mixed in with other folders.
But also please remember, polish bugs don't have to just be visual,
consistency and intuitive approach to things are often considered as
just polishing things off but they make a big different (like right
click on a static item in the bookmark toolbar menu referring to it's
parent, icons being made uncustomizable or drag & tear tabs seemingly
not going to make it for 3.1). Bugs like this might not make faster
times on the sunspider benchmark suite, or garner any feature
headlines on launch day (well drag & tear might), but they mean a lot
in day to day operations for every day users.
Alex Faaborg
> polish bugs I'm thinking about, I'll get that posted today.
http://blog.mozilla.com/faaborg/2008/10/28/polishing-firefox-week-n-special-edition/
Here are the whiteboard terms I am using:
[polish-easy] - updating an icon, css changes, etc.
[polish-hard] - something that is not trival to fix (like rewriting
the focus code)
[polish-visual] - something you would see in a screenshot
[polish-interactive] - something that you have to use the mouse or
keyboard in order to encounter
[polish-high-visibility] - something that users could encounter
multiple times a day
So for instance the menu underlines bug is: [polish-hard][polish-
visual][polish-high-visibility]
Cheers,
-Alex
On Oct 28, 2008, at 4:10 PM, Alex Faaborg wrote:
>> And thanks for that effort, Marco, as well as to anyone else who
>> took a swing at the bugs Alex mentioned or any other polish bugs
>> taken down this cycle. I'm sure that Alex didn't mean to trivialize
>> the amount of work that's gone in to polish bugs to date
>
>>> Ultimately, the specific mechanics are less important. The key is
>>> to decide that we actually do care about polishing our product
>>> until it shines. Once we do that, we can devise the process that
>>> incents everyone working on the product to take polish seriously.
>>
William Ehrich
Firefox 3 has dark backgrounds in the header fields, especially the tabs,
making them hard to read (using white text for the tabs would help).
This would seem to be very obvious, easy to fix, polish bug. Trivial for
whoever knows where in the code the colors are defined but hard for anyone
else, and perhaps very hard to get through the approval and scheduling
processes.
In the meantime I hope that version 2 will continue to be available and
updated.
-- Bill Ehrich
MacOSX 10.4.11 Firefox 2.0.0.18