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

[Tony Atkins]

Hi, All:

The proposed changes have been made.  I performed two bulk updates, one to
tag the "resolved" issues, and another to transition them.  I triggered
mail notifications on the second bulk update, and included an explanatory
note.   This was the best way I could find to make sure that less frequent
participants would be informed of the change.  Those of you who have
participated in lots of issues over the years may get quite a few
notifications as a result.  Thanks in advance for your patience.

Also, I sent a private note to Justin, but to confirm, this change was only
made to the GPII, UL, and CTR projects on the GPII JIRA instance.  No
changes were made to other projects, or to the Fluid instance.

Cheers,


Tony


On Tue, Feb 14, 2017 at 5:09 PM, Justin Obara <obara.justin at gmail.com>
wrote:

> 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/20170215/be050e05/attachment.html>