Thelounge: Sort out issues/feature requests

[McInkay]

Alrighty, it's time to sort this out.

We have our issues section in github, which I guess can be confusing. We have 139 open, of which some are bugs, some are feature requests, some are discussions about bigger things. It has led to @astorije closing things that are legitimate feature requests, but unlikely to be fixed, or bugs that are similar but not exactly the same as another bug. I think this is the worst way to solve this, as we'll just have people opening new ones because there doesn't exist one like it. I don't like this.

Here are a couple of ways of sorting this out:

1. Github tagging

We have tags, but we don't use them 100% of the time, and we don't have any definitions of how we should use them. This would be the simplest way to solve this, tag things as feature requests, improvements to existing ones, and bugs, and we have ways to filter them down.

1. 3rd party tool

We could use a 3rd party tool, like uservoice (although not uservoice cause it costs) to track features and get upvoting etc.

I think my preferred option is just to tag things properly and be happy with having lots of issues open, and not get annoyed about that. I would accept a 3rd party solution if we want to get the number of issues down. What I do not want, and I've seen happening, is artificially closing tickets (whether they are things that aren't technically duplicates, or because we don't see someone implementing it) just to get that number down.

Thoughts?

[McInkay]

(Yes, I have marked this as a bug, because I think it is a bug)

[metsjeesus]

Id like to see tags for server side and client side issues. Maybe CSS and Styling too?

[MiniDigger]

+1 for labels.
the only downside of labels I see is that is can be confusing to new users and that each issue requires manual label assignment by a maintainer.
I guess you could also drop the issues ordered by stars link somewhere in the readme https://github.com/thelounge/lounge/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

I personally order my labels with prefixes and require every issue to have a label for every type
(see http://i.minidigger.me/2017/04/chrome_17_14-27-06.png)

[McInkay]

Id like to see tags for server side and client side issues. Maybe CSS and Styling too?

I definitely don't want to end up with loads of tags. Server/Client we could probably do (especially if we do it in the way that @MiniDigger suggests) but I'm not sure I want to broaden it out too much as we may end up with a tag per feature, which just sounds horrible. We want it to be simple to understand and easy to use or it'll never be used.

confusing to new users

This can be mitigated with some descriptions in our CONTRIBUTING.md file, and won't be a massive issue for new users initially because they won't normally be contributing straight away.

each issue requires manual label assignment by a maintainer.

Yeah, this is 1 of the few downsides I can see, but it's not a massive one as we aren't big enough to be able to have hundreds. We generally don't get that many issues, so it isn't a lot of work.

I personally order my labels with prefixes and require every issue to have a label for every type

that could work, once we've decided which way we'll do we need to decide on a naming convention if we decide labels.

[metsjeesus]

It might not work out, so its just a idea. I propose a in testing tag, what when set to a pull request, will automaticly(if possible) merge the that pull request to testing branch, what you can use to test currently active stuff what community does. Why? because there are lot of them to test one by one and together.

[McInkay]

So, that is a good idea that would be nice, @metsjeesus but it is:

1. A lot bigger than this topic
2. Probably too big for us as a small OSS project

It's something that I would do for a client in my work, and it's very useful, but it's definitely not something we should be putting our limited resources into, I feel.

[astorije]

I'm also not super into adding per-feature/feature-group labels. I don't see any value to it as their usages are mostly going to be shadowed by the search feature that does a decent job.

I was looking for that for a moment, but part of me would like a feature-request board, where people can submit and vote for their feature requests, but another part of me thinks people will come and complain that no one is working on the top requested features. This has happened in the past with voted issues on GitHub.
Feature requests are tough for our project anyway, because no one has paid time (nor the ability to do so even if money was coming our way!) to do so. And adding employees or a company sponsoring this project would probably not align with our philosophy in terms of expectations.

Only thing I can think of to clean our issue tracker reasonable would be a "Feature request" GH project. When someone comes with a feature request, we add it to the project board, close it and let people vote. Good thing is they would still show up in the search results. That way we don't have to keep open tickets for totally unrealistic features that we don't want to rule out in case someone really wants to implement it or if there is a plugin mechanism someday.
Does that sound reasonable?

Also, this issue totally reminded me of this :D
Still, thanks for opening it, it would be great to come to a useful conclusion :)

