Oh, yeah you guys did hijack this thread! So much for trying to keep a clean bug list thread.
written by: geert
We've been using a single Jira issue tracker for our projects at work also. Basic on the project a bug is classified into, it's visible to the public or not. We link public issues to internal issues if that's appropriate so that we can keep track of their relationship.Oh, yeah you guys did hijack this thread! So much for trying to keep a clean bug list thread.
"In some cases companies have both internal and external bug bases"
- that's certainly how I've seen it used before. If the bug/feature is accepted it's added to the internal one.
"So much for trying to keep a clean bug list thread"
- hehe, I'm sorry about that... I suppose the end result will be a clean bug list somewhere else :)
Hi Barnone
If we can't reproduce a bug that's been reported, we never just drop it - it goes into a 'watch' category and we keep a good eye out for it over at least a subsequent three months, and if its deemed serious, possibly a lot longer (we've had 'watch' bugs on the list for over six months on occasion). I apologise if it seems that reporting bugs seems like dropping them in a black hole - we try to make sure our release notes contain information about all important outstanding issues and bugs that are fixed in that release but you're right that's as far as we go at the moment. It really just about the resources to manage this process, which we will improve later this year.
As far as bug reporting goes, your post actually makes a good point for me - you'd quite like to report bugs somewhere else, not using the bug reporter form built into EigenD. This is something that I'm actually afraid of as that bug reporter does a lot more than just send the information that you enter - it sends us logfile information and a setup dump. This makes it hugely easier for us to reproduce the issue (and is probably the reason that you've never been contacted for more info - believe me if we do need it we do not hesitate to contact you as many on this forum will probably attest to) and has been a huge boon to us in the rate of fixes since we introduced it. Anything that encourages people to report bugs in another way will make that task a lot harder, especially if they are reporting the issue a while after they experienced it.
I think you have a very valid point about the visibility of progress though - if you've made the effort to make us aware of an issue the least we can do is enable you to track progress in it's resolution and our release notes are obviously not cutting it for you in this area. We will get to improving this situation as soon as is practicable.
John
Hi John,
Just a very minor suggestion that might improve the 'black hole' impression. What I personally don't like is when you send a bug report, you never get any dialog nor notification that it arrived, you just pressed 'send', the reported window closes and that's it. Giving some kind of notification would already greatly increase the perception of this process. I suggest two changes for this:
* pop up a small modal dialog when the bug report was actually successfully sent
* send a confirmation email to the address from which is was sent to indicate that you received it
I think that this would already be a good first step just to improve how people feel after sending their bug reports.
Take care,
Geert
One thing that would only be a one-time effort might be a WIKI entry (and perhaps something in the printed material) on bug reporting. Clearly this is an important source of info for you but many don't know how or why or when to do it.
For example, it never occurred to me that it was useful to send a bug report other than when the bug was active (ie: after restarting) and often the sw was hung when it was happening so - no report.
In fact, it is clear that the report mechanism is useful even if it simply adds config info to a written description of the event. This is *obvious* once you know it but it does not come to the front of a non-technical persons mind unless brought to their attention. (Seemingly it does not come to the front of the - my - denser, quasi-technical mind either).
To Geert's point: Any kind of acknowledgement would reinforce this behaviour. Personally, I'd value come kind of categorization that allowed me to relate what is happening to me to the release notes and I suspect that is one dimension of an interest in a bug log.
an example.
I was having setups disappear (so user 2 would go blank and it was not possible to save a new U2). It turns out that I was using a special character; not in the file name but in the *description*. However the description is used to create a 'hidden' file name. (whistle/flute in sampler 3 seems like a reasonable description eh?)
So, OK, now I do not use special characters at all... no problem. However this was discussed as a bug that would be eventually fixed.
I do not recall seeing it in release notes.
The point is that I have no way to find out without bothering people (hey, have you guys fixed this minor problem yet?) and others have no way to check out something that might happen to them.
Actually, I guess the real point is that information flow is valuable but must be made as easy as possible
@John,
In your post you said "you'd quite like to report bugs somewhere else, not using the bug reporter form built into EigenD".
I totally understand why the EigenD bug reporter is so useful to you guys. But I also understand the requirement that we sometimes want to add extra info.
The compromise is that when the bug tracker is opened up, submitting a bug via EigenD automatically creates a new entry in the bug tracker, and opens your web browser with that loaded so you can fill in any additional information, like screenshots etc.
That would solve that concern I think. Add it to the wish list ;)
@Mike & @Geert,
Positive confirmation would really help, I agree. A little "Thanks very much for your bug report!" window would really affirm that the bug report had been sent :)
Thanks,
Tene
@barnone
I've had a few of my bug submissions followed up - I suppose it depends on what the issue is and what current priorities are. I agree though that some response mechanism would be nice to avoid the black hole effect otherwise.
@john
I agree that there should be only one bug tracker and the the internal one should be made public in some way, possibly just to those of us that have expressed an interest in developing the open source eigenD. We use FogBugz at work, and it's very comprehensive, but I imagine keeping track of two or more separate systems would be impossible.
What I would like to see however is a feature request system of some sort, even if we just end up making a document or a subsection of the wiki. It could serve as a place to lay out the details of a future update (that may end up being implemented by the community). We've already discussed a variety of crazy ideas and it would be nice to accumulate them into a central wishlist.
A single bug tracker only really makes sense if either
a. there are no issues that Eigenlabs doesn't want us to see
or b. there's a way of hiding those things from us mere peons ;)
This is especially true if it's being used for internal testing too.
We've been using a single Jira issue tracker for our projects at work also. Basic on the project a bug is classified into, it's visible to the public or not. We link public issues to internal issues if that's appropriate so that we can keep track of their relationship.
Please log in to join the discussions
UK
