The future of bugs.slimdevices.com

[Phil Leigh]

>>
Yep that's part of my direction from management, they want support to do support and QA to do QA. And I agree with them.

That makes perfect sense (even though QA are often better placed to answer support questions!)

>>
That is, in fact, the direction we're moving. It had been my hope that we could do BOTH; that is, manage the community even BETTER, AND have more internal testing. And maybe we can get back to that in the future. However, right now, I'm resource-limited and being asked to focus on our internal, formal testing.

Formal conformance test suites are neither cheap nor quick to assemble - but I guess you know that.

>>
I think all the employees on both the services/software side and the products side want to keep the community. Some of the managers in our respective new organizations don't see the value (which is disappointing), but we're basically planning to manage our managers. We're a willfull team. I don't represent the developers, but none of THEM have said to me that they plan to communicate less on the forums. I consider this thread to be about the relatively narrow-scope problem of Bugzilla.

You need to educate your "management" about the fact that no matter how much money they spend on formal QA suites or Support staff, at the end of the day
neither can compete with the inherent scalability of the community. There is a clearly visible viral element at play here. You can see people who post one day as a newbie posting the answer to someones problem the next day - the transition is almost seamless! Very few companies achieve this.

The community provides free support for many things and free testing - especially of edge cases - for many things. This is priceless. If Logitech want to be Sony they'd need to multiply their support and testing budget by at least 1,000! (probably a lot more) - and the cost/benefit wouldn't materialise.
If they don't realise this they are lost...

What the forums need is a bit more moderation to weed out the ranting and redirect them to Support - let the community handle (for free) the low-hanging fruit which is the largest part of the Support bell curve. It's a win-win - the community feels wanted and the customers get the answers they need at no cost to Logitech.

As for bug filing - let anyone file one, but weed out early the ones that you don't want to consume dev+QA bandwidth and mark them as "will not be fixed because...".
Also, split enhancements totally from bugs, and let the community vote or not for enhancements (not bugs!).

Sorry, rambling now...

[MrSinatra]

Some of the managers in our respective new organizations don't see the value (which is disappointing)

i hope i speak for everyone when i say i truly appreciate your candor, but that SCARES the hell out of me. when a business doesn't see the value in the customers, its doomed.

to address your concerns re: bugzilla, i have to say i am utterly confused and shell shocked by your posts here. its probably in part due to the fact that i am not a software developer, so please forgive my ignorance.

however, in the past few months i have seen lots of encouragement from logitech employees to VOTE on bugzilla for instance. i mean, when we asked does it matter, they said it does.

furthermore, i have submitted a lot of good bugs over the years, as everyone in this thread has, and some of them were in fact fixed, while others were documented as now known issues. i can only imagine this is to logitechs HUGE benefit, is it not? i wouldn't call myself "qualified" in an engineering sense, but i'm a fairly observent user.

i don't know whats technically possible with bugzilla, but it would make sense to have every new bug submitted reviewed at the end of the day by a designated logitech employee. at that time they could then decide if its a support issue, an enhancement request, or an actual bug where something is not working as intended.

let me put it another way, b/c i think this gets at what you are talking about: imo, it would be a big mistake to litmus test who can enter a bug into bugzilla. anyone should be able to. whats important is what happens AFTER that. someone at logitech needs to review the bugs at the start or end of each day, and then decide how to file them, (invalid/support, enh, bug) and then decide how urgent the bug is and otherwise further classify it. i don't see any good way to get around that from happening.

i think after that, once every two months, the devs should review ALL open bugs and post an update to the bug as to its status. this would be agreat way for devs to not forget about long standing issues. it would also give incentive to close bugs that should be closed, one way or the other. i can thinkof a few off the top of my head that i'm fairly sure are resolved and over with, yet remain open for some reason.

again, i don't see any way around this. trying to unburden the devs from bugs is like trying to teach a fish how to stay dry. how can the software improve if bugs are ignored?

i hope this input is useful to you.

