Forum module for issues/tickets? (Suggestion)


#1

I have a suggestion for a forum module, bug/issue ticket system…

When a user creates a new topic about his issue in one of the forum categories, he could mark this as a possible (JUCE) bug/issue and the topic results in a “Pending ticket” after he has selected a category to put this issue in.

If two or more users click on a “Confirm issue” button in the original post, the pending ticket becomes a valid ticket and ends up in a database of tickets.
These tickets can be resolved by either the JUCE staff or by N forum users confirming issue is resolved.

On the other hand, if the pending ticket doesn’t get any confirmations by other users within e.g. 3 weeks, the original poster gets a e-mail warning him that the pending ticket will expire unless he “re-new” it.

When a person wish to create a new bug ticket he could first look through the pending/confirmed tickets to see if one of them matches his issue and then simply confirm that ticket instead of making a new one.

This already exists (to some degree) at BitBucket etc, but I don’t think I’ve ever seen it integrated in a forum environment. This has the benefit that they already are registered users when they post their issues and don’t have to create a new account somewhere…

again, this is just a suggestion :slight_smile:


IPython's approach to Community support
#2

Those words could come from my mouth. I’d love to set-up a proper bugtracker/issue/ticket system for JUCE!

The problem is that this forum has developed into a very popular environment for doing that same thing. So we can’t just ditch it and replace it with some bugtracker system, I guess that many people here would hate that.

So we’d need to integrate the two approaches somehow. And here’s the problem: I have no idea how to do that. Any suggestions are welcome!


#3

Are you sure about that? Maybe an official topic could be started polling for opinions!
I think most of us would welcome that idea, even github alread integrates something like that.


#4

No, I’m not sure, as I said that was just a guess.

An opinion poll is a great idea!


#5

I think having both would be the best.

The forum is a great way to check out, if it is an individual problem, or if there is a problem with juce ore anything not self-inflicted. Also the comunity can add more insight from different view angles. And it spreads the load on a bigger base leaving the juce team more time to improve juce…
But having an issue tracker is great for the users to know, if a topic is already adressed and if we can expect something to change/improve soon. This is the thing I am missing most…

Perfect would be if there would be a workflow which migrates a conversation in the forum about a problem into an issue in a tracker, either by integrating issues into the forum, if possible, or manually when creating the issue by setting links in the issue as "additional information"
Having every problem anybody has into an issue in a tracker would bloat the tracker and eventually paralyze the team imho…


#6

I agree on what the other users are saying, timur. I’m still new, but I feel like a forum can be more for “how do I do this or what does this mean” vs “hey, I have a bug and I’d like to keep track of it between releases”

For instance, the one that I filed last night with the switching focus issue, I searched through a ton of forum posts before I felt comfortable posting it to make sure it wasn’t a duplicate post. Have an issue tracker would be able to filter stuff like that out and keep the users up to date on what’s been fixed, whereas with a forum it’s kind of like throwing a paper airplane into the wind. Which is not to say you guys are doing a bad job or anything at all, this was actually one of the fastest response times I’ve ever had.

I guess as a dev, bug trackers just feel more natural.


#7

Maybe the most natural way would be to have both a forum and a bugtracker.

The natural place to ask for advice would be the forum, while
the natural place to submit a bug would be the bugtracker.

When one submission in either the forum or the bugtracker has been done “in the wrong place” (i.e. a topic in the forum to report a bug, or a submission in the bugtracker to ask for advice), it could be “moved over” to the correct place instead (or the user could be briefly instructed to do so before closing the bug/topic)

I think us developers will quickly learn where to submit things after a short learning time.


#8

Many times, I have solved my JUCE-issues by searching the forum’s themes.
But also, many times, I have spent many hours for searching up for a particular answer on my issues.

Just a lite approach to the problem as it put by timur , can be the following :

  • When someone wants to put a new theme, the system can ask for some info to classify the issue, through a prepared-list, from its database.
    -The system can then recommend to the user, the most relevant issues from the system’s database.
  • Of course, the system of “recommend relevant issues to the problem”, can be used intepentently.

just a proposal. . . .

George


#9

I believe this is already in place to some extent: when you type the title for a new topic you want to create in the forum, it shows you a list of already existing topics related to the keywords you have typed (as if to suggest: “heyy, check out these before writing a new one!”)


#10

Some options you can do now.

  1. Enable the “tagging” plugin, create a few staff tags for “has repro”, “no repro” “scheduled” and what not, staff tags can only be applied by staff so there is no risk that the community will tag stuff incorrectly. Additionally you can style the staff tags with special eye catching CSS.

  2. Introduce a convention that a “like” on a “bug report” == it also happens to me… then you can sort the topic list for “open” bugs by number of likes on OP. Eg: https://meta.discourse.org/c/bug?order=op_likes&status=open

  3. Create a “tag” at least for “bugs” or maybe a discrete category for them.


#11

I feel some kind of issue tracking system would be good, as sometimes I don’t know if issues get lost in the forum - its not clear if they have been read by the JUCE team, being considered, not a priority, would be fixed quicker with a pull request etc.


#12

This is all great feedback, thanks to everyone so far!
We will discuss this internally in the JUCE team.

(Personally I also feel that an issue tracking system may be better, easier, clearer, and more efficient for everyone.)


#13

What adamski said exactly. Since the JUCE team doesn’t take pull requests, as far as I know I have no other option than to post on the forums and hope I get a reply or feedback from a JUCE dev. I occasionally have to bump my own posts every few days if the issue is still relevant to me and nobody’s replied yet, which I feel is probably annoying to other users. I feel that as JUCE becomes less niche and gets more mainstream popularity (which I think is already happening) this will just turn into chaos on the forums if there’s no place else to post issues.


#14

Actually I think they are starting to take pull requests now - see Github Pull Requests

Personally I think Github’s Issues are a great way to keep track of and discuss issues. But that may overlap with the forum.


#15

Yes, forums cannot be used as bug tracking, probably they can be used as bug reporting, but then bugs or improvements need to be tracked in a different way.

I used the github issues reporting in the past and i have to say it’s quite well integrated and easy to browse, categorize. Much more easy to find if an open bug is there as you can filter per bug types, and being able to search closed bug to check if something has been already fixed is somewhat i miss in the forum.


#16

Yes, the forum is definitely not enough for bug tracking : we need a way to be able to see the opened bugs quickly and easily.
Before 4.2 I was monitoring the forum to see the progress on 2 bugs. Since 4.2, not only those bugs are still there, but I’ve also seen so many posts reporting issues that I just don’t feel like using 4.2.
But I’m not sure if those reported issues were confirmed or not, or fixed. It’s not practical to have to read through 10 threads and all the git commits to be able to know what is the current state.


#17

if you are targeting plugins… i suggest you don’t do it, 4.2 made me appearing additional grey hairs (and i already have many).


#18

Don’t worry, we are working on ironing out all those issues as soon as possible!


#19

Following various threads here, its becoming clearer how badly a proper issue tracking system is needed. As an example, posting in random threads about fixes e.g. Plugin binary size (4.2 = bloat) is a very inefficient way to communicate with users. I vote for Github issues. Show the commit, get people to test, close the issue when confirmed that its working.