The future of bugs.slimdevices.com

[kdf]

On 2009-11-11, at 6:22 PM, ChrisOwens wrote:

>
> 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.

No worries. I know we're on the same page from earlier discussions. However, in a public forum, I won't be silent when the issue is this important

>
> Bluegaspode, it's an excellent point that we need to clearly document
> what information should be in a user-filed

essentially, put that everywhere. The wiki might be a good option as long as it is not more involved than what exists already without being more controlled. Is it possible to have some sort of checklist? I'm thinking along he lines of a flow chart type of interface. If a users goes to bugzilla, they get redirected to a basic form page. If the questions get answered in the right way, they get a new bug form. If not, they get links to support or the forum. For those that already know, they can use a more direct link to the new bug form. This may help to stem the impulse reports by those in the midst of a frustrated support issue or those with a personal issue on a design choice. This will also mean that consistent communication on the design plan will need to be in place so that reports in contrast to the design are marked as 'won't fix' instead of being fodder for forum complaints due to being ignored for years. If you expect community sorting, they are going to need to know how to address enhancements, especially those that are filed under the insistence that they are in fact bugs because not following the request is inexcusable.

-k

[bluegaspode]

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?

Um - where is information currently ?
When you start bugzilla you have a page directly giving you a bug button to start filing any bug without any instructions ?
And: wherever you put a link - it will be overseen - also noone will look to the wiki first.

So I guess you have to 'train' people individually.
But this happens very fast and easy, if you have some comments templates, which have a short kind description why a new entry is closed so fast with a link to the proper documentation.

If you did that (fast closing of bugs) without good documentation, people will be very upset because they think they are treated bad - if they see that it was just because they didn't obey some rules they will learn (or at least have a chance to learn).
Some people might still be upset - but these would be the type of persons you don't want to be in bugzilla anyway.
Other people will learn and quality of external bugzilla entries will improve.

Oh and by the way: buzilla sucks, JIRA makes much more fun ... but thats another topic

[kdf]

On 2009-11-11, at 11:18 PM, bluegaspode wrote:

>
> kdf;484404 Wrote:
>> 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?
>
> Um - where is information currently ?

see the forum stickies.
as for the bugzilla note on the main page, yes I see that is now missing with some recent upgrade.

Even still, if they can't see the forum sticky, they won't get the wiki. People don't read.
-k

[peterw]

While I think linking to guidelines is a good idea, don't underestimate users' reluctance to read. I have found that users will only read the shortest on-screen messages, and are very unlikely to click away to read additional pages.
.
The arguments about development methodology are important, but so is the notion of accomodating customers' desires and expectations. Make the bug system awkward or difficult to use and you will likely see few tickets from anyone who isn't being paid to enter the bug (i.e., Logitech staff).
.
Thanks again, Chris.

[Millwood]

Sorry to repeat myself -

mozilla has a system to deal with this. maybe you could start with that.

https://bugzilla.mozilla.org/enter_b...&format=guided

[kdf]

>
> Sorry to repeat myself -
>
> mozilla has a system to deal with this. maybe you could start with
> that.
>
> https://bugzilla.mozilla.org/enter_b...&format=guided

good spot.

perhaps a beter illustration that doesn't require a mozilla bugs
registrations:

https://bugs.slimdevices.com/enter_b...&format=guided

Would be useful on the bugs main page, for sure. I'd even go with one per
product for at least the most likely product selections at the given time.
This way beginners just pick a link and walk through the template (which
might be improved with some customisations and maybe wedge in a few checks
that could redirect to support if the answer suggests it).

Hide the "new" link, at least on the main page. More advanced users will
know where to find it after they check on their other reports.

-k

[bluegaspode]

I like it ! Just too much components

[erland]

perhaps a beter illustration that doesn't require a mozilla bugs
registrations:

https://bugs.slimdevices.com/enter_b...&format=guided

This way beginners just pick a link and walk through the template (which
might be improved with some customisations and maybe wedge in a few checks
that could redirect to support if the answer suggests it).

I like it.

I wonder if the "Components" selection really need to be there on this form, maybe that's just something for advanced users which could have a separate form similar to the one we have today ?

Some questions like these might help detect support issues:
- Do you think other people have the same problem ?
- Would you like someone to communicate directly with you to sort this out ?

If it's detected as a support issue it would be nice if one was redirected to some kind of support form that made it possible to add the missing information required for support, like serial number, contact information and similar stuff.

[ChrisOwens]

Sorry for the slow progress over the holidays. Here's the bug process document I've come up with. Please let me know if you think it should have any changes. I'll put in the 'guided' bug url, and probably the right thing to do about the components is just find some that aren't much used and remove them from the list.

BEFORE YOU FILE A BUG

Before you file a new bug, please do the following:

1. Consider whether your issue is really a support problem. If you are the only person who has noticed a terrible problem with a release that has been available a while, chances are it's something specific to you. Visit http://www.logitechsqueezebox.com/su...t-support.html for official product support. Search messages here in the forums or post a new message to see if other people have seen the same symptoms.

2. Try the latest stable nightly build of Squeezebox Server and see if the bug is still there. http://wiki.slimdevices.com/index.php/Nightly_Builds

