Is using Discourse to track bugs a WTF?
-
I could definitely see some kind of Discourse/bug tracker integration as a non-WTF way to discuss issues and track their status.
Someone already beat you to it. This is actively used on New Relic's forums.
https://meta.discourse.org/t/create-zendesk-tickets-from-discourse-posts/15342
-
You just keep changing the title of the thread/topic/whatever; prepend it with <state>:
Yeah, and now you're living in the same space as the morons whose database schemas are varchars with id and value columns stuffed with XML.
I'm interested in hearing how they know how many things are open. Maybe there are admin tools to query topics. Or maybe they just look directly at the DB?
I can't imagine trying to use such a management anti-pattern as this for something that I was trying to make profitable (they are, aren't they?).
-
I'm interested in hearing how they know how many things are open. Maybe there are admin tools to query topics. Or maybe they just look directly at the DB?
bug
A bug report means <strong>something is broken, preventing normal/typical use of Discourse</strong>. Do be sure to search prior to submitting bugs. <a href="https://meta.discourse.org/t/how-to-write-a-good-bug-report/183671/">Include repro steps</a>, and only describe one bug per topic please.
-
https://meta.discourse.org/category/bug?status=open
Well, that's only on one of the 12 sites. How many topics were there? It doesn't give a count, and it's really hard to count that much, especially when the infinite scrolling kicks in.
Now, how many of those are being worked? What are the priorities? etc, etc etc
Filed Under: chaos
-
We make IT-xxxxxx (not porn!) software
You read it for the articles. I understand.The advantage that you have is that you have the sort of project where you can fly by the seat of your pants and get by. And that's great. I have some personal projects kind of like that. I mean, no one is relying on you providing critical capability for their organization via Discourse or StackExchange like they would with ERP or accounting or whatever software. So I can see why you value the benefits less.
The major advantage is enumerated hereOur advice at Y Combinator is always to make a really good product and go out and get users manually. The two work hand-in-hand: you need to talk individually to early adopters to make a really good product. So focusing on the narrow and deep end of the sales/marketing continuum is not just the most effective way to get users. Your startup will die if you don’t.
Bug trackers are not about talking to users. They're more .. sadistic .. than that.
-
Now, how many of those are being worked? What are the priorities? etc, etc etc
Sort by likes, click the like column to do that.It's indeed a lightweight system, but that is exactly how I like my systems.
-
I think I found @codinghorror's portrait...
-
<sarcasm> And here I thought everyone tracked their bugs in a spreadsheet shared on a network drive </sarcasm>
Glad to be rid of that system...
-
<sarcasm> And here I thought everyone tracked their bugs in a spreadsheet shared on a network drive </sarcasm>
Glad to be rid of that system...
Or by how many emails you get from salespeoples swearing that they lost $xxm purely because we we were missing this feature or didn't fix that bug.
-
I'm interested in hearing how they know how many things are open. Maybe there are admin tools to query topics. Or maybe they just look directly at the DB?
I can't imagine trying to use such a management anti-pattern as this for something that I was trying to make profitable (they are, aren't they?).
Infinni-XSLT. It's very robust.
-
The major advantage is enumerated here
I can't see how anything there contradicts anything I've been saying. I could see you linking the same thing if we were mocking you for have an VCS that consisted of discourse1.zip, discourse_01-20-2013.zip, discourse-v0.6.zip, etc. and suggesting that you use a tool made for this sort of thing.
Bug trackers are not about talking to users. They're more .. sadistic .. than that.
Some certainly are.
Is this topic paginated? It's like you missed where multiple people said something along the lines of using discourse for the conversation part of an issue tracking tool.
-
I can't see how anything there contradicts anything I've been saying. I could see you linking the same thing if we were mocking you for have an VCS that consisted of discourse1.zip, discourse_01-20-2013.zip, discourse-v0.6.zip, etc. and suggesting that you use a tool made for this sort of thing.
You mean like discourse-v0.8.0.zip discourse_2013-06-01.zip discourse_USE_THIS_ONE.zip?
-
Bug trackers are not about talking to users. They're more .. sadistic .. than that.
So... what's the problem with using both?
You use DC to talk with users about bugs, and a triaged/confirmed bug goes into your developer team's private bugtracker.
-
It's like you missed where multiple people said something along the lines of using discourse for the conversation part of an issue tracking tool.
Hey, I missed that too, so that's why I said my piece.
-
You mean like discourse-v0.8.0.zip discourse_2013-06-01.zip discourse_USE_THIS_ONE.zip?
LET ME COUNT THE WAYS
discourse_OLD.bak.zip
discourse_OLD2.bak.zip
discourse_do_not_use.bak06082011.zip
discourse_do_not_use.bak06082011_a.zip
-
You forgot
discourse_USE_THIS_ONE-2.zip…
-
Also
discourse_USE_THIS_ONE-2-FINAL.zip
-
Hey, I missed that too, so that's why I said my piece.
Looking back at this topic, I can see that I didn't say it here. I must have said it somewhere else before this was created. I know I thought about it a lot during this thread, but I figured I'd already made that point. :-/
-
I had a folder called hacks_bkp_because_i_dont_trust_myself_using_hg
It had a much older access time than hacks/.git before I finally threw it out.
This isn't so much a reflection of the quality of git over Mercurial as a reflection of my patience for properly learning Mercurial on my own at the time.
As a bonus, I believe one of the items that was added to Hg was a folder called .bzr
History is fun.
-
Status is indicated by whether the bug topic is currently open or closed.
No!
Some topics in the meta/bug category have already been closed. It is now impossible to discuss those fixes or reopen the bugs (at least for ordinary users). Closing a bug is necessary, but not sufficient for closing the discussion.
IMHO using Discourse to discuss bugs is not a WTF, but using Discourse in this way to track them is.
-
So reply as new topic in the right gutter, then the new conversation is bidirectionally linked to the previous closed conversation.
-
Closing a bug is necessary, but not sufficient for closing the discussion.
From a general software dev process standpoint, bugs/issues should not be modified/discussed/etc after deployment to production. They can be referenced in new bugs/issues, but re-opening them makes for very challenging change management.
While I wouldn't use Discourse to track my bugs/issues... the workflow is good!
-
So reply as new topic in the right gutter, then the new conversation is bidirectionally linked to the previous closed conversation.
Huh, that link doesn't show up unless I make my browser wider, even though the gutter looks big enough to show it.
-
File a bug about it?...
-
Well god damn if that wasn't another bug ... was making the right gutter invisible based on media browser width queries. In this case it was left over bootstrap nonsense. Hooray for "span14" being a major semantic element in our CSS.
(I've fixed the issue by merging the spanX classes into the named CSS columns on the topic page, and making the width of avatar and body fixed size. So you should see reply as new topic more reliably)
-
From a general software dev process standpoint, bugs/issues should not be modified/discussed/etc after deployment to production.
I'm a Discourse user, not a Discourse developer. Whatever changes have been made, I won't notice until after deployment to this site. Only then I can determine if my bug has been properly fixed. If it hasn't, I have to create a new topic about the same topic because the old topic has already been closed. What's the point of that?
-
I am only closing bug topics here after I have the fix deployed on the site.
-
Assuming we understand your bug (e.g. we have a repro) we should be able to objectively determine whether it is fixed.
You'll know it is fixed because your bug topic was closed, which you'll get notified of since the close message is a post in the bug topic that you are tracking. (and/or we may reply to you).
-
You'll know it is fixed because your bug topic was closed
In theory. In practice, maybe you introduced a typo here, used a wrong color there, or made an off-by-one error somewhere else. Or maybe the repro wasn't clear enough and an edge case has been overlooked. IMHO minor issues like that don't justify a new topic.
Could you please wait a little longer before you close bug topics? Maybe a week after deployment?
-
Could you please wait a little longer before you close bug topics? Maybe a week after deployment?
On meta I usually leave a message and chuck an "auto close" on it, that way I don't forget to close it later on. Will try to use "auto close" here as well. (basically automatically closes topic after N hours)
-
In the system I use, we currently have 5 possible states for our bugs:
Pending - equivalent to Open
On Hold - generally used when there is some obstacle to actually implementing a fix. These get reviewed on a weekly basis to see if they can be put back in a tracking status.
Cancelled - for some reason or another, the bug has become a non-issue. Either it could not be replicated, there were multiple tickets, etc.
Completed - this indicates that the fix has been completed and verified. It just needs to be published.
Released - the fix has been completed, verified, and published.At work, tasks only have "open" and "closed" states, and we use tags for things like this this (Cancelled = notabug or wontfix, Completed = fixready, Released = task closed). Tasks are associated with diffs in Phabricator and the state (whether they've been committed and whether they're in prod yet or not) is automatically pulled from Phabricator.
