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

[Justin Obara]

Is this specific to the GPII instance, or also the FLUID JIRA instance?

Thanks
Justin


On February 14, 2017 at 9:56:47 AM, Tony Atkins (tony at raisingthefloor.org)
wrote:

Hi, All:

Hi, All.  In the spirit of "lazy consensus", barring any objections, I plan
to make the proposed changes in the morning.

Cheers,


Tony

On Thu, Feb 9, 2017 at 10:58 AM, Tony Atkins <tony at raisingthefloor.org>
wrote:

> 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
>

_______________________________________________________
fluid-work mailing list - fluid-work at lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20170214/8a361bf2/attachment.html>