Expand scope of issue tracker, possibly specify guidelines for how we will treat issues?

[achadwick]

(This is inspired by a comment of @odysseywestra 's in #364 )

It might be reasonable to expand the scope of what we do in the issue tracker.

Our current statement is in CONTRIBUTING.md, and it states:

The tracker is not really intended for user support, but we can sometimes help investigate your problems there. Your problem report may turn into a workaround you can use, and many reports have helped us uncover a more fundamental bug in the program code. However don't be discouraged if the issue gets closed when there's nothing we can do about it in the current phase of development.

This is really a compromise position which I settled on early as we moved over to Github for reporting, and it's one I'm happy to review. It stems from my time being limited, and the fact that I can only really make fixes in code if there's something a fixable problem to work on.

It might be a bit unfriendly. I don't want this project to be unfriendly.

However I'm fully aware that hacking is not the only project activity, and we already have a couple of project categories for what are essentially discussion threads. Like, er, this one.

If we expand the scope of the tracker to cover user support, addressing it is going to require more volunteers, so #364 is relevant.

If we expand the scope of the issue tracker, I'd like to provide some testable guidelines in the wiki for how quickly reporters can expect a response, and what kinds of response they can expect. Ballpark: users should expect some sort of response as soon as possible (ideally within a day, but that might not always be possible), and an initial triaging pass within a week. It ought to mention the labels we use in the tracker as well.

I'm very keen on the ideas that an issue shouldn't be open for longer than necessary, and that issues without something actionable should be turned into issues somebody can action as swiftly as possible, or closed down.

Any opinions or suggestions on this?

[AtsusaKaneytza]

In my opinion, it would be nicer. I do a lot of "tech support" for workarounds for people having issues with the program, but I'm not a dev.
The last time I tried to help someone out on here (Github) I remember being told on here that it wasn't really a forum for telling people workarounds.
It kinda discouraging when people want to use the program, but I can't respond to them with how to get it to work so that MyPaint's at least usable. Hope that makes sense.

[odysseywestra]

I'm all in for expanding the scope of the issue tracker as well, but like I said in #364 how will we manage all that? I would suggest add other contributors who can handle the user support and information gathering. That may help aliviate the stress of the developers of dealing with such problems and just deal with the ones marked bugs. Also using the creating a wiki page about how we deal with issues and what lables we use would help future contributors.

[odysseywestra]

Since now we have our Community Forms, maybe we could keep MyPaint issue tracker limited to just bug reports. Besides our Forms will be better at handling user support questions like it has been for the past few weeks.

We probably want to add a link to our Community Forums in our Contributor.md so people will know where they can go to get user support.

[achadwick]

Labels documented: https://github.com/mypaint/mypaint/wiki/Fixing-Bugs#classifying currently.

[achadwick]

Okay I agree that we should be porting more user-supporty requests at the forums (Discourse is just right for that sort of thing!) I've drafted a policy on answering issues in the wiki. Please can someone review/edit/propose changes here?

https://github.com/mypaint/mypaint/wiki/Answering-Issues

[achadwick]

@AtsusaKaneytza
The tracker absolutely should be a good place to share workarounds, but it just needs to stay on topic. Issue reports are shall we say... tightly focused conversations!

Making FAQ entries or referring people to the FAQ is a really good thing to do. I've tried to say something about it in the policy.

One really good reason for staying on topic is keeping threads searchable usefully. Searching is a really important part of the workflow, so titles like "multiple problems" or titles about one thing when the issue describes lots of things is bad for everyone.

Labeling is important too: labels need to be relevant to the entire issue. There's the expectation that if an issue is labelled "duplicate", you should be able to go into it and click the first issue link you find to see how the original problem is progressing. And if a code commit fixes an issue, it should be possible to write Closes #nnn in the message and have the issue resolve neatly, with links.

[odysseywestra]

@achadwick Well now that we have the new Community Forums, we can move stuff like Feature Request and Enhancements over to the community forums. Plus if we can also move all user-support issue over as well to help clean up the issue tracker. That way this issue tracker can focus more on bug reports and PRs.

[odysseywestra]

@achadwick, Anything more we need to do on this topic?

[AesaraB]

Addressed by existence of community forums