Xenopeek,
I was looking at the github for reporting errors and ran across issue 322 after reading through
https://linuxmint-troubleshooting-guide ... index.html. Reading through some of the potential issues I found you were helping out over there as well. Thanks!
In response to issue 322 I created issue 448. If this can be done with github I think it could really help with getting quality issue reports to the developers. The text of 448 follows:
Suggestion: Reduce Wasted Developer Time with Required Issue Data and Non-developer Triage
I believe a more formulaic procedure for describing a potential issue will benefit Linux Mint. I think there should be a series of input sections requiring an issue reporter to provide the type of issue (bug/upgrade), Linux mint version, observation, expectation, reproducibility, responsibility, change, environment, and errors. After providing this input the reporter should be asked a series of questions to help identify if the problem is with Mint or Upstream.
Once the issue description is completed and submitted by the reporter a Mint resource would then review the issue section by section. In the event there is a problem in any section the Mint resource will flag the section and the issue will be kicked back to a queue only viewable by the reporter along with an email notification. The email notification will identify the section in question along with a link to a resource similar to
https://linuxmint-troubleshooting-guide ... index.html. The issue reporter may then update the issue and resubmit.
In the event the Mint resource finds no significant issue with the potential issue and the issue should be reviewed by the development team it will be copied to a queue available for review by all developers or perhaps a subset who defines priorities. In the issue list available to all issue reporters the issue’s status will be changed to under review.
Benefits:
This procedure keeps multiple developers from reviewing the same issue. The issue reporter will be prompted to enter sections for all required information. In the event issue documentation needs to be tweaked the reporter can be prompted to do so. Odds are higher a significant issue will not be ignored as information required for evaluation will be required from the issue reporter. A non-development Mint resource can be used to triage potential issues. Issue reporters will feel more vested in the process as they see the issue status change to under review.
I was inspired to write this after reading
https://github.com/linuxmint/linuxmint/ ... issues/322.
).