On Sat April 8 2006 14:18, Christian Lohmaier wrote: > Hi *, > > On Sat, Apr 08, 2006 at 10:04:24AM +0100, CPHennessy wrote: > > I should have stated more clearly why I think that an alternative bug > > reporting interface is interesting. > > Yes. This helps. I have a different reason for requesting the simple > assistant... (it seems) > > You want every report to be filed. I however want to raise the quality > of the issues filed. And these aims are not mutually exclusive as it basically comes down to making it easier for the bug reported to understand what information they need to give and in what form they need to give it.
> I personally do not necessarily want the number of issues filed to > > increase, but see it as Bernd put it to the point: > > [...] > > > > On Fri April 7 2006 12:51, Bernd Eilers wrote: > > > CPHennessy wrote: > > > > [...] > > > > [...] > > > > > How do you suppose to get volunteers for doing the > > > extra work of getting those "simple" issues into a shape that fits with > > > the current processing of issues by developers and qa? > > It won't help if you can get people file bugs that only say "OOo doesn't > work" or have bugs where nobody reacts when there are further questions. > These kind of issues steal most of the time spent for QA-ing an issue. Agreed. It is important that users know they must provide reasoinable information and that it should be made clear that they must also be available to provide additional information if necessary. This is not obvious with the current interface. > > Maybe an analysis of bugs reported would be interesting : are those that > > are reported by users who have never reported a bug before useful, are > > the fields all wrong ? > > Some learn fast (e.g. you tell them in one report what they can do to > improve the quality of their reports and the next one will be almost > perfect), some won't (keep writing massive amount of text, keep using > l333t-speek or use hard-to-understand-for-non-english-speakers sayings > and the like....) > An then there are those who file an issue but don't respond back. And there obviously needs to be a certain amount of patience for these categories of users, but not an infinite amount :) > But I guess you can say: People who take the burden of filing a bug are > willing to learn. Sure but this does not mean that we need to set the bar too high either. > Unfortunately, those who are not willing to "get the point" still steal > most of the time. (one bad report equals to the time spent on 5 (or > easily more) good ones). > > (from a qa-POV, not for fixing the issue itself) And this I can also understand. > > > > For those things which are optional information anyway do you really > > > thing it is that scaring to the users to have some more fields in the > > > form which are optional? > > > > I imagine going to a restaurant for the first time where there was 4 or 5 > > pages of choices for the main plate. > > I surely believe, that the step-after-step approach (of e.g. gnome > bugzilla's simple bug-assistant) greatly reduces confusion on what to > fill in in each box and what things are important. +1 (kde has a similar system, which does a match between the summary line and that of summary lines of other bug reports to see which helps to reduce duplicate bug reports) > > [...] > > Now compare that to a menu (for those new to "Brazilian food from the > > barios") with only 3 or 4 choices for the main plate. The choice is > > simpler and clearer, plus it is easier to discuss the choices with your > > 3friends around the table. > > Exactly. > But I don't meant to reduce the number of fields to fill out, but simply > not present them all at once. Ok. > And I think having a "template" style comment-box will greatly help in > making the issues better (in quality, measured in time necessary to > understand/reproduce the issue). Ok > Gnome's bugzilla asks for a short summary and the comment is then > divided into: "please descibe the problem shortly", "please enter the > steps necessary to reproduce the problem", "actual result", "expected > result", "does it happen all the time", "additional information" > > see e.g. > http://bugzilla.gnome.org/show_bug.cgi?id=337581 > for an example. So what do we need to do to move this forward ? I have limited time but am willing to work on some this if others are willing to specify what we want : 1) a number of steps; or 2) a simpler page If it's a number of steps, then how to break out the steps and what needs to go into each step ? CPH --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