[MiniDigger]

mmh, boards without issues don't have a way to hold discussions, right? I guess that could go into the closed issue but that's not really nice...

[astorije]

Sorry, I meant that only issues would be attached to a project and can
therefore hold discussion, added to a milestone, etc.
It actually works not bad and kind of sets the expectations (or lack
thereof) when something not frankly realistic is not going to be worked on,
but still open for contributions.

Also, it certainly isn't perfect but I can't envision something better
right now :D

[McInkay]

Apparently I completely missed your replies, @astorije ... I must have had quite an email backlog.

Only thing I can think of to clean our issue tracker reasonable would be a "Feature request" GH project. When someone comes with a feature request, we add it to the project board, close it and let people vote. Good thing is they would still show up in the search results. That way we don't have to keep open tickets for totally unrealistic features that we don't want to rule out in case someone really wants to implement it or if there is a plugin mechanism someday.
Does that sound reasonable?

I don't like the idea of closing tickets while still having discussion on them, does that make sense.

However, having a board for feature requests, and a board for bugs does sound like a good plan, that might be a good first step.

But of course, how does that differ from the labels?

[astorije]

It makes sense, I understand, but to me the main difference is that cognitive overflow we're having now.

There is no way on Earth we could get to the bottom of the 172 open issues (as of today), and this number is only growing! 😢
I know personally I'm having a hard time with our issues, I cannot look at them for more than 5 minutes before getting lost and move on to something else (but maybe that's just me and my brain...).
For a new contributor and/or user, it's probably discouraging to see so many open issues 😕.

Also, we don't do a perfect job at labeling issues, which means maybe only 50 or 70% of them are correctly categorized.

I don't know, I'm not saying this is a great solution, I don't have an ideal solution.

IMO, when there is a legitimate feature request, but we all agree we will never implement it, or not in a foreseeable future, or that we would not merge a contribution, leaving it open is just noise. Aah, the magical world of open source software :D

[McInkay]

Also, we don't do a perfect job at labeling issues, which means maybe only 50 or 70% of them are correctly categorized.

I definitely agree this needs to change, but my question is how would having a board work better for this? We wouldn't be inherently better at putting things on a board than labelling them.

There is no way on Earth we could get to the bottom of the 172 open issues (as of today), and this number is only growing!

Sure, but if we have 2 boards, 1 for bugs and 1 for feature requests, then how would that be any better than just clicking on a label and just seeing those?

IMO, when there is a legitimate feature request, but we all agree we will never implement it, or not in a foreseeable future, or that we would not merge a contribution, leaving it open is just noise.

Oh, I agree. If it's something we won't ever do, or don't want, then we close it.

My issue is if we close something because we think we might not have time for it. I don't want to close feature requests that we want to implement, we just don't have time for (unless we put feature requests on some other service).

Don't get me wrong, I'm not trying to be awkward about this. I just want to know that this will be better before we switch to it. You know?

[astorije]

Totally not awkward, it's a good discussion I think. And again, you have some great points there.

First off, I'm not saying we should use GitHub Projects for feature requests, it was just an idea out there, not sure if good or bad yet, really. What we really need I think is an actual feature request board, with extra feature like voting, a real-time search when creating a new one (a bit like Stack Overflow, that tries to help reduce duplicates), and stuff like that. But having it outside of GitHub (because GitHub doesn't have one) makes for another indirection / service, and here as well there are pros and cons to that.

