I don't know if it's ok for you to reopen those tickets and add the tag.

Not for this time. I plan to use that in the next cycle, but I'm not going to generate additional noise this time around. I like the addition, though. That's going to be a good improvement.

In a future development, we can make the step-two mark open tickets for which the user is still inactive with a pending_removal. And a step-three can be run so that all tickets are closed in the appropriate way, without manual intervention.

I don't see a need for an additional step. Step two can produce a list of accounts to remove and then close issues. I'll give the list to infrastructure to actually do the removals. I don't see the value in a third step.

Did you close #621 in favor of the changes in your check_impact branch?

Did you close #621 in favor of the changes in your check_impact branch?

Yes, I don't think it's useful anymore: for this run, the csv file has already been generated, while for the next run I'd like to heavily rewrite step-two so that:

• adds users from open tickets tagged "pending_removal" in the list of users to be removed
• checks activity for users from open tickets (without the "pending_removal" tag) and add them to the list of users to be removed if no activity is detected again. This is much faster than re-check the whole set of packagers and then make a join with the previous "inactive packagers" set.
• output the list of users to be posted to releng for removal and close tickets accordingly ("Removed from packagers" for those which were marked "pending_removal" or those still inactive, "Keep packager status" for those which some activity was detected in step-two).

I think I can have it ready before step-two of this run, but obviously for this run you will have to manually add users in your list those tickets have already been closed as "Removed from packagers".

The csv file output from step-one should be no more needed. For step-two we can make the script to open a ticket to releng rather than ouput a list and then having you manually open a ticket with the list... but that's another story.

What do you think?

Did you close #621 in favor of the changes in your check_impact branch?

Yes, I don't think it's useful anymore: for this run, the csv file has already been generated, while for the next run I'd like to heavily rewrite step-two so that:

Makes sense.

• adds users from open tickets tagged "pending_removal" in the list of users to be removed
• checks activity for users from open tickets (without the "pending_removal" tag) and add them to the list of users to be removed if no activity is detected again. This is much faster than re-check the whole set of packagers and then make a join with the previous "inactive packagers" set.
• output the list of users to be posted to releng for removal and close tickets accordingly ("Removed from packagers" for those which were marked "pending_removal" or those still inactive, "Keep packager status" for those which some activity was detected in step-two).

I think I can have it ready before step-two of this run, but obviously for this run you will have to manually add users in your list those tickets have already been closed as "Removed from packagers".

This sounds good. I have a list that I'm tracking in my todo list app. I could start going with the pending_removal tag from here on and merge the lists at the end. The improved speed would be a huge help (although hopefully subsequent runs should be a lot faster after this initial cleanup).

The csv file output from step-one should be no more needed. For step-two we can make the script to open a ticket to releng rather than ouput a list and then having you manually open a ticket with the list... but that's another story.

Agreed about removing the CSV file. I don't see any use for it with your proposal, although maybe it's worth keeping as a default-off option? Or maybe we drop it and can add it back later if we think of a reason to have it.

I'm not sure how I feel about the auto-creation of a ticket. I think at least this time around, I'm fine with a manual creation. There might be a reason for a person to give it a once-over before creating it.

I used the check_impact branch to develop changes for step-two automation.
I've preserved the "csv file mode": csv files in step-one and step-two are always produced. Both step-one and step-two can be run in "local" mode without the --open-tickets and --close-tickets flags. Moreover, step-two can be run from Pagure (default) or from the csv file produced in step-one.

Long story short:
** full off-line workflow **

$ find-inactive-packagers step-one
$ find-inactive-packagers step-two --from-file inactive_packagers.csv

** open-tickets + simulate step-two **

$ find-inactive-packagers step-one --open-tickets
$ find-inactive-packagers step-two

** real automated workflow **

$ find-inactive-packagers step-one --open-tickets
$ find-inactive-packagers step-two --close-tickets

So you can currently simulate step-two against real time data from open tickets without touching them.
I plan to write a "SOP" file, as the simple script has grown up...

Oh, and I made the email showed in the Pagure ticket always partially masked (the --privacy option is only used for logs, in case one needs to share logs with the public).

This looks great! If you want, you can make SOP edits to my in-progress PgM Guide SOP. If you'd rather keep it in this repo and leave my doc for the specific way I (and my successors) use this in pratice, that's okay too)

Implemented in #624