Couldn't agree more, Peter. As a rule, laypeople reporting bugs have excellent motivation - they ran into a bug and the best possible thing that could happen to them is for the bug to be fixed right there, on the spot. That's unlikely, but finding a workaround or at least some 'closure', such as some backstory and a feeling its being worked on, is the second best thing.
That motivation is going to waste right now. On Jul 19, 1:05 am, Peter Becker <[email protected]> wrote: > I think one of the core features on stackoverflow.com is that they take > your second point serious. When you ask a question there, it will list a > selection of possible duplicates once you entered the subject line. > > At first I thought that is too early since there is not much data to > compare. In some ways I still believe that, but I also think that it is > the right time to provide a look at existing entries since the user will > still be happy to browse. Once all the effort of writing a ticket has > been spend, hardly anyone will bother to check for duplicates since > there is nothing to gain for them. > > I seriously wonder if an old-school expert system could help. The type > with a series of multiple-choice questions, in this case drilling down > into components (as visible to the user). Of course with an escape route > on every level so you get the really lazy people to submit, too. It > might be to patronizing. > > Peter > > > > Reinier Zwitserloot wrote: > > If they WERE using jira, I can imagine that users, being flabbergasted > > about how to use jira, just mailed them. I honestly believe that a > > good, solid bug tracker that is designed with a clueless end-user in > > mind is a big improvement over any email solution, and will be used > > properly. > > > Simple things you can do: > > > 1. Offer a central place for adding more feedback. This is hard with > > email-centric solutions. (Note that the tracker should ask for an > > email address (but not verify it), so a bug investigator can contact > > this person, but all this ought to be done via the tracker, and the > > tracker can fold reply emails into a comment. This still isn't an > > email-centric system, it just offers an alternate interface). > > > 2. Automatically search for some bugs that appear to be similar, list > > them, and point a user at them. Users are somewhat desperate, usually, > > looking for a solution, so odds are they will investigate. With some > > fancy footwork in regards to a header that allows a user to delete the > > report they used made, you may even get some of your investigation > > time back. > > > 3. Be smart about forwarding the new report to more knowledgable users > > - find those similar bugs, and maybe ask 'is this a duplicate of that' > > questions to multiple people, especially if the 'similar bugs' list > > contains bugs from wildly different sections of code. > > > 4. Integrate with the tool, so that the tool can add version and other > > relevant information. See netbeans for how awesome this can get. > > > Does such a system exist? Evidently not. Maybe someone at atlassian > > reads this :P > > > In the mean time, however, I'll settle for a bug reporting system that > > mere mortals can get to grips with. > > > On Jul 18, 1:13 am, Christian Catchpole <[email protected]> > > wrote: > > >> Yeah, I wouldn't do it at work. I'm not suggesting A. And maybe > >> IntelliJs tracker did B anyway. They use JIRA I noticed. Maybe > >> people were just emailing them anyway so they put up the email form. > > >>http://www.jetbrains.com/support/support.jsp?pr=IDEA&ask=Bug%20Report > > >> On Jul 17, 10:33 pm, Reinier Zwitserloot <[email protected]> wrote: > > >>> Depends on the project, and what would you suggest fixes this? As far > >>> as I can tell, you're either suggesting: > > >>> A) Nothing, let users stew, or let them flood a mailing list or forum > >>> or some such, or > > >>> B) Let users email it to some central repository, where someone has to > >>> take action. This is just like letting users enter bugs in a bug > >>> tracker, except far more annoying, as a bug tracker can automatically > >>> do some cross-reference searching, it can move newly created issues > >>> into the inbox on a round-robin schedule, and more. > > >>> On Jul 17, 6:52 am, Christian Catchpole <[email protected]> > >>> wrote: > > >>>> I sent a bug to intellij the other day with a simple "email form". It > >>>> turns out the bug was already identified. I guess if it wasn't they > >>>> could have escalated it to a real bug. Allowing direct public access > >>>> to a bug system would probably result in lots of duplicates and low > >>>> quality reports. > > >>>> On Jul 16, 2:02 am, Mohamed Bana <[email protected]> wrote: > > >>>>> I agree with you --- most trackers are just crammed. > > >>>>> Also, as is common, telling someone to file a bug report isn't the way > >>>>> to go > >>>>> as it requires creating an account etc. Most people simply won't do > >>>>> it. I > >>>>> guess Trac could help in this regard, because it's supports creating > >>>>> issues > >>>>> from emails. > > >>>>> 2009/7/15 Reinier Zwitserloot <[email protected]> > > >>>>>> Unless the JIRA frontpage can be skinned into something without 85,000 > >>>>>> links and buttons, JIRA is fundamentally not going to be a good idea > >>>>>> if its going to be used by end-users. > > >>>>>> On Jul 15, 6:28 am, Mark Fortner <[email protected]> wrote: > > >>>>>>> JIRA supports voting and can also be configured to automatically > >>>>>>> create issues from emails. You would need to check with your provider > >>>>>>> to find out which features have been enabled. Atlassian also provides > >>>>>>> a hosted service if you don't want to handle managing the server > >>>>>>> yourself. > > >>>>>>> Hope this helps > > >>>>>>> Mark > > >>>>>>> On Tuesday, July 14, 2009, Michael Neale <[email protected]> > > >>>>>> wrote: > > >>>>>>>> Its interesting how people are never really satisfied with bug > >>>>>>>> tracking, despite there being quite a market and competition. > > >>>>>>>> I guess cause they are really trying to solve 2 overlapping problems: > >>>>>>>> bugs and issue tracking for project teams with some project > >>>>>>>> management, and on the other side is it a place for end users to log > >>>>>>>> issues/requests/bugs etc... (the latter are the ones that might be > >>>>>>>> "scared away"). > > >>>>>>>> I sort of wonder if a solution is something like JIRA for the project > >>>>>>>> side, and then for a more user driven front end something like > >>>>>>>> uservoice - where things get voted on, it aggressively de-dupes > >>>>>>>> things... > > >>>>>>>> On Jul 14, 10:35 pm, Straun <[email protected]> wrote: > > >>>>>>>>> As an open source project surely you must rate exposure to your > >>>>>>>>> community as highly desirable? > > >>>>>>>>> My only observation is that strangely Google code does not get much > >>>>>>>>> exposure via Google itself, instead projects on SF get the best > >>>>>>>>> exposure. This might be because the page ranking systems rate SF > >>>>>>>>> long > >>>>>>>>> standing might above googlecode's fresh faced approach. > > >>>>>>>>> I have yet to see if Kenai does any better. > >>>>>>>>> Good Luck. > > >>>>>>>>> On Jul 14, 12:13 pm, Reinier Zwitserloot <[email protected]> wrote: > > >>>>>>>>>> I'm looking around for online project hosting, and frankly, I'm not > >>>>>>>>>> really finding the perfect solution. > > >>>>>>>>>> NB: JIRA gets a double negative because it's utterly useless for > >>>>>>>>>> Joe > >>>>>>>>>> Schmoe who would like to file a bug. You get a massive screen > >>>>>>>>>> filled > >>>>>>>>>> with bells and whistles, which is just going to scare people away. > >>>>>>>>>> Google Code's home-grown issue tracker, but then without requiring > > >>>>>> you > > >>>>>>>>>> to have a google login, that'd be perfection. > > >>>>>>>>>> kenai: Supports git (++), wiki (+), JIRA or bugzilla as issue > > >>>>>> tracking > > >>>>>>>>>> (--). Bonus: Netbeans integration. > > >>>>>>>>>> github: Supports git (++), wiki (+), useless home-rolled issue > > >>>>>> tracker > > >>>>>>>>>> (--). Bonus: Lots of repository visuals. > > >>>>>>>>>> google code: Only supports hg (-), wiki (+), nice homegrown issue > >>>>>>>>>> tracker (+). Bonus: It's google, so stable under load. > > >>>>>>>>>> sourceforge: Vague sense of being from the 90s (-), Supports git > > >>>>>> (++), > > >>>>>>>>>> no wiki (-), not so nice homegrown issue tracker (-). > > >>>>>>>>>> None of them really convince me. Right now I'm hosting the > > >>>>>> repository > > >>>>>>>>>> and wiki on github, but hosting the downloads and the issue tracker > > >>>>>> on > > >>>>>>>>>> google code. I wonder if that's even allowed on those services. I > > >>>>>> must > > >>>>>>>>>> say I looked at sourceforget only for writing this post and they've > >>>>>>>>>> done quite a job on improving the look. It used to be that your > >>>>>>>>>> average user would get utterly overwhelmed by the vast amount of > >>>>>>>>>> options, almost all of which led to empty pages because project > > >>>>>> admins > > >>>>>>>>>> didn't use any of those niche features. > > >>>>>>>>>> Which ones am I missing (It is an open source project, but if it > > >>>>>> costs > > >>>>>>>>>> a little, that might be okay)? > > >>>>>>>>>> The perfect project hosting: > > >>>>>>>>>> - > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
