Bugzilla: Philosophy

[Guy Pyrzak]

Bugzilla can be used for a LOT of things, trust me I'd know.

But I think you're right Gerv, the "philosophy" is more about maintaining
and narrowing scopes and features than "philosophy". Does that change
anything about the reality of the tool? I don't think it does.

However, what it might change is how we support people who want to make it
more than a bug tracking system. Maybe we (the core developers) write a few
enhancements to make bugzilla a more of a ticket tracker, or more of a PMS,
but those are all extensions?

Francois just pointed out that he has had to do a bit of work to get around
the severity field's restrictions but there could be a few extensions or
code organizations to make it easier to do (I do think we're headed in that
direction as we move more fields into fields.js btw.

However, as Max would point out, we can focus on extensions once Bugzilla
isn't so unwieldy and unfriendly.

So I was reading the first line (i stopped there because i realized it could
become a whole new conversation).

Gerv wrote: *To help people fix bugs in software.*
Max wrote: *To help people store and organize bug reports.*

I'm not sure either are great, however, Gerv your statement could also be
applied to an IDE, which are actually used to "help people fix bugs in
software" in fact if that was Bugzilla's philosophy then we'd need to add a
debugger, something that lets users check in code from the UI, review the
test cases against newly checked in code, stuff that testopia does... well
you get the idea. Now many (myself included) would say "Geez don't be so
litteral" but we all know that many folks will see Gerv's statement and
start arguing for all sorts of new features.

I'm not much of a word smith so I'm not going to try to say the 1 sentence,
but I think it should include the words file/communicate, triage/understand,
find, follow and disposition bugs.

But as a developer  the software that "helps me fix bugs in software" is my
IDE or my debugger. My bug tracker just tells me what to do next, how bad
the situation is for an existing bug(/component/product based on bugs
filed), find out how people think a bug should be fixed and lets me tell
others I'm done and when and also lets me find out what others users found
wrong.

To be clear to Gerv, I like your philosophy, but it doesn't fulfill the main
purpose of stating this philosophy. So I'll state the reason/rationale for
stating the philosophy....

*To avoid scope creep and feature enhancements on a product (Bugzilla) which
is already unwieldy and not user friendly by many accounts*.

So maybe the Bugzilla philosophy for now could be:
*To not add any big new features that don't serve the purpose of simplifying
and easing the use of existing features in Bugzilla.*
*
*
But that's a tongue-in-cheek philosophy, so don't go posting this as the new
Bugzilla philosophy! Besides we all know Bugzilla doesn't support fixing
bugs on multiple branches very well, we should add that feature, erm i mean
"enhancement" :P.

-Guy

On Mon, Mar 1, 2010 at 3:36 AM, Francois Cottet <fct.java at gmail.com> wrote:

> Hi folks,
>
> While I agree that Bugzilla is not meant to replace any PMS, there are
> few enhancements which would be welcome.
>
> A simple one is a clear separation between bugs and enhancements.
> https://bugzilla.mozilla.org/show_bug.cgi?id=9412
> "In my humble opinion" bugzilla is used in a more complex way than
> just a bug tracking system, most installation I have seen actually use
> Bugzilla as a "change tracking system".
> In my organization people (developers and managers) complain
> frequently about the interface, mainly because they can see at one
> glance what are the bugs and what are the enhancements.
>
> When a public release of a product is scheduled, people want to focus
> on bug fixing, while once the release is done and the product stable.
> We want to review the enhancement requests.
> Currently we use the "severity" field but it's a workaround and it
> seems that quite a few installations have to deal with that
> workaround.
>
> Best regards,
> Francois
>
>
>
>
>
>
> On Mon, Mar 1, 2010 at 18:42, Gervase Markham <gerv at mozilla.org> wrote:
> > On 27/02/10 03:50, Justin Wood (Callek) wrote:
> >> help PEOPLE fix bugs. PEOPLE to fix bugs well usually wish to have a
> >> project management system of some sort. In Mozilla Project Management
> >> uses Bugzilla features for their ease of use, while I also *agree* it
> >> should NOT be a project management system this point should be felt more
> >> through the other goals rather than in opposition to them.
> >
> > Well, let's reconsider the question entirely, just as a thought
> experiment.
> >
> > Why do we want Bugzilla not to be a project management system?
> >
> > 1) It increases code complexity
> > 2) It increases UI complexity
> > 3) It spreads development and testing resources thinner
> > ...
> >
> > Why might someone want Bugzilla to be a project management system?
> >
> > 1) There are organizational benefits of having your PMS and your task
> > tracker closely integrated
> > ...
> >
> > (any more for either list)
> >
> > So perhaps "Bugzilla is not a project management system" is not a bit of
> > philosophy; it's more a practical restriction we have decided to make to
> > avoid scope creep and focus our resources.
> >
> > Gerv
> >
> >
> > _______________________________________________
> > dev-apps-bugzilla mailing list
> > dev-apps-bugzilla at lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-apps-bugzilla
> > -
> > To view or change your list settings, click here:
> > <http://bugzilla.org/cgi-bin/mj_wwwusr?user=fct.java@gmail.com>
> >
> _______________________________________________
> dev-apps-bugzilla mailing list
> dev-apps-bugzilla at lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-bugzilla
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=guy.pyrzak@gmail.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20100301/5129931a/attachment.html>