Project

General

Profile

Feature #16545

Make contributors aware of stalled work regularly

Added by u 6 months ago. Updated about 1 month ago.

Status:
Needs Validation
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
03/07/2019
Due date:
% Done:

0%

Feature Branch:
Type of work:
Sysadmin
Blueprint:
Starter:
Affected tool:

Description

Create automated emails every 45 days to individuals

We've created two Redmine views:

"Stalled: Unblock other people's work"
https://redmine.tails.boum.org/code/projects/tails/issues?query_id=317
This view shows tickets assigned to a contributor, while the ticket status shows that someone else is waiting for their input.

"Stalled: WIP & not updated for a while"
https://redmine.tails.boum.org/code/projects/tails/issues?query_id=316
This view shows tickets assigned to a contributor, that are work in progress but have not seen activity since a while. Mostly tickets on which 80% of the work is done and that can either be finished or could be assigned to a relevant team to take over.

Using the YAML list (#16544), send everyone on that list a link to this Redmine view + filtered for them,
asking them if they think they can realistically come back to it and finish the work in the next 6 months;
expected valid answers / possible actions are:
- yes ⇒ add suitable target version and when relevant, blocks the "Core work: $team in $quarter" ticket
- no ⇒ deassign yourself, then: if relevant for a core team, bring it to their attention; else, forget it, make some tea and have a bath :)


Related issues

Blocked by Tails - Feature #16544: Create YAML of assignee names from Redmine view for ticket triaging Resolved 03/07/2019

History

#1 Updated by u 6 months ago

  • Blocked by Feature #16544: Create YAML of assignee names from Redmine view for ticket triaging added

#2 Updated by intrigeri 6 months ago

  • Status changed from New to Confirmed

#3 Updated by intrigeri 5 months ago

  • Description updated (diff)

#4 Updated by intrigeri 5 months ago

  • Target version changed from Tails_3.15 to Tails_3.14

#5 Updated by intrigeri 4 months ago

  • Target version changed from Tails_3.14 to Tails_3.15

I first need to implement the workflow change (dropping the "QA Check" field) I've proposed, then to update Enrico's script accordingly.

#6 Updated by intrigeri about 2 months ago

  • Status changed from Confirmed to Needs Validation
  • Assignee changed from intrigeri to u

Hi @u!

I have something that works locally. All pieces are deployed in production already except the cronjob, because I'd like your feedback about the content of the email it's going to send. My draft lives there: https://git.tails.boum.org/puppet-tails/tree/files/redmine/reminder/email_body

A few things that we did not consider initially IIRC, though, and for which I need your input (or consent, in some cases):

  • I'm not sure what the From field should be. Possibly you, as our ticket triager? Except this might stop working if your email server ever does DKIM/SPF/whatever. For now, I've set From: root$FQDN@, which is not ideal.
  • Similarly, we need a To field makes it too likely that the message is classified as spam. Here as well, I'd be inclined to set your address there, and set all other recipients as Bcc. Shall I do that?
  • cron does not easily allow doing something every 45 days; the closest cheap options to that are: either every month or every 2 months; I think every 2 months is sufficient; what do you think?
  • Be it wrt. "stalled WIP" or "reviews waiting for a long time", we have at least as many problematic tickets that this code will not identify as those it will point people to. These problematic tickets, that our setup will miss, are those which have a target version that's been postponed after the N last releases by the Release Manager: every such Target version bump counts as an update so there's no chance the ticket will ever be identitied as stalled. That of course does not imply that what we did is useless nor that we should block on this. But I'd like us to think this through and address it if we can do so easily. For example, we could do one pass every year or so on the tickets whose target version is the next Tails release, and whenever the target version was bumped by the RM since 6+ months after each release, with no update by the assignee, we drop the target version and paste a nice comment from a template. I'd be fine with doing the first pass in the next few months myself. Then our queries about stalled WIP and reviews will be able to notice those tickets, starting 6 months later. What do you think?

#7 Updated by u about 2 months ago