To answer your entire comment, I think the distinction I primarily make is the following: I do not mind having a board with feature requests that keep growing forever. As the project grows and we add new features, it's expected that people will have more ideas for existing or new features. However, bug issues should never be allowed to grow. Something marked as a bug should eventually be fixed, at least as a goal (while a feature request might be interesting to discuss but not necessarily a goal).

The fact that GitHub mixes both, and calls them "issues" is a bit of a problem IMO (I don't know, when I want to make an enhancement in the apartment, I don't tell my wife we have an issue with it :D).
It's not just semantic, it's more like it's difficult to monitor. Maybe the solution is to become really really good at tagging, and as maintainers mostly focus on this view (hey, 36 bugs, it's not that bad!)?
I guess the biggest issue I have with all that is the confusion of the state of (our) issues... but that's precisely why we are here in this thread, so I feel like I haven't helped the discussion move forward at all 😅

[astorije]

Actually, here is an idea: do you think it would be helpful to have a template for our issues?

See the Ansible one as an example.

My one requirement would be to make it as simple as possible (and we can come up with one as part of this issue). Essentially, instead of many categories like the Ansible one, we could just have "Issue type" and "Description" (or maybe extend from here). Maybe it would make labeling easier, as sometimes there are tickets I am not 100% sure if the OP was seeing this a a bug or a missing feature...

I don't know, just another idea out there, let me know what you think :)

[McInkay]

Actually, here is an idea: do you think it would be helpful to have a template for our issues?

That could definitely be useful, yeah.

What we really need I think is an actual feature request board, with extra feature like voting, a real-time search when creating a new one (a bit like Stack Overflow, that tries to help reduce duplicates), and stuff like that. But having it outside of GitHub (because GitHub doesn't have one) makes for another indirection / service, and here as well there are pros and cons to that.

Yeah, that was my thoughts, really.

I do not mind having a board with feature requests that keep growing forever. As the project grows and we add new features, it's expected that people will have more ideas for existing or new features.

Yeah, I definitely get this. But there's a problem. A board can have issues, PRs and 'notes' on it. Issues still exist, and the only way it would make sense to have a board rather than a label would be if you could have things that weren't issues or the issues were closed. I am strongly against having feature requests that we want to do closed, because semantically that makes no sense.

So that leaves us with the notes. The notes sound like they would be a great way of dealing with it, but they don't allow comments. It is literally 1 note.

So I don't see how it would actually help us.

The fact that GitHub mixes both, and calls them "issues" is a bit of a problem IMO (I don't know, when I want to make an enhancement in the apartment, I don't tell my wife we have an issue with it :D).

I agree, but we have limitations to work with here.

I suggest we do the following:

1. Keep an eye out for a good tool that exists for dealing with feature requests. With voting, etc. Bring it up when you find one.
2. Keep an eye on the github boards. I know they want to have more features on it, and if it ever becomes good, like you can have things on the board that aren't issues and have voting and comments, then that'll be good to switch to.
3. Keep going with tagging until 1 or 2 happens. We tag feature requests as "enhancement" and bugs as "bug", and we can easily filter to just bugs.
4. Make sure everything gets tagged or closed.

I have made sure there are no untagged issues now.

Does that sound alright to go with for just now, @astorije ?

[richrd]

I don't remember when reactions were added to github, but now that we have :+1: and :-1: reactions we could use them for voting on feature requests. The issue filter also allows us to sort by most reactions of a specific type.

[McInkay]

Oh boy yeah this is way old and doesn't need to still be open.

I don't remember when reactions were added to github, but now that we have +1 and -1 reactions we could use them for voting on feature requests.

That's what I've essentially been doing to watch them.

The fact that this ticket is still open...2.5 years later kinda proves it's point, but also I don't think there's any way to solve it. We are tagging things, but that doesn't help things. Voting is fine.

[richrd]

Yeah, I was just checking out some of the most commented issues, and came across this. I think it's fine to close as you did. I'll try and participate more in going through issues and tagging them. Now that vue is done there are a few features that I'd like to start working on too :)