Removing "resolved" status from the GPII workflow...

[Tony Atkins]

Hi, All:

In last night's architecture meeting, we discussed the "resolved" status as
currently used in the following projects:

   - GPII
   - Developers Space
   - GPII Projects
   - Onboarding

The "resolved" status is meant to be a stage at which the reporter of the
issue verifies that they are satisfied with the outcome.  Our hope was that
especially non-developers reporting issues would have a key chance to see
our response to their input and to give their feedback.

In practice, this loop is seldom closed.  At least in the GPII project,
there are over 400 issues that have been resolved but never closed, many
have not been updated for years.  In the meeting last night, I argued that
it would be better to streamline our process, and remove the "resolved"
status, at least as a stopping point in our particular workflow.

In part, I argued that the reporter is already informed via notifications
throughout the process.  We also have the option to "at mention" them at
any time and explicitly ask them to confirm that they are happy with the
proposed direction.  Involving them throughout the process seems more
useful than developing, reviewing, and merging a fix, and only then getting
their feedback.

Although there was still some concern about this, we agreed to try out a
new workflow in the GPII project, one that does not allow issues to be
moved to the "resolved" status.  After some thought, I have come up with a
reversible process, which is as follows:

First, to avoid affecting other projects, we would "clone" the existing
workflow and make a new workflow and workflow scheme for any changes.  This
workflow would have the rest of the existing steps, but there would no
longer be any transitions to or from the "resolved" status.

Before that is deployed, we need to deal with existing "resolved" issues in
the GPII project. I would propose transitioning all currently resolved
issues in the GPII project to "closed".  As part of the bulk transition, I
will add a distinct tag to these issues, so that if we decide to reverse
this decision, we have some indication of which issues were closed in bulk.

We would then update the workflow used by the main GPII project itself (I
also plan to update the UL and PTD projects, which I manage, to use the
same workflow).  The rest of the projects will remain as they are.

To reverse this process, we would update the GPII project to use the
previous workflow/scheme, and optionally transition the tagged issues back
to the "resolved" status.

As discussed, I have posted this to get your feedback.  If there are
concerns that are too large to work through on the mailing list, I will
revise the plan and review with the group at next week's architecture
meeting.  If the plan is acceptable or acceptable with minor revisions, I
will plan to implement the changes early next week.

Please comment by close of business on Friday at the latest.

Thanks,


Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20170209/86d7e4b9/attachment.html>