We hope you enjoy your visit.

You're currently viewing our forum as a guest. This means you are limited to certain areas of the board and there are some features you can't use. If you join our community, you'll be able to access member-only sections, and use many member-only features such as customizing your profile, sending personal messages, and voting in polls. Registration is simple, fast, and completely free.


Join our community!


If you're already a member please log in to your account to access all of our features:

Username:   Password:
Add Reply
Idea: Bug Tracker
Topic Started: Nov 15 2016, 03:16 AM (453 Views)
Cory
Member Avatar
Member
[ *  *  *  *  *  *  *  *  * ]
I think a bug tracker should be added in list/table format to a pinned topic somewhere on this forum, the documentation wiki, or an official page.

Pros of a bug tracker:

  • A (hopeful) decrease in topics and tickets regarding the same bug.
  • Workarounds
  • Informative
  • Status Updates/Highest Priority Fixes
The question is: Why wouldn't you have this information publicly visible?
Offline Profile Quote Post Goto Top
 
Stephen
Member Avatar
Twilight is upon me, and soon night must fall.

In theory, I'm not opposed to it. In practice, things can get messy. If someone has solutions to avoid the mess, I'm all for it.

To give an example, when ZetaBoards was in the staff testing phases, we did have a bug tracker. And we used it. But there's a few issues here:

1) Going from a server down or other error support topic- many of our users chime in with "me too" The problem there is that other bugs that are less noticeable or affect a smaller group would get ignored over say search being down and 12 users saying they are also affected.
2) Brandon probably won't use it. I say that because he has his own bug tracker topic within the staff forums and that's what he responds to. The reasons are that these reports tend to include specific details, ways to reproduce the bug if needed and locations where the bug is occurring. It contains the information he needs to resolve the problem. Some of this information is not useful to users who are looking for information specific to how it affects them and, as you mention, any potential workarounds.
3) For a similar reason as number 2, it's difficult to maintain. It's one thing to have a topic in the staff room where Brandon can quite literally fix a dozen bugs in an hour and just write "fixed". It's another to have to keep updating it. If for instance, a bug is not fixed or a new bug arises, we go off of that to let him know so he can resolve it quicker. It can become messy to do this in a public topic.
4) There are generally a lot more bugs than you know about because Brandon fixes some of them very quickly. Having to document and then resolve them or later unresolve simply becomes time consuming for those involved. In general, we avoid contacting Brandon directly about bugs because he generally knows about them before we do and he may already be fixing them. It's when a bug is a true priority that we might make sure it has his full attention (and usually those do but he is trying to track down the exact cause which can be time consuming). This is pretty much what happened with the move. We had a topic for staff to draw his attention to bugs that were related to it, he would let us know when it was resolved.
5) Support staff are generally busy with tickets, I keep trying to keep abuse reports manageable, Helena keeps theme of the month going and other staff have their own various projects. The problem is that we're not going to be able to keep such a topic up to date. Some bugs are blink and you miss them. The nasty ones tend to have topics in support until they are resolved. So what we're really talking about is the middle of the range bugs: things that are not essential but annoyances that are not working as expected. Those can sometimes be fixed without Brandon letting us know so our topic might say there is still a bug when it may have been fixed days earlier. Vice versa there may be something we mark as resolved and then something else crops up and it is no longer fixed.
6) The format for presenting this information is another hurdle. If this were say a bugzilla style thing, it's a matter of clicks to move a bug from resolved to unresolved and vice versa. A topic or a wiki doc is mostly keeping on top of it and editing it. I don't like it only because I can't guarantee we'll be able to keep on top of it. And when you make a topic like that, you need to be committed towards keeping it up to date and accurate. I can't guarantee that would be the case.
7) We do have to acknowledge that not all users look at pinned topics. So I am not so sure it will cut down on the number of topics. Consider every time a server goes down we have multiple topics for that despite our numerous requests not to make topics.
8) Finally, to answer your last question, while 90% of the bugs we have are minor or quickly resolved, there are some bugs that can be security concerns and in those instances spreading the word may not be the best course of action. Consider for instance if there were a bug that let you delete a topic on any board even if you weren't a staff member. Some of our less honorable users might take it upon his or herself to duplicate the error and use it to harm other boards. That's an extreme example but we have had rare instances of bugs on a level like that and generally the user tells us, we resolve it quickly and make sure it can't happen again.

The idea is good. The problem lies in the execution. From our side, there is no way to keep it consistently up to date because we don't always know the current status of a bug until we receive a development update. Those updates may be as frequently as every few hours to as long as a month depending on the scope of the bug in question and the other items that are occupying developer time. The bottom line then is that we can't provide up to date information at all times. And if we can't do that, then we've essentially defeated the purpose. In general the current course of action is that we address topics individually and share what information we have at that point. Sometimes it isn't much as it is the first we're hearing about. Other times, we have information it is being worked on but have no eta on a resolution.

For zIFBoards, because we stopped development, the bugs we have listed (search, PMs) aren't going to change so we have them in the welcome topic I believe. But ZetaBoards remains in active development and is therefore constantly changing. Hopefully I've explained myself clearly enough. The idea is good, we just lack a way to execute it well at this juncture.
Offline Profile Quote Post Goto Top
 
1 user reading this topic (1 Guest and 0 Anonymous)
« Previous Topic · Service Discussion and Feedback · Next Topic »
Add Reply