UI module owner

[Gervase Markham]

timeless wrote:
> Bugzilla should ship such that most companies don't feel the need to
> implement dozens of horrible hacks that cause them to refuse to
> upgrade to a newer version of Bugzilla later.

Gregg completely agrees with you.
http://wiki.mozilla.org/Bugzilla:Personas:Gregg

(BTW, everyone, the personas are still works in progress. Let me do a
bit more work before you lay into them :-))

> Bugzilla should be the standard tracking system that companies and
> organizations use, so that when I have a problem with any product
> anywhere, I can turn to a comfortable fairly standard Bugzilla
> installation which I can easily log into, select my standard per user
> custom settings and feel right at home explaining my problem or
> finding out the status of a preexisting report that I was able to find
> about my problem.

How likely do you think it is that these different
companies/organisations requirements will be similar enough that all the
Bugzillas will be "fairly standard"?

Thought: none of the current personas use multiple Bugzillas. Does that
mean that this is a niche use, or that we've failed to capture something
in the existing persona set?

> Bugzilla should enable any company to easily send a problem report to
> the next company or organization's Bugzilla without resorting to
> hacks. Note that in almost all cases this communication is
> bidirectional, it's not just a "move", it's some sort of "keep these
> bugs in sync" or "share comments across bugs" or "establish a
> dependency between these bugs". It's fairly rare for anything to be a
> simple "move" (the hack implemented for bugscape), most customers or
> consumers appreciate at least being told "this is fixed in the next
> version" and "the next version shipped with this fixed, you can
> actually download it now", which are things you don't get if you just
> "move" a bug.

Observation: even if we have "get as many people as possible using it"
as a goal, that doesn't by itself imply that moving bugs from one
Bugzilla to another, or linking them together, is a requirement.

Given that your aim is to have lots of people using Bugzilla in a
standard way, which makes it easy to just grab an account and log in,
why is the right solution to this problem just "move the bug
across/refile it, and have interested parties track it in the other
Bugzilla"?

Let's look analogous situations. If a user files a bug, and it turns out
that it's a duplicate of another one, do we "link them together and
share comments"? No, we mark it as a dupe, it gets closed and the filer
watches the other bug.

If a user files a bug in the Firefox product, and it turns out that the
problem is actually in the Core, do we open a core bug and link them
together? No, we move the bug to the Core product, and have it fixed
there - even if the bug report then becomes about fixing the underlying
problem, rather than the particular symptoms the user sees.

So why is it that we can't say that if someone files a bug in Mandrake's
Bugzilla about their browser, and it turns out to be a bug in Firefox,
we file a bug in b.m.o, close the Mandrake one and tell the users to
watch the b.m.o. bug? Yes, this could be made a bit easier by something
like the current "bug moving" mechanism but less hacky. But I don't see
the need for bi-directional linking, given that we don't use it in other
analogous situations.

[There's also the issue that I suspect that it would be a real pain to
implement, test and keep working, particularly when the Bugzilla
versions start getting out of step, and after a few years when we've
released four releases and the testing compatibility matrix starts
getting larger and larger.]

>> Clearly, it's not good to have only a few places using it - but we are
>> well past that stage.
> 
> It's not good for every single consumer of this product to fork it
> just to make it work for them.

The number of logical issues with that statement take my breath away.

Firstly, you start out by using a perjorative word ("fork") to buttress
your position, when what we are actually talking about is customisation,
which can be more or less of a "fork" depending on the customisation
mechanism used and the level of customisation required.

Secondly, you use over-generalisaion ("every single consumer") when
quite clearly by observation, not every single consumer of Bugzilla
makes significant customisations to it.

Thirdly, you over-exaggerate ("just to make it work for them"); again
clearly, by observation, Bugzilla already works in its default
configuration, and can meet a lot of people's needs.

All in all, not a good start as a basis for arguing for a particular change.

> It's not good for every single organization that does this to end up
> w/ dozens or hundreds of complaints which are lost in some internal
> problem report area. Every single organization I visit is either using
> or has tried to setup or use (sometimes both depending on the size of
> the organization) Bugzilla, and they all have valuable feedback about
> what's wrong or unusable about it. But we lose most of that feedback
> because it's internal.

OK... So what stops that feedback from ending up in
bugzilla.mozilla.org? And is there anything we can do about it?

>> Re-skinning an application (in the usual sense of the word "skin" - i.e.
>> changing colours and logos) has no effect on TCO.
> 
> The skinning we're interested in is more akin to guided, it's not the
> same as modern v. classic, it's the difference between advanced and
> simplified.

Then it might help not to call it skinning. The usual use of the word
"skinning" (and the Bugzilla use - see the skins/ directory) is making
graphical/cosmetic changes which do not have significant effects on the
underlying functionality. For that, we have historically used
"customisation".

>> > We just need a samples bundled in distro.
>> They are.
> 
> We have samples half bundled, we still have people asking how to
> integrate things very much like the guided entry form, which if they
> were fully integrated shouldn't happen.

The original rationale for the way they are bundled is that we wanted to
keep the distribution generic, rather than Mozilla-specific. So, we said
we would include the Mozilla-specific guided format as an example of
what could be done, and put a big comment at the top saying "this is an
example".

Are you suggesting that we should fully integrate Mozilla-specific
customisations into the stock Bugzilla, so they serve as better
examples? (That might be a reasonable thing to suggest.) If not, what
are you suggesting we change about the current method of bundling?

Gerv