[ham] Goals for 2.22?

[Kevin Benton]

On Sun, 2004-11-28 at 10:57, Mick Weiss wrote:
> I'd like to see an up to date list of "these patches need to be
> reviewed", "these are being reviewed by..." and an explanation of how to
> get a patch into bugzilla. I remember a patch for LDAP SSL/TLS a while
> back. I'm still not sure if it made it into Bugzilla itself.
> 
> A definite must would be a "how can I help". The other thought that I
> had was company sponsorship. So some people can get paid to work on
> Bugzilla. IIRC someone from AMD is now developing Bugzilla and Dave is
> at least part time working on it (since he is now working for the
> Mozilla Foundation - I believe that thread was "Re: Fostering developers
> (was Re: Feature Request)").
> 

That would be me.  The challenge for me is that I'm still behind the
learning curve with BZ so I would not consider myself ready to do patch
validation yet.  The other challenge is that in order for me to do some
of that work, I have to justify it to my boss.  It's not too difficult,
however, I don't see myself doing patch validation for others for at
least a few months.  Until then, I will be spending lots of time
learning how BZ does things and becoming a BZ knowlege expert in the
company.  I'm not there yet. 

> How could Bugzilla go about getting company sponsors?
> 

I think you probably have more than you're aware of.  The challenge we
face is to make a business case for companies to devote resources that
they would need to use to help them make money to aiding the BZ
development.  It has to be a win-win situation or you won't get
participation.  For AMD, it's often a win-win because we're already
using BZ heavily - which is also why they hired me full-time to do BZ
development.

I know that some in this group might think that reporting isn't all that
critical apart from reporting what needs to be fixed now, and having
history of what's been done.  I am here to tell you that great reporting
is one of the keys to gaining tremendous company sponsorship at every
level.

In order to do that, we have to ask ourselves the question, what kinds
of things are upper-level managers *and* front-line engineers looking
for from a tool like BZ?  Plain and simply, managers want reports that
give them the bird's-eye view of what's happening with the ability to
drill-down to issues.  Right now, that's difficult to get from the stock
installation of BZ.  For example, as a former manager, I often measured
things like time to resolution on a weekly basis over a quarter.  From
what I can see, it's possible to generate this type of report from stock
BZ, however, to get it, it requires going through a lot of steps to get
it.  In fact, it is this type of reporting that my customers inside the
company are asking for, both at the management and the engineering
level.

Why are these reports needed?  It's difficult to quantify process
failures if there's no easy way to identify what problems are killing
performance.  With appropriate reporting, locating those process
failures become much easier.  Process improvement allows managers to
help their teams work smarter and more effectively without having to
work harder.  For example, a team I managed was responsible for
responding to systems that weren't working properly.  They got their
alerts via email.  This meant that they were constantly tied to their
mail readers.  To free them up, I placed a system in the NOC that would
receive the same email messages and verbally announce when something
came in that needed their attention.  This allowed the team members to
remain focused on solving problems more and worrying less about incoming
emails.  This, along with other improvements like it, allowed the team
to see a 90% increase in performance while simultaneously decreasing the
team's size (through promotion).

Here are the reports I'm looking to develop using Crystal Reports that I
think should be in BZ's stock reports:

o Time To Resolution over time (i.e. bar graph showing avg. time it took
to resolve bugs that got resolved each week over a 13 week period)
o Time in Queue over time (meaning how long did a particular group hold
on to the issue)
o Time To Acknowledgement (how long till the bug was seen by someone who
could direct it where it needed to go)
o Number of Bugs in Queue over time (how many bugs were in the queue
last week?)
o Number of Bugs Opened over time
o Number of Bugs Resolved over time
o Number of Bugs Pending over time
o Number of Bugs set to Won't Fix over time
o Number of Bugs Reopened over time

Being able to drill-down into those reports would give the user the
ability to look at the sources for each report, giving them the ability
to troubleshoot processes.

I think this is clearly a large undertaking, however, I think it is
critical to the success of Bugzilla against any commercial applications
that may be out there.  I think that by adding this type of reporting,
many more companies will look seriously at BZ as a key resource.

> When someone writes something like:
> <snip>
> Hello,
> 
> I didn't receive any response to my last e-mail when I sent a patch that
> added START TLS support to Auth/Verify/LDAP.pm.  I have attached a slightly
> revised patch to the bug itself at
> 
>    https://bugzilla.mozilla.org/show_bug.cgi?id=250916
> 
> We are currently using this patch where I work and we are eager to get
> this patch included into Bugzilla proper.  Please let me know what I can
> do.
> 
> Thank you.
> -- seth / @sethdaniel.org
> </snip>
> 
> I can understand how de-motivating it can be when you don't get a reply.

Ditto.