Grammar problems and a typo on this line.
Perhaps: "Users whose account is protected with 2FA are always considered verified."

Suggested grammar edit: "We all know that priorities change throughout life. Seeing a valued contributor leaving makes us sad, but it may happen. Prior to departing, please consider performing the following steps:"

"Users in the packager group can push code into official Fedora repositories. If one of these users loses ownership of the email address associated to the Fedora account, it could lead to a potential security breach."

"Orphan all packages where you're the primary admin, allowing someone else to step in and take them."

This step should occur prior to the previous step, so maybe add another, earlier instruction to identify the packages that should be orphaned.

"will download /the/ list of packagers"

Thanks, I've applied the suggested changes.

I've removed the WIP tag from the title and urged people to vote in https://pagure.io/fesco/issue/2759

As the person who will apparently be responsible for running the script, I have a few concerns:

• The policy doesn't say who is responsible for carrying it out. The script won't run itself. Having explicit responsibility in the policy helps with accountability and will help make sure that someday when I'm replaced by the next FPgM, it will be more clear to my successor and their manager that this is part of the job duties.
• The two month period seems arbitrary. Why not once per release in the same way we do the provenpackagers check? Or at least pick 2-3 milestones in the release cycle so that it can be added to the schedule. i'd be in favor of two tasks in each release schedule (where they fall is unimportant to me)
  • Check for inactive packagers
  • (2 months later) Removal of inactive packagers
• There are probably some packagers for whom we don't have a reliable BZ<->Fedora mapping, so we should be aware that the BZ check may not catch everyone who is "active"
• The simplest way to keep state is to leave their tickets open until the expiration period, which could make it harder to find issues in FESCo's queue. Using a separate, dedicated repo for this may be a better option, especially since the process as proposed doesn't require FESCo to act.

I can't support the proposal as-is, but with the changes above, it would be more sustainable.

There are probably some packagers for whom we don't have a reliable BZ<->Fedora mapping, so we should be aware that the BZ check may not catch everyone who is "active"

IIRC @pingou eradicated this.

The simplest way to keep state is to leave their tickets open until the expiration period, which could make it harder to find issues in FESCo's queue. Using a separate, dedicated repo for this may be a better option, especially since the process as proposed doesn't require FESCo to act.

+1

There are probably some packagers for whom we don't have a reliable BZ<->Fedora mapping, so we should be aware that the BZ check may not catch everyone who is "active"

IIRC @pingou eradicated this.

Sadly no.