@intrigeri,

I have something that works locally. All pieces are deployed in production already except the cronjob, because I'd like your feedback about the content of the email it's going to send. My draft lives there: https://git.tails.boum.org/puppet-tails/tree/files/redmine/reminder/email_body

Nice!

A few things that we did not consider initially IIRC, though, and for which I need your input (or consent, in some cases):

  • I'm not sure what the From field should be. Possibly you, as our ticket triager? Except this might stop working if your email server ever does DKIM/SPF/whatever. For now, I've set From: root$FQDN@, which is not ideal.

My address as from will not work, my mail server migrated last week to a new one and SPF/DKIM will be in place if it's not already.

Either, we keep using root@FQDN, or we set up some sort of alias (that can forward emails to me). I'm not sure how to request such an alias.

  • Similarly, we need a To field makes it too likely that the message is classified as spam. Here as well, I'd be inclined to set your address there, and set all other recipients as Bcc. Shall I do that?

If I get it right, we do send out one email per person, is that correct? So why do addresses need a Bcc:, when they can have a clear To: field? Not sure why the one or the other would make spam detectors cough more or less.

  • cron does not easily allow doing something every 45 days; the closest cheap options to that are: either every month or every 2 months; I think every 2 months is sufficient; what do you think?

Agreed.

  • Be it wrt. "stalled WIP" or "reviews waiting for a long time", we have at least as many problematic tickets that this code will not identify as those it will point people to. These problematic tickets, that our setup will miss, are those which have a target version that's been postponed after the N last releases by the Release Manager: every such Target version bump counts as an update so there's no chance the ticket will ever be identitied as stalled. That of course does not imply that what we did is useless nor that we should block on this. But I'd like us to think this through and address it if we can do so easily. For example, we could do one pass every year or so on the tickets whose target version is the next Tails release, and whenever the target version was bumped by the RM since 6+ months after each release, with no update by the assignee, we drop the target version and paste a nice comment from a template. I'd be fine with doing the first pass in the next few months myself. Then our queries about stalled WIP and reviews will be able to notice those tickets, starting 6 months later. What do you think?

That sounds like a very good plan. Should I ask enrico if he thinks this could be automated? It would avoid us a lot of boring and recurring work.

#8 Updated by u about 2 months ago

@intrigeri

I have something that works locally. All pieces are deployed in production already except the cronjob, because I'd like your feedback about the content of the email it's going to send. My draft lives there: https://git.tails.boum.org/puppet-tails/tree/files/redmine/reminder/email_body

I like the text and the signature :)

So we don't include a list of ticket numbers in that email?

#9 Updated by u about 2 months ago

  • Status changed from Needs Validation to In Progress
  • Assignee changed from u to intrigeri

#10 Updated by intrigeri about 1 month ago

So we don't include a list of ticket numbers in that email?

No, the plan was to do the cheapest possible thing, i.e. point folks to the place where they will find their list (after logging in).

#11 Updated by intrigeri about 1 month ago

Dear @u,

  • I'm not sure what the From field should be. Possibly you, as our ticket triager? Except this might stop working if your email server ever does DKIM/SPF/whatever. For now, I've set From: root$FQDN@, which is not ideal.

My address as from will not work, my mail server migrated last week to a new one and SPF/DKIM will be in place if it's not already.

Either, we keep using root@FQDN, or we set up some sort of alias (that can forward emails to me). I'm not sure how to request such an alias.

Thanks, that's the info I needed. I'll try to find & implement a cheap solution, which should be easier now that we host a MX.

  • Similarly, we need a To field makes it too likely that the message is classified as spam. Here as well, I'd be inclined to set your address there, and set all other recipients as Bcc. Shall I do that?

If I get it right, we do send out one email per person, is that correct?

