Suggestion for Bug Tracker/Roadmap


Recommended Posts

I have been a longtime user of Mediabrowser, since it was called VideoBrowser actually. And up until a year ago I was very involved with the community, proud to say a few features/fixes have been in a small part because of me.

 

One of my favorite parts of the community was the Community Tracker. It gives a centralized place, much like a forum, to give ideas, discussions, ideas on implementation, submit bugs, ect.

 

A Community Tracker would benefit the Add-on and Plug-in authors here by giving them somewhere to easily track their own requests, and if Tom wishes to expand the Dev team past himself, a good way for the devs to "claim" a fix, say, if there is a bug in Unraid menu, Dev A could claim it and be responsible for the fix, and Dev B would know they don't need to look at it as it will be taken care of.

 

No point in me blabbering about how good the CT is, check it out for yourselves(I suspect some already have as I believe there are a few MediaBrowser users on this forum).

 

http://community.mediabrowser.tv/

 

And the community tracker website itself (for, hopefully, Tom) http://community-tracker.com/

 

The CT is currently in an open-beta, and I'm sure Sam(the author) would be willing to let LimeTech in on the beta as MediaBrowser is his project as well and use to be a one man operation as well, there's sure to be a kinship there somewhere!

Link to comment

yes a bug tracker would be a nice thing - I found so many ideas and some bugs, but it's hard to follow and you never know if Tom will ever read it. There's a lot of stuff spread on forum. I think there might be also people helping maintaining the system, removing duplicates etc.

 

It would be also nice to let the community vote about stuff on any feature/bug list. E.g. a driver rework for faster writes :-)

Link to comment

This topic and the roadmap posting of recent provoked a thought. 

 

What is the true roadmap or SOPD for Limetech?  What's the plan?  When a company follows a pattern for period of time then changes drastically that's a sign for investors to buy or sell.

 

 

Link to comment
  • 2 months later...
  • 4 weeks later...

I'm probably not going to adopt a 'bugzilla' type issue tracker.  Instead I will be expanding the "Release Support" section.  I will change the "5.0-rc3" part to just "5.0-rc", eventually becoming just "5.0".  Also, at some point I want to get away from the "-betaN", or "-rcN" release numbering.  Instead I'm just going to adopt the same method as other projects: basically just a number that increases, and when the release has the right stability and feature set, then call it "5.0" or "5.1", etc.  This will let me produce many more releases with just a change or two.  For example, I want to generate a release with NFS fixes, but that's all I've tested, so I can't release it until all the other fiexes in -rc4 have been tested.  It's going to be better to be able to have more incremental releases.  The interactive nature of the forum along with some more "message icons" is way better than bugzilla IMHO.

Link to comment

The interactive nature is a plus, but bugs/posts can become "lost" in the forums much easier than they can in a tracker. With trackers you have better filtering(for bug/feature), streamlined comments...

 

Looking at a bug tracker, its easy to skim down the list and see if a bug is similar to what you are experiencing, whereas forums require much more searching, which, sadly, most people either only do a quick search and then make a new post, or no search at all, quickly filling forums with duplicates. In my experience, this happens much less with dedicated trackers.

 

Just my 2 cents, which depending, may be worth more or less than, :)

 

I'm sure whatever you decide will work just fine, and as the developer, you should go with whatever you are most comfortable with using

Link to comment

I'm probably not going to adopt a 'bugzilla' type issue tracker.  Instead I will be expanding the "Release Support" section.  I will change the "5.0-rc3" part to just "5.0-rc", eventually becoming just "5.0".  Also, at some point I want to get away from the "-betaN", or "-rcN" release numbering.  Instead I'm just going to adopt the same method as other projects: basically just a number that increases, and when the release has the right stability and feature set, then call it "5.0" or "5.1", etc.  This will let me produce many more releases with just a change or two.  For example, I want to generate a release with NFS fixes, but that's all I've tested, so I can't release it until all the other fiexes in -rc4 have been tested.  It's going to be better to be able to have more incremental releases.  The interactive nature of the forum along with some more "message icons" is way better than bugzilla IMHO.

 

I completely agree, the new tracking system has been fantastic and so easy to follow. We're all on the forums most of the time anyway, a seperate bug tracker is just another thing to keep track of. It also lets users discuss a particular issue in its own thread instead of flooding the announcement thread (impossible to follow).

 

The interactive nature is a plus, but bugs/posts can become "lost" in the forums much easier than they can in a tracker. With trackers you have better filtering(for bug/feature), streamlined comments...

 

Looking at a bug tracker, its easy to skim down the list and see if a bug is similar to what you are experiencing, whereas forums require much more searching, which, sadly, most people either only do a quick search and then make a new post, or no search at all, quickly filling forums with duplicates. In my experience, this happens much less with dedicated trackers.

 

...

 

While I agree that duplicate bugs/issues and feature requests can be lost in these threads I think this is where it comes down to moderator management. If the mods can keep on top of the release section and move/delete duplicate topics then the bug tracking system should work as intended. Additionally new topics (in the release section only) should require pre-approval by a mod before being created to ensure they are suitable and moved to general support (etc) if they are not related.

 

The concern I have is if Tom is planning on releasing new versions as frequently as he states it might make feature requests get buried. Perhaps the new release threads should be split up into two sections such as:

 

- Version 5 Feature Requests

- Version 5.0-RC3 Current Bugs/Issues

 

This way once all of the issues have been address/fixed/closed the thread can be locked and a new thread can be opened for "Version 5.0-RC4 Current Bugs/Issues." Any remaining issues which Tom feels will be addressed in the next version can then be moved.

Link to comment
  • 3 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.