[Libreoffice-qa] suggestion for weekly-bug-summary

[Robinson Tryon]

On Fri, Jan 30, 2015 at 1:52 AM, Bjoern Michaelsen
<bjoern.michaelsen at canonical.com> wrote:
> On Thu, Jan 29, 2015 at 04:14:24PM -0800, Joel Madero wrote:
>> I've never been a fan of this split to begin with. Having a much less
>> visible means of suggesting enhancement requests or bugs pretty much
>> just sucks. Just speaking for myself, I'm very unlikely to report any
>> enhancement requests about bugzilla on redmine...
>
> Oh, hate the split too. The split will not go away easily though (I tried.
> Hard.). Yeah, sucks. Still, the best we can do now is have a clear cut rather
> than fractured border between the two.

It's indeed frustrating to go through the work of the Bugzilla
migration, only to run into the challenges presented by a split
bugtracker. Two bugtrackers may not be ideal, but there are some
concrete steps we can take to reduce the pain:

* Set up LDAP to allow shared logins for both trackers
* Decide on protocol for dealing with bugs misfiled in the wrong tracker
* Make sure that QA and other groups feel welcomed to file bugs and
enhancements in redmine, particularly against Bugzilla

>> So we're only tracking enhancement requests if the reporter can either
>> (1) do it themselves; or (2) they can show that it's reasonably
>> resourced? I can't imagine a similar strategy working for LibreOffice
>> itself - we might as well close 99% of enhancement requests. I don't get
>> why we'd have two different "philosophies" just because one is "infra"
>> and the other is .... something else?

IMHO, just because we're mandated to use a different tool shouldn't
change our policies regarding what's valid. Others with bigger hats
can always override me, but at least for enhancement suggestions
regarding Bugzilla, I'd suggest that we use the same threshold as we
use for bugs filed in Bugzilla.

> So, maybe Im overcautious. ;)
>
> As an exaggeration: There is a risk that we end up with 20 people working on
> making our Bugzilla nice and beautiful and 1 guy working on triaging
> LibreOffice. Also note that all customization cumulates to create extra pains
> during updates etc.  IMHO we should just keep in mind to keep the fixed costs
> of running our Bugzilla constant and rather low[1].

Sure, there are definitely trade-offs to be had. All of the QA Team
work that will take place in Redmine will be meta-work, and I expect
those tasks will appeal to only a subset of our total members. The
entire goal of the meta work will be simplifying and improving the
effectiveness of QA, so if we end up with a 20:1 ratio of people
improving Bugzilla vs. Triaging, either we'll end up with the best
improvements to any Bugzilla, anywhere, or we'll run out of tasks in a
week!

Now that we've upgraded Bugzilla to a much more modern version, we can
also take a look at our current bug workflow and compare that to the
suggested workflow from Bugzilla itself. It's possible that we might
want to adopt some of the new changes from upstream.

> [1] For example that we ended up with a Redmine/Bugzilla split (which is
> already a simplification over the mess we had before that) is ultimately a
> result of bit too much fast-and-loose play with extending, creating and
> customizing services.

Lesson learned: It's always good to try to plan for the future, and to
involve other TDF/LibreOffice teams when making decisions that impact
them.

Cheers,
--R

-- 
Robinson Tryon
QA Engineer - The Document Foundation
LibreOffice Community Outreach Herald
qubit at libreoffice.org