[Phil Leigh]

trying to unburden the devs from bugs is like trying to teach a fish how to stay dry. how can the software improve if bugs are ignored?

The 3,000+ devs I work with would like to know if anyone manages to find an answer to this one... apparently it would mean they could spend more time drinking and less time coding...

[MrSinatra]

actually i felt very redundant with my post following yours b/c mine was so similar! but i didn't plagerize, i simply was writing it while you posted yours. i'm still confused though, i don't really understand what Chris is asking or trying to accomplish, all i "get" is that bugzilla could be drastically changed for the worse.

[kdf]

erland wrote:
>
> The main reason for having this "filter function" is to make sure the
> developers are focused on fixing bugs that are important and needs to be
> fixed in this release. Without the filtering, the developers will focus
> on what's fun, interesting, easy and not necessary what's most
> important.
>
I'm hesitant to be quite as cynical but otherwise agree. Filtering or
'triage' is critical to making it manageable. Without it, I wouldn't
suggest that devs will ONLY do what's fun, but they sure can't be
expected to waste the added time trying to find something versus
tackling what they see only for themselves on their own setup.

This is not to toot my own horn, but simply to put some perspective on
things. Before Chris and his team came along, my own mild obsession
with organisation had me rather heavily involved with bugzilla. I found
myself spending the equivalent of a full-time job simply reading every
new report each day, flagging ones that are clearly enhancements,
removing dupes (searches got more and more time consuming as I could no
longer remember the more than 700 active reports and all the various
wording). While this didn't use up all of that time, testing the bugs
certainly filled up the rest. It was not always fruitful.

Beyond that, I would still try to create patches where I could find the
problems and try to clarify the reports. This was not always met with
cooperation (even flagging something as an enhancement was sometimes
seen as an insult, resulting in not-so-cooperative emails to my personal
inbox). I was most relieved when employees came along who were
dedicated to the task. Not that they deserve any personal attacks, but
I would always assume that those kinds of attacks are self-censored when
it comes to sending them to @slimdevices.com.

It woudl be sad to see it returned to that kind of state because there
is no resources available to it, nor would I want to see anyone having
to put in that kind of contributed time. But by the same token, not
addressing reports when users are expecting prompt responses in line
with their perception of it as a support mechanism is bad too. And, now
we're back to what I agree is a very key question: what you want it to
be? Is it a developer tool or is it a support mechanism?

-k

[ChrisOwens]

Well if that's the question, then the answer is clear: we want it to be a developer tool and NOT a support mechanism. However even defined as a "developer tool", it doesn't mean that community members should be shut out. Many of you *are* developers on the products.

Although I feel pressure to spend more time on other aspects of QA, I don't feel ANY pressure to 'shut out' the community, and it's definitely NOT my goal.

There is no good reason, IMO, for these changes to 'scare the hell' out of anyone. It's a reorganization that unfortunately has an effect on a customer-facing system. We just need to handle the changes gracefully.

I think for now I'll probably just go ahead and enable bug confirmation, perhaps early next week. If it's good enough for the Mozilla team, it's probably good enough for us. As we go on, I'll keep in touch here about Bugzilla and make sure I keep an eye out for problems with the new workflow reported here in the forums.

Thanks as always for your thoughts and contributions.

[MrSinatra]

sorry if i overstated that, i guess i just misunderstood what you meant? please understand that i was from the start, and still am, a big supporter of logitech's acquisition of slim, and i think it'll be overall much more good than bad.

i just get a little bit worried when proposals to privatize bugzilla get floated. copying another system like mozilla or phpbb or something like that is prob a good idea.

[bluegaspode]

Chris,

don't you think that you could achieve a lot in just documenting (on the wiki) how you want bugzilla to be used (and then enforcing it).
Just create some simple rules and you will increase quality of bugzilla entries while decreasing unwanted noise and while keeping it open to everyone.

I take from your words:

