backlog > approved > backlog produces invalid tracking of issues

[mancdaz]

If a card is added to approved mistakenly, and then moved back to backlog, the date that the approved label is added is still captured, and any tools used to analyse the data are showing the issue as being in the system.

Is there some way we can ignore the 'date approved label added' if the issue is currently in backlog?

PS - I know cards should never move backwards.

[sigmavirus24]

Functionality like that can be added but it will greatly increase the complexity if done for just two columns like that.

Would it make sense to do this for all columns?

[mancdaz]

@sigmavirus24 yes I'd say so. Again, whilst knowing that work should never be moving backwards, we should really not be counting the date added for a label for a column that is 'in front' of where the card is right now.

[b3rn4rd0s]

@mancdaz @sigmavirus24 If we ignore the 'date approved label added', how will know when issues are moved into approved? Right now, the analytics tool uses this as the committed start date.

[sigmavirus24]

@b3rnard0 I believe @mancdaz only wants to do that when it moves backwards, not at all times.

[b3rn4rd0s]

@mancdaz Okay, so an issue moves backwards, the 'date approved label added' is removed. When do we track when the issue moves into approved? I feel we are missing data if an issue is essentially going to start in doing (which sounds like what we would be doing with this request). This would only apply to issues moving from approved back to the backlog or are we going to include other workflow steps post approved?

I could also mimic a couple of Github issues that would have this type of date data to show how it would appear in the metrics.

[sigmavirus24]

To be clear, I don't advocate us doing this, but it is technically plausible to do.

[mancdaz]

@b3rnard0 @sigmavirus24 I'm just suggesting we ignore the 'date approved label added' if the card is currently in backlog. If it's in approved and beyond, then still count it. And presumably if it got moved to approved, then back to backlog, then into approved again, it would have 2 dates for 'approved label added'. At that point, obviously we're only interested in the latest one.

[b3rn4rd0s]

We ran into an issue when we had conflicting dates, i.e., an approved start date that was later than the doing start date, so I would want @sigmavirus24 to weigh in on this issue. Ian ended up creating a cleanup portion of the script for these conflicting dates.

[sigmavirus24]

@b3rnard0 correct. That is on by default and disabled by --skip-date-normalization. As far as I was aware, this had been working. Is this now broken?

[b3rn4rd0s]

@sigmavirus24 It's been working fine. I'm wondering whether this proposed chance would conflict with the date normalization option?

[sigmavirus24]

I'm surprised it's not working for this. The date normalization (if I re-read the code correctly yesterday) looks for dates that are older than dates earlier in the list and then normalizes them so that the earlier dates are the same as the same as the later ones that occur first in the list.

Is the problem that we don't look at when something entered the backlog maybe? I don't think there's a label for that and so it would make sense that we don't catch this in that case.

[b3rn4rd0s]

The problem that Darren wants to solve is a way for us to not "count" those issues that get moved into approved or later and then get moved back into the backlog. Usually, these end up as outliers that can be safely ignored but we've started to have many of these now that some of the new teams are using GitHub/Waffle for their work tracking.

[sigmavirus24]

I guess my point is, how do we track that this happened. If I understand correctly, things without labels are in the backlog. That said, that definition might change. Is there a status-backlog label that we could use for all issues in the backlog column to make this explicit rather than something implicit?

[b3rn4rd0s]

We could add that label but that would mean getting those added during issue creation because a manual process won't scale for this. Seems this is getting really complex, really fast

[mancdaz]

Can't we do what waffle does - assume that the absence of a status-* label means it's in the backlog?

On Wed, 8 Feb 2017, 19:50 Bernardo Salinas, notifications@github.com wrote:

We could add that label but that would mean getting those added during issue creation because a manual process won't scale for this. Seems this is getting really complex, really fast

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rcbops/gh2/issues/7#issuecomment-278441384, or mute the thread https://github.com/notifications/unsubscribe-auth/AAiUVtO8j8vNuAupMHel_0rtjzuM3KODks5rahyJgaJpZM4L4Qw_ .

[sigmavirus24]

That seems like a fragile assumption to me and that's an inaccurate statement. Open issues without a status label is probably in the backlog. Closed issues without status labels are finished/devdone/whatever.

That said, if someone in GitHub, removes status labels accidentally, that shouldn't really send it back to the backlog necessarily. But that's a case where we probably don't want to just assume it's been moved back to the backlog.

[mancdaz]

Except that's exactly how waffle would interpret and display it, so if someone did do that then for all intents and purposes it would be back in the backlog.

So ok, open and no status-* label equals backlog. That's how waffle would see it, so that's how we would see it...so therefore that's how we'd want our script to interpret it.

