Work Flow for Bug Reports First should this be a general work Flow for support? Another point is that what I write is necessarily from QA and/or user view. Developers may wish to modify or expand on their part in this. And make no mistake their part is major major. (That's right double major!) ################################################################################### Links for reference, reading, and whatever: https://help.github.com/articles/managing-your-work-with-issues/ https://kaosx.us/docs/bugs/ https://github.com/KaOSx/apps/issues https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow https://fedoraproject.org/wiki/Bugs_and_feature_requests#The_Bugzilla_workflow https://wiki.mageia.org/en/Triage_guide https://wiki.mageia.org/en/Bug_Squad_Portal https://wiki.ubuntu.com/Bugs/Triage/ https://guides.github.com/features/issues/ https://opensource.com/article/18/4/keep-your-project-organized-git-repo https://opensource.com/life/16/7/how-take-your-projects-github-issues-good-great https://coenjacobs.me/2013/12/06/effective-bug-reports-on-github/ https://www.theozimmermann.net/2017/10/bugzilla-to-github/ https://forums.xamarin.com/discussion/111394/migrating-to-github-issues-and-projects ############################################################################################# Need to define support (for us basically forum/IRC) versus technical issue/bug report/IRC ie. a flaw in the software or feature request. A support request is one user having a problem with their computer. A bug is a problem or flaw in the software. This is from https://coenjacobs.me/2013/12/06/effective-bug-reports-on-github/: "What is requesting support and what is a bug report? A support request can actually be a bug report, but not the other way around. The purpose of resolving a support ticket is to solve a problem for one user. A bug report is to explain a bug in the software, to make the software more stable. Let’s take a look at two example and where these two overlap. This is an example of a (actually surprisingly well structured) support request: Error when using plugin X and Y I just activated plugin X and now plugin Y shows this error: …. How can I resolve this? Here’s the same problem, explained in the form of a bug report: Conflicting function name in plugin X and Y Both plugins X and Y use function name … and this results in the error: … The support request and the bug report are both aimed at resolving the same bug. If I would read the support request, as a support employee, I would probably try to debug this first. Eventually I would figure out the cause of the problem and would report the bug to the developers in the form of the above example bug report. When a user asks for support, without knowing the cause of the problem, it’s a support request. When it turns out that the problem is in fact a bug, the support request becomes a bug report and can be treated as such." ################################################################################################# Simple bug report work flow: 1. User reports issue 2. QA person evaluates report and decides if this is a support issue, a flaw in software or code (ie. a bug), or a feature request. 3. Triage >>> QA person decides where or to whom issue report should go. We are woe fully lacking in guidance for this. 4. If support issue then someone (QA, tech-savvy contributer, or dev) tries to help user with their problem. If technical issue the developer assigned fixes bug or reports otherwise. If feature request the Package Maintainer or Dev assigned either builds new package/packages or explains in user understandable language why we can't do this. Liscense, closed source, doesn't work with our code, package upstream is abandoned/not supported, ect. 5. QA reports results to user. 6. User confirms their issue is resolved, or acknowledges that we will fix in future version of package or OM Lx. Or otherwise like Upstream, Cantfix, ect. Now what needs to be done is to refine the above and correct it as need for specifically what me may call ISSUE TICKET, ISSUE REPORT, or my preferred BUG REPORT. To be decide is do we include support request in bug reports (if user so desires) or restrict bug reports to only technical issues and feature requests. Or can we make a distinction between the two with a label or something? #################################################################################### This link is unrelated to above and for package QA: https://wiki.mageia.org/en/QA_process_for_validating_updates ####################################################################################### Another Bug Work Flow (courtesy of crazy): well normally this should go like this : someone open bug report .. it should be auto-ssigned to QA@.. , QA peoples look the bug and assign self to responding devel@ .. , devel@ should fix and push to testing , now QA are going to test the fix and if OK move from testing to updates , close bug , if not back to devel@ until fixed so assign and verify the fix shold be QA task not random devel pushes something and closes bug who should close the bug? Ultimately the person who reported, right. no QA should close the bug OR: 1. User reports bug >>> bugs are automatically assigned to QA 2. QA looks and evaluates and if warranted assigns to developer 3. Developer should fix and push to testing 4. QA to test the fix and if OK move from testing to updates. If not OK back to developer until fixed. 5. QA closes bug. The above might just work. The individual points may need to be expanded on a little and some things need to be defined. IMO.