Well, I did the cheapest thing i.e. send one single email to all affected folks. Indeed, sending one email per person would fix this problem. I'll do that. Thanks!

  • Be it wrt. "stalled WIP" or "reviews waiting for a long time", we have at least as many problematic tickets that this code will not identify as those it will point people to. These problematic tickets, that our setup will miss, are those which have a target version that's been postponed after the N last releases by the Release Manager: every such Target version bump counts as an update so there's no chance the ticket will ever be identitied as stalled. That of course does not imply that what we did is useless nor that we should block on this. But I'd like us to think this through and address it if we can do so easily. For example, we could do one pass every year or so on the tickets whose target version is the next Tails release, and whenever the target version was bumped by the RM since 6+ months after each release, with no update by the assignee, we drop the target version and paste a nice comment from a template. I'd be fine with doing the first pass in the next few months myself. Then our queries about stalled WIP and reviews will be able to notice those tickets, starting 6 months later. What do you think?

That sounds like a very good plan. Should I ask enrico if he thinks this could be automated? It would avoid us a lot of boring and recurring work.

I'd love to be surprised but I expect that:

  • It's not cheap to specify the exact algorithm the automation should implement in all corner cases (e.g. what to do if the assignee was the RM back then?)
  • It's not cheap to implement said specification (who was the RM back then?)
  • In quite a few cases, for human/social/accounting/management-ish reasons, doing the automated thing would cause all sorts of trouble, such as workers confusion ("so, what's my deadline, in the end?"). So I think that someone will need to review all the resulting Redmine changes and occasionally revert some of them with personalized explanations/apologies. I'm not sure that all in all it's better (for us and contributors) than doing it by hand in the first place.

Right now that's 87 tickets we would need to go through for the initial pass. It's indeed quite some work but the number should drop quickly, once we've dealt with the initial backlog and folks get used to a new, stricter meaning of "target version". Given this and the fact I'm proposing to do it only once a year, I feel more optimistic than "lot of boring and recurring work".

In any case, if we go for the automated way, I suspect we'll need to go through a bunch of these tickets by hand first, in order to tell what the algorithm should be and provide examples of what we expect it to do.

Oh, but actually, what about this: the automation does not do any change on Redmine, but instead computes a list of tickets that are candidates for dropping target version? This relaxes quite a bit the need for the algorithm to be excellent and it addresses my concern about automatic changes being undesirable in some cases. It still saves quite some of the boring work and allows humans to focus on what we're better at than computers. There's some boring/repetitive work remaining but perhaps not much more than reviewing automatic changes?

#12 Updated by intrigeri about 1 month ago

  • Status changed from In Progress to Needs Validation
  • Assignee changed from intrigeri to u
  • Target version changed from Tails_3.15 to Tails_3.16

I've implemented everything discussed above and enabled the cronjob, which should run every 2 months, on the 17th. Please let me know if something goes wrong (or if it does not run at all).

#14 Updated by intrigeri about 1 month ago

A first batch of email was sent!

#15 Updated by u about 1 month ago

intrigeri wrote:

A first batch of email was sent!

It worked :)

#16 Updated by u about 1 month ago

@intrigeri

Right now that's 87 tickets we would need to go through for the initial pass. It's indeed quite some work but the number should drop quickly, once we've dealt with the initial backlog and folks get used to a new, stricter meaning of "target version". Given this and the fact I'm proposing to do it only once a year, I feel more optimistic than "lot of boring and recurring work".

Agreed.

In any case, if we go for the automated way, I suspect we'll need to go through a bunch of these tickets by hand first, in order to tell what the algorithm should be and provide examples of what we expect it to do.

Oh, but actually, what about this: the automation does not do any change on Redmine, but instead computes a list of tickets that are candidates for dropping target version? This relaxes quite a bit the need for the algorithm to be excellent and it addresses my concern about automatic changes being undesirable in some cases. It still saves quite some of the boring work and allows humans to focus on what we're better at than computers. There's some boring/repetitive work remaining but perhaps not much more than reviewing automatic changes?

Yes, I don't expect the algorithm to do anything besides computing the list.
If you think it would be doable and have fun doing it, I would say go ahead and clock as ticket triaging work.

Also available in: Atom PDF