All that said, if we feel like this is not solvable in code, then I can just try and work around it when people do move work backwards (which they shouldn't be doing anyway, but it sometimes happens)

On Wed, 8 Feb 2017, 20:16 Ian Cordasco, notifications@github.com wrote:

That seems like a fragile assumption to me and that's an inaccurate statement. Open issues without a status label is probably in the backlog. Closed issues without status labels are finished/devdone/whatever.

That said, if someone in GitHub, removes status labels accidentally, that shouldn't really send it back to the backlog necessarily. But that's a case where we probably don't want to just assume it's been moved back to the backlog.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rcbops/gh2/issues/7#issuecomment-278448587, or mute the thread https://github.com/notifications/unsubscribe-auth/AAiUViRt4Z4Q_sWeOSpWPnR1rltwon83ks5raiKngaJpZM4L4Qw_ .

[sigmavirus24]

So it's probably solvable by doing something akin to:

if any(labeled_dates) and not [l for l in issue.labels if l.starstwith('status-')]:
   # unset any labeled dates

That would, however, remove every date, so if a card has gone from backlog > approved > doing ... etc, then we'd have none of that information.

@b3rnard0 is that kind of dramatic change from one import to the next acceptable to the tool or will it complain at you?

[b3rn4rd0s]

@sigmavirus24 I haven't done testing of the various date scenarios.

Does the above remove the issue creation date? If issues are showing up without the initial dates and hoping into doing, for example, that's even worse.

This would be easily solved by a cloning or duplicating GitHub issues functionality as we would just close the issue that needs to move backwards, add a invalid label, and clone the new issue to the backlog.

[b3rn4rd0s]

@mancdaz Was thinking about this again this morning (sorry) but another option is that we only measure the start and end dates for our metrics. While not the ideal solution, this would allow us to move issues backwards as needed because we only care about when an issue is created and when it's completed and the tool can handle these types dates regardless of moving backwards. This is based on the forecasting/metrics class I took recently as the only measure start and end dates and they still get very valuable information. I can also play with this option by essentially eliminating all of the middle date columns in the CSV file. What I would need to test is whether removing the middle dates has a drastic impact on the metrics we are gathering for the various projects, however, the data should be similar enough for use in forecasting and measuring performance. I'll know more next week when I have a little more time to test this option.

This would allow us to reduce the complexity of the script.

[sigmavirus24]

Does the above remove the issue creation date?

It shouldn't.

This would allow us to reduce the complexity of the script.

It would drastically reduce complexity. That said, there was scaffolding in the script to make the columns & mapping of column -> data field configurable. If someone wanted to finish up that work, you wouldn't have to edit the CSV files manually, you could just regenerate them.

[mancdaz]

Currently we measure cycle time from when an issue goes into approved, through to when it's closed/dev done. This proposal would start the clock ticking from the date the issue is created (placed in the backlog) which would produce significantly different metrics, no?

[b3rn4rd0s]

@mancdaz Right, we should measure when things go into approved as that is our commitment point. Good catch. I think this should work fine but I'll need to explore this a little bit.

@sigmavirus24 Does the script use the latest status-approved date if issues are moving backward into backlog or does it use the initial status-approved date? This change would mean we are only going to measure the latest status-approved date and the done date and hopefully that keeps it mostly simple.

[sigmavirus24]

@b3rnard0 I'm not sure which date it would use. I never tested that scenario. goes off to look

[sigmavirus24]

Right now it uses the first it finds. If we want to remove support for other columns/labels we can make that fit our needs more specifically (i.e., pick the latest date).

[b3rn4rd0s]

Okay, so the next step for me is to investigate how that looks, metrics-wise.

@mancdaz Thoughts?

[mancdaz]

Regardless of using the first or the latest date for a column, we still have the original problem - if something moved to backlog after having been in any of the columns ahead of it, there will be dates for those columns and it will make the analytics tool get confused.

I guess all I was asking for originally was that we strip any dates for any columns, if the card is currently in backlog.

On Thu, 9 Feb 2017, 16:27 Bernardo Salinas, notifications@github.com wrote:

Okay, so the next step for me is to investigate how that looks, metrics-wise.

@mancdaz https://github.com/mancdaz Thoughts?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rcbops/gh2/issues/7#issuecomment-278693813, or mute the thread https://github.com/notifications/unsubscribe-auth/AAiUVrolg5YvZs7CbIZPNnaz9K4BzWxvks5raz5_gaJpZM4L4Qw_ .

[b3rn4rd0s]

@mancdaz I'm in the process of analyzing the JIRA plugin version of the tool and will see how moving issues backwards is handled, if at all. More to come but I believe any changes that are handled would be through the JIRA version and not this scripted version.

[mancdaz]

No problem @b3rnard0 - for now in the csv/agileanalytics tool I handle this with a combination of education, and invalidating/recreating new cards in the backlog where it does happen. Since I raised this issue with the team, we've not had another incidence of it occurring. We can close this issue since it relates specifically to gh2.