3. Search existing bugs that are open OR resolved to see if your issue has already been noticed. If you find your bug, update it with additional information you think may be important. https://bugs.slimdevices.com/query.cgi

FILING A NEW BUG

When you file a bug, you want the bug to be fixed as quickly as possible so you can improve your enjoyment of your Squeezebox. So what makes a good bug? From our standpoint, the goal of any new bug should be to make it easy for our developers to understand the problem and make the required changes to fix the bug.

Towards that goal, a LIST OF STEPS TO REPRODUCE the bug are the biggest help. These allow any QA engineer, developer, or even manager to experience and understand the bug. You may be asked to create and attach "log files" created by the server software's internal logging function. These are a running commentary by the software as it runs, and can often provide insight into the cause of the problem.

Screen shots and videos are sometimes useful, but we prefer words. Bugs are also turned into test cases for future software versions, and it's difficult to do this with videos. Also, we periodically run complex queries of the bug database to look for trends in reported bugs. Screen shots and videos make it harder to search for bugs using Bugzilla's text search feature.

Attaching music files, playlists, or .prefs files can also be useful if a specific file seems to be causing the problem.

When you are done entering the detailed description of the bug, READ BACK OVER IT and try to verify if it really has all the information another person would need to reproduce and understand what you're reporting.

There are also a number of other data fields to fill out:

* Summary: A short summary of the bug. Should be more specific than 'No sound' but shorter than the full description.

* Product, Component, Platform/OS: Lets us know a few more details that might be important to reproducing the bug.

* URL: A link to a useful URL, most often a link to a conversation here on the forums about the bug.

* Target, Assigned to, Priority, Severity: Logitech people or special bugzilla users will set these fields later.

* Description/comments: These fields are where all the other information goes. Some information that is often useful includes the software Version or build number (for player firmware)

BUG FLOW

At any time someone might edit your bug to make it more correct. If you disagree with the change, post a comment about why!

After you create a new bug it has a life cycle peculiar to the Squeezebox team. At first, it will have a status of "unconfirmed." This means that that only a very small number of users are seeing this bug. If a bug has a certain number of votes, it will become "confirmed". Employees and some community members also have the ability to confirm bugs. If your bug doesn't have enough information to reproduce or understand, you will be asked for more details before your bug is confirmed. If you feel like your bug is particularly important, feel free to visit our forums and encourage people to vote for it or confirm it.

After a bug has been confirmed, it is moved to "new" status. Usually, it will be assigned to "Unassigned." These bugs are reviewed by Logitech QA people and given priorities, targets, and assigned to a developer. If its not immediately clear what these fields should be, this process can take up to a week or so.

After that point, the bug is the responsibility of the assignee. If a particular developer doesn't have time to work on it, it may be assigned to someone else, or it might be retargeted for a future version.

WHAT YOU CAN DO TO HELP

ANYONE:
* Confirm bugs: Search our Bugzilla system for unconfirmed bugs (https://bugs.slimdevices.com/buglist...us=UNCONFIRMED). See if you can reproduce the bug on your system! If there's not enough info, or you can't reproduce the bug, post a comment to the bug asking for more information, or describe what steps you followed to try to reproduce.

* Vote for bugs: If you can reproduce the bug or if you're already being annoyed by the bug, vote for it! Voting for bugs will automatically confirm them, and is used by our QA team and developers to prioritize bugs.

* Add additional information in comments: If have noticed any more detail about the bug, add it! If the original post was about MacOS but you also see the bug on windows, add it! If the original bug was about all music files, but you only see the bug on MP3 files, add it!

* Link forum conversations in URL: if there's a forum thread about this bug, make sure the URL of the thread is in the URL field!

POWER USERS:
* Check if critical information is there: If you are familiar with our products, you can easily tell if a bug has enough information to reproduce. Ask for any missing information we need!

* Attach sample files which display the bug: If you can isolate a file which can help reproduce the bug, attach it!

COMMUNITY DEVELOPERS:
* Fix things! If you see a bug with a lot of votes, or that you are interested in that is not yet assigned to a developer (many of these will be targeted for "Future"), feel free to post to the bug noting you're working on a patch. Even if the bug is assigned to a developer, post a question about whether you could take over the bug. Participate in our developer forum at http://forums.slimdevices.com/forumdisplay.php?f=5. Attach patches for review and inclusion in the software!

WHAT IF SOMETHING IN BUGZILLA IS BROKEN/IGNORED/WRONG?

If you see a bug that isn't being treated properly, or anything else wrong with the bugzilla system, our bug flow, or software engineering practices, you can:
* Post to the forums http://forums.slimdevices.com to see if other users know something about it!
* Send me email at chris_owens@logitech.com. Note that if you need technical support on one of our products, I'm not very good at helping people with common problems, and might totally ignore you. Our tech support team is much better at that kind of thing. You can contact them at http://www.logitechsqueezebox.com/su...t-support.html

Thanks for helping improve our software!

[Mnyb]

How do you list ALL unconfirmed bugs ?

The link you posted "return zarro bugs"

https://bugs.slimdevices.com/buglist...us=UNCONFIRMED