Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Yes, some things are getting missed

14 (46.7%)

Yes, the developers have been managing fine so far, but...

7 (23.3%)

Maybe, it would depend which one and how it was used.

5 (16.7%)

No, the development team does a great job on their own.

3 (10%)

Bugs?  You mean there are bugs in MC?

1 (3.3%)

Total Members Voted: 27

[glynor]

gpvillamil's post over here made me think about this this evening, and since I had some time I decided to put up a quick poll.  I am, of course, referring to formal bug tracking systems like Bugzilla or Mantis that are used for a wide variety of projects.

If you have specific feedback on what systems might work well for the team (based on actual usage), that could be useful as well.

I also wonder about feedback from JRiver staff on if one of us (end-users) were to create and maintain one on our own, would it be used by the development team (or would it be better to do it in-house)?

[GHammer]

I also wonder about feedback from JRiver staff on if one of us (end-users) were to create and maintain one on our own, would it be used by the development team (or would it be better to do it in-house)?

While I think it is a good idea, no way would I 'outsource' this function if I were a developer. I kinda like the Firefox 'voting' system. It lets them know what to work on by what the users think is most important.

And that is the bottom line I'd think. Keeping customers happy.

[hit_ny]

I like the idea, as it would allow ppl to post quickly what they think is a bug.

But then they will be asked to open a thread for it as well. The current system is more verbose, but things tend to be forgotten or ppl forget/give up bringing it to attention.

Thing is, who decides what is a bug and when it has been fixed ?

I'm not familiar with other bug reporting systems, so go gentle

[glynor]

I like the idea, as it would allow ppl to post quickly what they think is a bug.

But then they will be asked to open a thread for it as well. The current system is more verbose, but things tend to be forgotten or ppl forget/give up bringing it to attention.

Thing is, who decides what is a bug and when it has been fixed ?

I'm not familiar with other bug reporting systems, so go gentle

I would tend to think of it much like the way Mozilla runs their system, the forum (Mozillazine) is separate from, but works with the Bug Tracker (Bugzilla).  Interact would continue to serve exactly the same purpose as it now does.

The benefit would be that the developers would always have a running "list" of the bugs/changes that need to be made, and we would have an official, easy-to-use method for submitting them (and tracking progress on them).  I would assume that the developers (Matt, John, Jim, and the gang) would continue to determine what constitutes a bug.  The formal bug tracking systems are designed to handle this (you actually have an account on the bug tracker and some people have the power to change the status of bugs -- say to "assigned", "won't fix", "invalid", "fixed", etc).

As it is now, if you have a "pet" bug that they don't jump on right away, you have to just keep harping on it until it gets fixed (or you are told no).  It works (I voted for option 2) ... But for how long?

[nigebj]

Having been in the software development field for more than 20 years, I think there should be consideration of the difference between an OS project and a commercial project such as MC.

OS project lose nothing, other than credibility, for the discussion, examination and resolution of bugs.  Commercial products can suffer market-share loss, purchase delays and competitive issues when bugs are publicised.  That a commercial vendor is prepared to drive a forum which allows their discussion is great, to place some formal 'laundry list' of perceived (as determined by the user, not the designer) and real bugs in the public domain could damage the company reputation.  Also commercial considerations have to be given as well as technical - that most users want bug a, or feature y added may be immaterial if adding feature X would close a major licensing deal.

Perhaps a minor voting system, as Tivo has, where users can vote for certain 'approved' fixes or enhancements - to help steer priority might work - but a formal bug tracking system in the public domain would be a very bad idea IMHO.

Nige ...
(been on the wrong end of this thing before - it hurts, commercially and technically)

[glynor]

While I hadn't really thought of that before, I can certainly see your point.  Does anyone know of a solution that offers a more "middle-ground" approach?  Possibly one where the public can submit bugs, but they don't become "public" for everyone to see until one of the JRiver folks approves it as 1) real and 2) appropriate for public consumption.

I'm honestly not sure... I've only used a few bug tracking systems from a user's point of view, never configured one.  Do any of the available systems offer options like this?

[JimH]

We've used Mantis in the past and it works well, but I don't believe it works better than the way we currently do it and it adds a layer of overhead.  I find it awkward.

It's important to keep in mind that we aren't limited by our bug-tracking.  In fact, we often have more reports than we can deal with effectively.  If we had more resources, we might benefit from finer bug tracking.

What the current system does well is to bring to the top the really ugly problems.  The media keyboard problem is a good example.  We saw several conflicting points of view on it, and by discussion, we were able to follow the problem, narrow it down, and pretty well solve it.  That would be harder in a more rigid framework.

Another issue is that a minor bug that affects a few people who are exploring the edge of media management is not going to have the priority for us that it may have for these few people.

Marko did a nice job of keeping his own list, checking it, and reposting last time.

Nige got it mostly right above.  We already run a very open development process.  Making it more open would not benefit us.  In fact, the contrary may be true.

In any case, thanks for your thoughts.

[gpvillamil]

I've been involved in a couple of projects that used Mantis, the approach used was to select a small number of heavy (and friendly) users for alpha/beta testing. This way the potentially damaging list of bugs was kept out of public view.

Almost all bugs in the public forum were detected by the beta testers, and if some were missed, they were easy to add.

I am a strong proponent of separating debugging from user support. It is scary to new users!