There's a script that finds such people and mails them a nag, but it's still needs a human (and I guess it's me?) to propose dropping them.

The packagers_without_bugzilla toddler just ran and noticed some packagers without
valid bugzilla account. The list of them is here:
- acabral (email: avelar.analuiza@gmail.com) has no corresponding bugzilla account
- michaelanguskelly (email: mkelly@arista.com) has no corresponding bugzilla account
- nicknas (email: nicoalcaine@gmail.com) has no corresponding bugzilla account
- tkrizek (email: tkrizek@mailbox.org) has no corresponding bugzilla account

Each person on this list has been notified and, hopefully will fix the situation.
Failing to do so, this notification may be used a record for a potential
non-responsive packager procedure.

Have a wonderful day and see you (maybe?) at the next run!

There are probably some packagers for whom we don't have a reliable BZ<->Fedora mapping, so we should be aware that the BZ check may not catch everyone who is "active"

IIRC @pingou eradicated this.

Sadly no.

There's a script that finds such people and mails them a nag, but it's still needs a human (and I guess it's me?) to propose dropping them.

That's correct, we have a toddler notifying daily the user impacted and twice a
day the admins (it's even 3 emails: 2 about the failure to sync dist-git to
bugzilla and 1 with the summary of problematic accounts).

I've been letting them flow for a while and after sometime I would just go in,
check for how long they have been running and email the devel list + FESCo
ticket a week later or so.

The packagers_without_bugzilla toddler just ran and noticed some packagers without valid bugzilla account. The list of them is here:

At some point I need to patch this line as the list return includes packagers
but also non-packagers who have enabled "watch issues" on src.fp.o and are thus
added to the CC list synced to bugzilla.
Adding this precision is helpful as sometime we have weird account showing up,
which are not packagers, and we wonder how they got in the list

As the person who will apparently be responsible for running the script, I have a few concerns:

• The policy doesn't say who is responsible for carrying it out. The script won't run itself. Having explicit responsibility in the policy helps with accountability and will help make sure that someday when I'm replaced by the next FPgM, it will be more clear to my successor and their manager that this is part of the job duties.

Yep, I wasn't sure if I should specify who is responsible to run the script. Should I add a line to say that is "FPgM" (whatever the acronym stands for)?

• The two month period seems arbitrary. Why not once per release in the same way we do the provenpackagers check? Or at least pick 2-3 milestones in the release cycle so that it can be added to the schedule. i'd be in favor of two tasks in each release schedule (where they fall is unimportant to me)
• Check for inactive packagers
• (2 months later) Removal of inactive packagers

The two months period is because the same script will provide the list of inactive packagers and also the list of packagers that didn't replied after the previous run.
At least, that's how the script I wrote as today works. It can be changed, though. See https://pagure.io/find-inactive-packagers

• There are probably some packagers for whom we don't have a reliable BZ<->Fedora mapping, so we should be aware that the BZ check may not catch everyone who is "active"

I've recently modified the script to search for {username}@fedoraproject.org also, as I noticed there are many users which are using that.
Those users for which the script cannot find a valid bz account will be marked with the line Unable to check user {username} activity in Bugzilla because I cannot find them.. See the most recent output log at https://mattia.fedorapeople.org/inactive-packagers/ (this is just a log, the actual output produced by the script is a csv file with the username and associated emails in it, I didn't published it in my fedorapeople space because of the email privacy).

• The simplest way to keep state is to leave their tickets open until the expiration period, which could make it harder to find issues in FESCo's queue. Using a separate, dedicated repo for this may be a better option, especially since the process as proposed doesn't require FESCo to act.
  

A separate repo would be better, consider that the first run will open over 500 tickets (again, see the most recent output log).

I plan to have the script automatically open the ticket against inactive packagers using pagure APIs, but it could take a while because I'm now having some family problems.

A separate repo would be better, consider that the first run will open over 500 tickets (again, see the most recent output log).

We can use https://pagure.io/find-inactive-packagers

A few grammar suggestions:

"Remove the user to any package where they're the main admin or co-maintainer or collaborator." should be "Remove the user from any package where they're the main admin, co-maintainer, or collaborator."

"Such users are not required to follow again the steps for being sponsored in the packager group." reads better as "Such users are not required to repeat the steps for being sponsored in the packager group."

+1 from me, FWIW.

+1 too

link:https://pagure.io/fesco/new_issue/[packager-sponsors]

The title here is wrong. But I think we should use a different repo. Let's maybe create a separate repo just for those tickets, I don't think we want to spam any existing repo with hundreds of tickets.

Shouldn't this be somehow linked with https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/#_maintaining_provenpackager_status ?

A few grammar suggestions:

"Remove the user to any package where they're the main admin or co-maintainer or collaborator." should be "Remove the user from any package where they're the main admin, co-maintainer, or collaborator."

"Such users are not required to follow again the steps for being sponsored in the packager group." reads better as "Such users are not required to repeat the steps for being sponsored in the packager group."

Changes applied to the PR.

Shouldn't this be somehow linked with https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/#_maintaining_provenpackager_status ?

I think it's fine if we first merge this, and then add links/redirects in other places as appropriate.

link:https://pagure.io/fesco/new_issue/[packager-sponsors]

The title here is wrong. But I think we should use a different repo. Let's maybe create a separate repo just for those tickets, I don't think we want to spam any existing repo with hundreds of tickets.

I've corrected the link to point to the packager-sponsors repo.

The "hundred of tickets" opened by the automated script will not be filed in that repo. I've currently set my script to open such tickets in its own code repo, but that's fully customizable in the script settings (or by env variable). You can find some tests I made in https://pagure.io/find-inactive-packagers-test/issues

I still maintain that we need to be more explicit about who the actor is here. The script doesn't magically run itself. I recall in a previous meeting being told it would be my (as Fedora Program Manager) responsibility, so I think that should be clearly stated.

And as the person who will apparently be responsible for this, the "every two months" timing doesn't fit well in how my work goes. Picking a few points on the release schedule for this would make it much more likely to actually get done, particularly at some point when I hand the reigns over to the next FPgM.

In addition to what @bcotton noted, I think we should not do any inactive marking right before or during release freezes. This could disrupt the release by someone being marked inactive and a scramble to see who can take it on and fix things. Also, perhaps this should be coordinated with the orphan packages/retirement cycle? ie, mark inactive and orphan packages at the start of that cycle?

From the FESCo meeting:
bcotton> I was thinking maybe 1 week after final release and 1 week before beta freeze as a starting point. that gives us 4x a year somewhat spaced out and FTI retirement is a week before the start of beta freeze

Also:
bcotton> the proposal as written is 6, so that seemed like a fair compromise. i'd be fine with 2
bcotton> so yeah, i'd be happy to have it happen alongside the provenpackager check

For reference, the provenpackager check begins the day after branch: https://fedorapeople.org/groups/schedule/f-37/f-37-pm-tasks.html

So, sorry for not being able to attend to the meeting... I've read the meeting logs on meetbot and the comments here, there's still one thing it's not clear to me:

bcotton> I was thinking maybe 1 week after final release and 1 week before beta freeze as a starting point.

Do you mean making the first run of the script 1 week after final release to open tickets against packagers and then do a second run 1 week before beta freeze to detect what users to remove from the packagers group? That's sound in contrast to:

kevin> In addition to what bcotton noted, I think we should not do any inactive marking right before or during release freezes

What about making the first run of the script 1 week before beta freeze and the second run 1 week after final release? Could that be a too short grace period?

Do you mean making the first run of the script 1 week after final release to open tickets against packagers and then do a second run 1 week before beta freeze to detect what users to remove from the packagers group?

No, I mean as that as the two points in the release cycle where inactive packagers are removed. I'm fine with once per cycle, but I offered twice as a compromise from the original proposal which would (essentially) have been 3x per cycle. I was only thinking about the point at which we remove people, not the length of the process.

What about making the first run of the script 1 week before beta freeze and the second run 1 week after final release? Could that be a too short grace period?

That would be about two months apart, which I think is a totally fine (and longer than strictly necessary grace period).

The first run to identify possible removals can happen during freezes, as far as I'm concerned, since it doesn't involve making any changes.

@bcotton I think it's better if you say me your preference about when the two steps should be performed.
I've already updated the proposal with 'first run 1 week before beta freeze and second run 1 week after final release', but I can change it again to match the two steps with the inactive provenpackagers removal ('first step the day after branched and second step two weeks later') if better fits the schedule.

@bcotton I think it's better if you say me your preference about when the two steps should be performed.
I've already updated the proposal with 'first run 1 week before beta freeze and second run 1 week after final release', but I can change it again to match the two steps with the inactive provenpackagers removal ('first step the day after branched and second step two weeks later') if better fits the schedule.

I don't have a preference apart from it being tied to predictable points in the release schedule and not performing the removal between beta freeze and final release.

A few nit-picks for clarity and readability:

In the future, this policy may consider users with 2FA enabled onto their account from being exempted
by the periodic check. Packagers are therefore encouraged to enable 2FA to secure their account.

This might be more clearly written as something like:

In a future version of this policy, users with 2FA enabled may become exempt from the periodic check.
Packagers are therefore encouraged to enable 2FA to secure their accounts.

In

A user that got removed from the packager group may return to Fedora after some time and want to re-gain
their packager status.

“Was removed” would be more idiomatic formal language than “got removed.” “Re-gain” would be better written “regain.”

In

Such users are not required to repeat the steps for being sponsored in the packager group. Providing that
they can prove their identity through other methods than the email used in their account, they can open a
ticket in the link:https://pagure.io/packager-sponsors/new_issue/[packager-sponsors] tracker asking for
their identity to be confirmed and ask their status to be restored.

“Providing” should be “Provided,” or it could simply be “If.”

The “ask” in the last line is superfluous, and the sentence has better parallel structure without it.

I have applied the suggested corrections above and rebased.

The policy was approved:
https://pagure.io/fesco/issue/2759

It looks like there were no objections to the corrections for the last-minute nit-picks, so I will push the "merge" button.