[Trisquel-devel] New bugtracker workflow proposal

[Andrew 'Leny' Lindley]

Long post warning

From: santi at trisquel.info (Santiago Rodríguez)
Subject: [Trisquel-devel] New bugtracker workflow proposal
Date: Fri, 6 Mar 2015 00:54:15 +0100

> As discussed in our last meeting, the current bugtracker  makes it
> difficult to find bugs to work on, and that has a heavy impact over users
> that want to contribute to trisquel, but aren't able to find a field to
> help with.
> 
> I outlined a propossal in
> 
> http://trisquel.info/en/wiki/bugtracker-proposal
> 
> wich I think cover almost all current usages, including also user support
> requests that can not be considered as bugs,  and make things a bit
> clear.
> 
> Any comments/feedback ?
> 

Here are my thoughts  (pasted from the ORG mode file)

* Intro

I think we need to take a step further back from the current system
and look at taxonomies and workflow.  This is an alternative view
which tries to leave presumptions inducted from the existing system
aside for the early part of discussions. 

* Taxonomy Proposals

** A User Issue is one of 

*** Help/Support Request 
  The default for new problems which need further diagnosis
*** Diagnosed Problem Report
  The user already knows *exactly* where the problem is and might even
  have a patch

** A User Issue is handled by one or more *logical* teams or roles

Obviously, presently many Trisquel volunteers will wear more than one
hat.

*** Fora (aka Forums see data / datum)
*** Triage
*** Compliance 
  GNU FSDG, Branding, Legal and other problems which can 'stop the distro'
*** Trisquel Desktop
*** Trisquel Mini Desktop
*** Sugar (TOAST)
*** Trisquel Console Environment
*** Server - Education
*** Server - Business
*** Web
*** Installer
*** Beta / Next Release
*** Documentation
*** Translation
*** Year 2038?
As of 8.0 perhaps. I expect developers working toward Y2038 will need
at least a virtual machine GNU/Linux which has a basic system to
develop on top of.  As with a Debian 'port in development' one of the
GNU FSDG distros should facilitate this requirement with a distinct
repo & build.
*** Other
*** Remix Teams such as
**** Triskel Desktop 


** An issue has an attribute which reflects the importance it has to the user

(aka Priority)

And by logical extension this reflects how much work the user is
prepared to put into helping diagnose the problem.  If a user claims
it is critical, then it is reasonable to expect them to spend a full day
or more collecting diagnostics. 

** An issue has an attribute which reflects the impact of the problem

(aka Severity)

In descending order

*** Compliance Matters (they could 'stop the distro' after all) 
*** System Down / Unusable
*** Subsystem Down / Unusable
*** App Down / Unusable
*** Normal Bug
*** Feature Request / Wishlist

* Workflow


** The User Issues process is essentially...
...one of diagnosis and communication.

*** The goal of handling a User Issue is...
...to resolve it in some way.  Preferably one which the user agrees
with, even if reluctantly.

*** Conceptually the user(s) 'own' the User Issue

** The Developer Issues process is essentially...
...one of actioning a Unit of Work of Code Change.  Which might or
might not be as a result of a User Issue.

*** The goal of handling a Developer Issue is...
...robust change management to the required standards of stability
and documentation (the latter to facilitate teamwork).

*** Conceptually the user(s) 'own' Developer Issues too

** Process

*** The one rule of this process

It's not so much a process as a mental framework to assist in making
sure the volunteer is doing/has the right things in the right order. 

**** 0. Leave some breadcrumbs (optional?)

Businesses do this because customers will not stand three months
diagnosis work going down the drain because someone leaves the
company.  But the principle applies here from 'Conceptually the user
'own(s)' [Developer] Issues.'  Leave some breadcrumbs so the user
isn't left in the lurch when you dash off to code the category killer
app you've just thought of, or met the love of your life or whatever.
A quick summary of what new you've worked out at the end of each
session, or if you're writing code push a commit of where you're at at
the end of each session.

**** 1. New User Issue

1.1 Choose one of 

1.1.1 Help Support Request - Goto 2. Triage 

1.1.2 Diagnosed Problem Report - Goto 3. Team Validation


**** 2.  Triage 

2.1 Elicit Environment (Release, package name, hardware etc as
appropriate) 

2.2 Elicit a suitably specific description. E.g. How to recreate; what
was expected and what actually happened; what the error message text
was *exactly*; what & where the incorrect text is in the
docs/translation etc.

2.3 Search Trisquel.info and the web to see if this is a known
problem.  Mark UI 'upstream' if it is resolved in later release
there. 

2.4 Advise the user of any bypass, potentially drop Severity as
appropriate.  Perhaps consider the UI resolved if there is a
bypass/workaround.

2.5 Determine team and mark Issue as theirs.  Go to 3. Team Validation


**** 3. Team Validation

3.1 Get either from the user or by recreation the diagnostics required
to tie the problem down to 'the culprit line.'

3.2 Turn this into a a Diagnosed Problem Report

3.3 Repeat 2.3 and 2.4 with the new info, paying particular attention
to upstream bug reports / issues / commits in later releases

3.4 Potentially Create a Developer Issue for any required Code
Change.  Go to 4. Developer Issue

**** 4. Developer Issue

4.1 Are you sure you should be doing this?

I'm guilty of this... picking low hanging fruit from the first page
of User Issues.  When there are FSDG issues which are years old which
definitely should be higher on my priority list.

But speaking of priorities, is this a bug which could be fixed at the
root upstream developer in a future release?  This is especially true
if you've developed new code to replace non-free or whatever.  

4.2 Code

4.3 Test
4.4 Test
4.5 Test

There, I've told you three times. :)

4.6 Feedback to the user via the User Issue when it is in the repo

4.7 Close it if they don't reply in a suitable time.

*** END PROPOSAL / SUGGESTION ***

> I also want to ask about a follow-up to the meeting we had in February, as
> more than one month has passed and there isn't any news.

I'll create a separate sub-thread for the reply to this.

Leny