Web interface for Issue triage

[elsiehupp]

Problem

Right now the boilerplate on the OS repository (the obvious place for people to go to) reads as follows:

This repository is for the elementary OS build system and not a catch-all for the OS itself. Please do not file issues for the operating system itself or apps here, as they will be closed or need to be manually transferred.

If you are on elementary OS and trying to report an issue with something in the OS itself:

1. Open System Settigns → About → Report a Problem
2. Choose the appropriate category and component
3. Follow the prompts to report a problem

If you are not on elementary OS, please:

1. Visit https://github.com/elementary
2. Use your best effort to find the correct repository
3. Check for similar or duplicate issues to what you're trying to report
4. If none are found, file a new issue against that repository

Please remember, the more time that we have to spend triaging issues is less time we have to address the ones that are already open. :)

While I appreciate that it takes time triaging issues, the above description is honestly insufficient. I don't have any experience yet with the Feedback app itself, but just dumping users into elementary's GitHub organization page is a bit daunting, and it doesn't help with Issues that don't easily fit in any single existing repository.

Proposal

There is definitely an important purpose to a native feedback interface, namely collecting system info and logs, which, judging by the Issues on this repository it doesn't seem like the Feedback app actually does, but for broader feedback triage it would probably make sense to have a web interface that guides users to the correct place.

The GitHub interface for self-triaging Issues looks like this:

Yes, I'm aware that the underlying system for this is quite limited, but you can still essentially bounce people between different repositories, and this functionality could be used to create a multi-step workflow.

• First, there could be a global "inbox" (or "start here") Issue tracker that presents the visitor with a series of categories, each of which would be a link to another Issue tracker.
• Each of these Issue trackers could then present the visitor with a list of links to the Issue tracker for each of the repositories in that category.
• Then each repository Issue tracker could present the visitor with a series of templates and related links, as well as a link back to the category issue tracker for the purpose of "none of the above".
• The category Issue trackers could then be used for triaging Issues that don't quite fit in any existing repository (and the category repositories could consist of just the triage Issue tracker and a README with a list of the repositories in that category).
• The global "inbox" Issue repository and the category repositories could then be pinned repositories on the elementary GitHub organization's home page.

I'm not sure if you can use Issue templates to complete disable the ability to add Issues to the underlying Issue tracker, but if so the "start here" Issue tracker could be set up this way (with prominent links to it in the "start here" README and at the top of the elementary support page).

Alternately you could try and do something like this on the main elementary website, but that may end up being more difficult to maintain, even if it would be a more flexible approach.

Prior Art (Optional)

The link inkscape.org/report redirects to a triage issue tracker. While Inkscape uses a single massive inbox, you may wish to use a more sophisticated system to help visitors get to the right place for a given type of feedback.

Also the automated phone systems that are the bane of anyone trying to reach a real human being do exactly this. ("Please listen to all of the options, as our menu has changed," the voice says as it lies through its teeth, lol.)

[danirabbit]

Right, so it sounds like what you're describing is exactly what the Feedback app already does currently :)

If not can you explain specifically what the difference between what you're suggesting and the difference between what the feedback app does is?

[elsiehupp]

There are several key differences between this and the Feedback app (which, again, I haven't used):

1. It works on platforms other than elementary OS. I have elementary OS on my HTPC, but I use macOS on my notebook (for now). As I said in the introduction to my issue, the second half of the quoted text is obviously deeply insufficient when compared to the first.
2. In addition to suggesting a multi-step workflow, I also suggested using the structure as a way to provide more loosely defined category-based issue trackers in addition to the per-repository ones. For example, there is no obvious place to suggest new core apps, new Switchboard plugs, or new Wingpanel indicators.
3. Empty category repositories with consolidated Discussions sections could also make said Discussions sections a bit less... dead. I know you want people to use those more, right? (Looser discussions of the sort in the previous list item could go here instead of in the Issue trackers, too.)
4. And, again, the README files of otherwise empty category repositories could help provide a more hierarchical table of contents for the GitHub organization, which otherwise features a single flat list with a limited number of pinned repositories.

The fact that the Feedback app already has the triage process is all the more reason not to build a web interface from scratch and instead just build it into the elementary GitHub organization using self-triage templates. This way the two interfaces would be easier to keep in sync with each other.

[danirabbit]

Transferring to website since it seems you’re explicitly not interested in using the feedback app

[elsiehupp]

I mean, I'm sure I will want to use the Feedback app at some point, but this particular, um, feedback is probably better here. Thanks!