• it shouldn't be used as a support tool, but proper bug reporting
  1) Create a template on what you expect at least from a bug report.
  - Squeezebox-Server or MySB.com involved
  - Version Number of Firmware / SB-Server
  - Is the bug reproducable
  - Are logs with error-message available ?
  - Describe steps to reproduce
  
  2) Document it in the wiki.
  
  3) Create a template answer for support requests, kindly pointing to the wiki article (where the process is defined and the differences between a support-ticket and bug-tracking database are documented for everyone to understand) and kindly ask to create a support ticket. Resolve this bugzilla-entry instantly as 'invalid'.
  
  4) Create a template answer for bug reports lacking important information, kindly asking to provide the needed information, otherwise this bug report cannot be handled. Explain that you will resolve the bug report as 'Won't fix' until the conditions are met. Kindly remind that logitech support will help to analyze problems and help to create a necessary report.
  Resolve this bugzilla-entry instantly as 'Won't fix'.
  
  5) Drastically reduce Product and Component definition. Do you really need it that finegrained and want to bother yourself with correcting it all the time ?
  Wouldn't it be enough to have 5 products: 'Touch/Controller/Radio' (a.k.a. SqueezOS/SqueezPlay problems), 'Boom/Classic/SB 1 +2', 'local SB-Server', 'MySqueezebox.com' and 'Other' ?
  
  6) remove the instant notifications of developers for certain components. I guess this just distracts them unneeded ? QA will set a priority to bug and might decide to have it fixed in the current or next development stream.
  Devs will get notifications of that soon enough.
  
• Should bugzilla be used for tracking enhancements request ?
  If not: create a text template explaining how enh.req are handled and close the bug instantly as won't fix.
  If so: document what the prerequisites for a 'proper' enhancement request are: just some wishes ? Or should there be a discussion started in the forum first and only a summary of the discussion and a link to the forum should be created as a bugzilla entry ?
  Document what happens with enh. request (i.e. there will be looked at by marketing or a product owner when the feature set for the next release is set). Encourage voting for the request.
  
• Think of anything else, that bugzilla shouldn't be used for !
  Document it, Explain It ... on the wiki.
  Create a default answer if such entries start.

I do like the idea of bugzilla staying open for everyone.
I don't like the idea of thinking that leaving bugs in an unconfirmed state will help anyone.

You are the housekeeper and you set the rules. If those rules are known in advance, are sensible in that everyone sees that they try to 'just' enforce some quality to the entries, noone can complain.
Please keep a fast confirmation of bugs and/or enh. request but reduce your workload also by strict rejection of entries that don't match your criteria.

Take a day or two to define the process - this is very well invested time.
I guess most people currently using bugzilla will value your guidance very much.

[kdf]

bugzilla has it's own documentation regarding severity and how and when to file a report.
most forums have a sticky about filing a bug report.
bugzilla main page also explains the basic 3 steps.

A good number of reports are filed having ignored all of the above: some end up ok anyway, many do not.

Wiki is even more distant from the above information. do you see a way of making the link to wiki instructions more clear than what is there already? Given that what is there is very basic, do you think a detailed wiki article would encourage more users to take the time?

I haven't personally looked up a great detail of info on how the confirmation mechanism works. I expect it won't appear much different that what we have already, but I'm hoping it may mean that search filters might have more control. I look forward to seeing how it plays out.

Thanks, Chris for bringing it to the community. It honestly does seem to be a rarer thing lately, so it is encouraging to see this approach still being taken even in the face of conflicting pressures.

cheers,
kdf

[ChrisOwens]

KDF, I hope you don't feel like I'm ignoring you. You and I have spoken in person on this subject, and I feel like we are much in agreement.

Bluegaspode, it's an excellent point that we need to clearly document what information should be in a user-filed but, and how the workflow works. In addition, I can have some information on 'How you can help' that describes looking for unconfirmed bugs, commenting on them if you have additional info, directing the original poster what else he or she needs to add, if they are missing something on the list, and voting for them (or marking them confirmed) if you can reproduce.