Recently Github (where MyPaint code is hosted) recently implemented issue and pull request templates. These templates help bug reporters and code contributors either give us the information we need to before we can fix the bug, or a checklist of what is require before we can accept a pull request. I think the community can help us by giving us feedback about how our template should look. One thing we don’t want to do is overwhelm our community from contributing to the MyPaint source code. Let us know your thoughts about this matter down below. It will be a great help in shaping the future of the MyPaint Community.
opened 06:40PM - 18 Feb 16 UTC
closed 09:49AM - 11 Apr 17 UTC
type.Enhancement
type.Project
Issue reporters frequently have to be asked to supply basic information about ne… w issues. we already use a `CONTRIBUTING.md` that refers people to the [bug reporting guide](https://github.com/mypaint/mypaint/wiki/Reporting-Bugs) and the [Contributing pages](https://github.com/mypaint/mypaint/wiki/Contributing) on the wiki, but this information is hidden away behind links that not many people click.
**[Github have recently added support for templates for new issues](https://github.com/blog/2111-issue-and-pull-request-templates)**. This is just a bit of Markdown, meaning that reporters could be given some [task list checkboxes](https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-comments). If we do that, what ought to go there?
@yourfirstpr and @Charlotteis [remind us](https://twitter.com/yourfirstpr/status/700303824892768257) that the template's job is to make the project more accessible. What can we do there to improve our workflow? There seem to be two main jobs here:
- Leading new reporters through the process of reporting an issue
- This is a crowd with few coding skills, but deep knowledge in other areas and a very clear idea of what they want, or when something's wrong. MyPaint's userbase is artists, not coders. It's HIGHLY international, meaning that language can be a barrier when reporting.
- Gathering the information has the checkbox nature, and we really need that reproducibility info for the next stage
- Basic bug report/triage checkboxes: "I have searched for duplicates", "I've tried this with a fresh config", "I verified that this affects the latest stable version / the latest master HEAD", "I've written up what version this affects / what OS I'm using".
- Providing information to people with (some of) the skills required to fix the bug, and helping them grow their skills
- These folk will be more technical, a mix of triagers and coders. Sometimes the occasional icon artist or documenter.
- A canned workflow for us would be an improvement over our current rather lax approach. For starters:
- Checkbox: someone has managed to reproduce this issue enough for it to be fixed
- Checkbox: task-is-assigned
- Checkbox: forked and cloned and branched
- Checkbox: PR submitted.
The great thing about this is that it puts relevant information in the user's eyeline.
MyPaint already does something a little like this from the exception dialog: we offer a button for searching the tracker, and have a translated template in there on the Submit button that becomes unlocked after a search is started. We HAVE had a couple of reports with just the exception and an uncustomized template, however - perhaps due to the aforementioned language issues.
Perhaps an obvious checkbox-based reporting nature may help with this?
One thing is obvious: we shouldn't let the structure constrain us too much if we do this. Best make it clear that contributors can and should remove tasks which don't make sense.
One stumbling block: who has permissions to edit those checklists or the original post? That may make the ticky-box idea unworkable for the details.
