The Fedora Ambassadors group has an action which if a member does not fulfill certain tasks within a period of time (), the users' global account is set to inactive. This came up as a Fedora Infrastructure ticket https://pagure.io/fedora-infrastructure/issue/5995 where Patrick and I were reticent to set these accounts to inactive without clear approval. [The fact that no other group one belongs to in Fedora has this global affecting policy does make it stand out for needing extra approval. It might be that this is wanted/needed by other groups or that many people feel it is not wanted and don't know that a group has this 'power'.]
Setting a Fedora account to inactive is in many ways the same as disabling it. The user loses access to things they may have had before it was set to inactive and they lose access to email aliases and OpenID. On the other hand, not being active in the process has led to a large number of accounts in the Fedora Account System which are most likely dead.
In order to look at closing accounts for multiple reasons I would like to ask the Council for guidance on what they feel is allowable, who should be able to exercise that power, and what steps should be done to keep that power in check.
It sounds like we have two challenges here:
The Ambassadors need to figure out how to manage their listings without having an account be inactive. I believe they have a FAS group they can use. I'd like to have them point us to the documentation for why someone who is no longer an ambassador shouldn't be removed from the active ambassadors group. I believe nothing is stopping them from keeping a list of alumni ambassadors in the wiki or creating a second FAS group.
So in this regards, I support the idea that a single group shouldn't be allowed to decide if a FAS ID should be marked inactive or not.
However, I believe we need clear guidance on what causes an ID to get marked inactive. Looking at https://pagure.io/fedora-infrastructure/issue/5995#comment-437107 it appears that some accounts were marked inactive, but the rationale felt very adhoc based on the wording.
What is our official policy on when an account is considered inactive? If we don't have one, should we?
The fact that no other group one belongs to in Fedora has this global affecting policy does make it stand out for needing extra approval.
Well, the infrastructure group has this power and as used it in times of, for example, ssh key change or password change.
The user loses access to things they may have had before it was set to inactive and they lose access to email aliases and OpenID.
True for the email alias, but the OpenID queries FAS and updates there the last_seen field that the script ran by the ambassador checks. I think the alias would be the only thing they loose that they may be using frequently. They do loose the OpenID but that also means they are not using it frequently since using it is a criteria to be deemed active or not.
I believe the only policies we have around this is the one from the ambassador and the non-responding packager procedure which ends up with the account being disabled (as well) and the packages orphaned and offered to the community.
What is our official policy on when an account is considered inactive? If we don't have one, should we? I believe the only policies we have around this is the one from the ambassador and the non-responding packager procedure which ends up with the account being disabled (as well) and the packages orphaned and offered to the community.
Sounds like we should have a policy both from a security perspective and to prevent arbitrary reactions.
I can't find this in the nonresponsive packager policy? As far as I know, we purely remove their pkgdb ACLs for that.
Hm, you may be right, we may just remove the ACLs in pkgdb. Sorry for introducing a confusion there
Just for resuming where this comes from:
I am personally fine if we set up an overall rule, or we decide to not set accounts as inactive just because a sub-group has this rule. I am still convinced that people who are not logged into any Fedora system or ML or whatever for more than 18 months should get removed from the ambassadors FAS group, as ambassadors give voice to Fedora and need to be up to date.
Edit: oh, wow, so many replies while writing this. Sorry if I repeated some things here.
My personal opinion would be to not allow subteams of Fedora other than Council (or delegates) , Legal or Infrastructure request for accounts to be deactivated/disabled, and those teams need strong incentives for doing so.
From Infrastructure, the only times I'm aware of we deactivated accounts are: - Spam accounts (these are actually given an specific state) - When we moved to a new password hashing system, to force password reset - Individual accounts when any of their private keys or passwords leak to prevent abuse - Accounts with inadequate passwords
From Legal, I think the only request I'm aware of was when we moved from CLA to FPCA, blocking not yet merged users (because of the CLA no longer being active).
Deactivating dormant accounts after some predefined inactivity time (which should be agreed upon project-wide or by council) is tricky in my mind, since people might get back and then no longer have their email address but still have the password. I am not entirely opposed to this, my concerns were mostly related to the fact that one subteam decided on the inactivity times without project-wide agreement.
When FAmSCo years ago came up with this clean-up process, we discussed this publicly in the ML, and there were strong opinions of many ambassadors to NOT remove anyone from the FAS group just for inactivity. FAmSCo's thought for FAS group removal was based on the second rule we have (which apparently is not working): "ambassadors who are inactive for more than 6 months will be removed automatically from the FAS group". So, after 2 years of inactivity, people will be removed from the FAS group.
Based on these two statements it sounds like revisiting the group membership issue is a worthwhile thing to do. I think it is a reasonable request to ambassadors for them to have to manage their activity lists either manually or through a FAS group.
I am personally fine if we set up an overall rule, or we decide to not set accounts as inactive just because a sub-group has this rule. I am still convinced that people who are not logged into any Fedora system or ML or whatever for more than 18 months should get removed from the ambassadors FAS group, as ambassadors give voice to Fedora and need to be up to date. Edit: oh, wow, so many replies while writing this. Sorry if I repeated some things here.
I strongly believe we need an account inactivity rule. I also don't believe we should ask FAmSCo to come up with it.
I'll toss out a rough proposal:
After 9 months of no measurable fedmesg activity an account is set inactive. This causes the following changes: X, Y, Z. Accounts can be re-enabled by the user by following the procedure, P, Q, R.
After 9 months of being inactive an account is set to XXX status. This results in the following additional changes. To re-enable this account a user must request the account be reactivated via this procedure: A, B, C.
I strongly believe we need an account inactivity rule. I also don't believe we should ask FAmSCo to come up with it. I'll toss out a rough proposal: After 9 months of no measurable fedmesg activity an account is set inactive. This causes the following changes: X, Y, Z. Accounts can be re-enabled by the user by following the procedure, P, Q, R. After 9 months of being inactive an account is set to XXX status. This results in the following additional changes. To re-enable this account a user must request the account be reactivated via this procedure: A, B, C.
Well, one problem that @smooge pointed out is the use of the email alias. The alias gets removed once the user is no longer active, and we do not track emails going to these aliases (nor do I think we should).
Edit: correctly attribute.
(It's @smooge that pointed it out first ;-))
Just a small remark on the present proposal: there is no step 2. Once the account is marked as inactive there is no extra step.
People can reactivate their account just by going to the accounts page and setting the flag to "active". No requests are needed.
But will I loose my email alias immediately when dropping the active flag or how does this happen? (sorry for the silly question)
After 9 months of being inactive an account is set to XXX status. This results in the following additional changes. To re-enable this account a user must request the account be reactivated via this procedure: A, B, C. People can reactivate their account just by going to the accounts page and setting the flag to "active". No requests are needed.
... so long as they still have access to their email address, since for reactivating they need to use "forgot password". Which is one of the main issues I have with a policy like this: when people get back after a long time, their old email address might no longer work, and they're locked out forever (most of the older accounts we're asked to recover have no GPG or SSH key they still have or a security question).
The alias gets removed once the user is no longer active, and we do not track emails going to these aliases (nor do I think we should).
I am not sure I understand the problem here. Is the problem that the person's @fp.o alias will stop working? or is the problem that we create a mail loop or something similar?
I thought everyone had to have a non-@fp.o email address in their profile if they had an @fp.o alias. Therefore, if the problem is that someone's @fp.o alias stops working then I am OK with that. As long as we give notice (say 30 days) before marking them inactive, they have enough time to login to the system and cancel the impending action of being marked inactive.
I do not believe we should block on this, if I am understanding this correctly.
Nice!
After 9 months of being inactive an account is set to XXX status. This results in the following additional changes. To re-enable this account a user must request the account be reactivated via this procedure: A, B, C. People can reactivate their account just by going to the accounts page and setting the flag to "active". No requests are needed. ... so long as they still have access to their email address, since for reactivating they need to use "forgot password". Which is one of the main issues I have with a policy like this: when people get back after a long time, their old email address might no longer work, and they're locked out forever (most of the older accounts we're asked to recover have no GPG or SSH key they still have or a security question).
Do we still allow accounts to be created with no GPG or SSH key and no security question? If so, can we stop that?
For older accounts, can we audit them and send an email that says "do one of these three things to ensure that your account can be recovered."
Basically, I'd rather not block on a problem that is going to be faced by only the (I hope) small subset of users who are:
This also presumes that in these rare cases we can't use some other form of validation on these people.
I meant that their @fp.o alias stops working.
..snip.. I do not believe we should block on this, if I am understanding this correctly.
Not sure, but it does make detecting account inactivity harder.
Yes we do, and no I don't think we should stop it. A lot of contributors have no clue at all what a GPG key or SSH key is. Requiring a security question is more reasonable in my mind.
For older accounts, can we audit them and send an email that says "do one of these three things to ensure that your account can be recovered." Basically, I'd rather not block on a problem that is going to be faced by only the (I hope) small subset of users who are: Active today Ignore the request to set a GPG key, SSH key, or security question Disappear with no activity for 9 or more months Show up at some point down the road and can't reactive their old account.
For older accounts, can we audit them and send an email that says "do one of these three things to ensure that your account can be recovered." Basically, I'd rather not block on a problem that is going to be faced by only the (I hope) small subset of users who are:
Active today Ignore the request to set a GPG key, SSH key, or security question Disappear with no activity for 9 or more months Show up at some point down the road and can't reactive their old account.
This set of users is bigger than you might think. We get requests like these on average once a month I guess. (source: none, my memory).
Which holds true in 99% of the cases I've seen so far.
How? I am not of the opinion that merely receiving an email on an @fp.o email address indicates someone is an active contributor. They could just be a living spam honeypot :)
Do we still allow accounts to be created with no GPG or SSH key and no security question? If so, can we stop that? Yes we do, and no I don't think we should stop it. A lot of contributors have no clue at all what a GPG key or SSH key is. Requiring a security question is more reasonable in my mind.
I tried to imply that we should require at least one of the three. I actually agree with you fully that we should just require the security question, but I can see where some of our contributors may be upset by that. By requiring at least one of the three and suggesting security question as being the "easiest" we've covered the situation.
For older accounts, can we audit them and send an email that says "do one of these three things to ensure that your account can be recovered." Basically, I'd rather not block on a problem that is going to be faced by only the (I hope) small subset of users who are: Active today Ignore the request to set a GPG key, SSH key, or security question Disappear with no activity for 9 or more months Show up at some point down the road and can't reactive their old account. This set of users is bigger than you might think. We get requests like these on average once a month I guess. (source: none, my memory).
And what do you do with them? Also, how are we getting these requests at all if we aren't setting accounts inactive because we have no policy to do that.
This also presumes that in these rare cases we can't use some other form of validation on these people. Which holds true in 99% of the cases I've seen so far.
Then how are you validating them?
Not sure, but it does make detecting account inactivity harder. How? I am not of the opinion that merely receiving an email on an @fp.o email address indicates someone is an active contributor. They could just be a living spam honeypot :)
The fact they don't do any activities directly in fedoraproject.org doesn't say they're not active. People might be very active on github.com/fedora-infra and have a different username there than they have in FAS. In my mind, that still makes them contributors.
The same with infrastructure: ssh'ing into servers doesn't give you anything. Doesn't mean you didn't do anything.
I am an active Red Hat employee, but if you look in 99% of the internal systems, you won't see any activity from me.
Not sure, but it does make detecting account inactivity harder. How? I am not of the opinion that merely receiving an email on an @fp.o email address indicates someone is an active contributor. They could just be a living spam honeypot :) The fact they don't do any activities directly in fedoraproject.org doesn't say they're not active. People might be very active on github.com/fedora-infra and have a different username there than they have in FAS. In my mind, that still makes them contributors. The same with infrastructure: ssh'ing into servers doesn't give you anything. Doesn't mean you didn't do anything. I am an active Red Hat employee, but if you look in 99% of the internal systems, you won't see any activity from me.
The fact they don't do any activities directly in fedoraproject.org doesn't say they're not active. People might be very active on github.com/fedora-infra and have a different username there than they have in FAS. In my mind, that still makes them contributors. The same with infrastructure: ssh'ing into servers doesn't give you anything. Doesn't mean you didn't do anything. I am an active Red Hat employee, but if you look in 99% of the internal systems, you won't see any activity from me.
100% of this is true. I also feel it is not an extreme burden to ask someone to react to an email every 8 months that says, please log in so we get a fedmesg activity from you to prove you're still active. There is literally no other required action.
This is precisely what the ambassador group has been doing. They run a script querying FAS and fedmsg, send an email, wait for two weeks, then ask the infrastructure team to mark the account as inactive.
Fair enough.
I meant to imply that we have users that get themselves locked out. Some of those can recover if we just tell them their username because they remember their password (I am betting those are using the same password everywhere, unless they use some smarter things like pwdhash). I meant to imply there's a chance there's further people that don't need to get to infrastructure because currently they can relogin on their own. Though admittedly we have no way of tracking this.
This also presumes that in these rare cases we can't use some other form of validation on these people. Which holds true in 99% of the cases I've seen so far. Then how are you validating them?
We don't. Those accounts will remain dormant possibly forever, because they'll need to create new ones. (Assuming that the person trying to "recover" wasn't an imposter, and the original owner still has access to the account obviously.)
Except that the waiting time is not always long enough. Proof: look in the ticket at the start of this conversation: one account was used a day after the request to infrastructure was put in.
100% of this is true. I also feel it is not an extreme burden to ask someone to react to an email every 8 months that says, please log in so we get a fedmesg activity from you to prove you're still active. There is literally no other required action. This is precisely what the ambassador group has been doing. They run a script querying FAS and fedmsg, send an email, wait for two weeks, then ask the infrastructure team to mark the account as inactive.
Yes. However, this is not something FAmSCo should be driving, or at least that is the request that was put forward when this ticket was opened. I am proposing a Project wide policy.
Correct (was writing the same).
Proof: look in the ticket at the start of this conversation: one account was used a day after the request to infrastructure was put in
One could argue that there will always be someone acting just after the deadline :) It's like being caught by the police for speeding 1km/h over the speed limit :D
This is precisely what the ambassador group has been doing. They run a script querying FAS and fedmsg, send an email, wait for two weeks, then ask the infrastructure team to mark the account as inactive. Except that that seemingly is not always long enough that they wait. Proof: look in the ticket at the start of this conversation: one account was used a day after the request to infrastructure was put in.
Except that that seemingly is not always long enough that they wait. Proof: look in the ticket at the start of this conversation: one account was used a day after the request to infrastructure was put in.
We could have one script that emails all accounts that had no activity in the last 8 months and said "do something or you go inactive." We can have another script that sets all accounts with no activity in the last 9 months inactive. Run them both on rand(days in month) every month and we have a solution. It stops the problem of making lists and then having to check them 800 times.
Sure. That message was meant to imply that the two weeks might not be long enough. Also, this is totally up to the person sending the email whether the person will see the reply, so the reply-to should probably be some list.
100% of this is true. I also feel it is not an extreme burden to ask someone to react to an email every 8 months that says, please log in so we get a fedmesg activity from you to prove you're still active. There is literally no other required action. This is precisely what the ambassador group has been doing. They run a script querying FAS and fedmsg, send an email, wait for two weeks, then ask the infrastructure team to mark the account as inactive. Yes. However, this is not something FAmSCo should be driving, or at least that is the request that was put forward when this ticket was opened. I am proposing a Project wide policy.
Agree. If we have a project-wide policy we can also drive these kind of prcesses more easily IMHO, for any group.
However, this is not something FAmSCo should be driving, or at least that is the request that was put forward when this ticket was opened. I am proposing a Project wide policy.
Well, they drive it for the part of the community they drive. I am not entirely sure to get the benefit of a project-wide policy. Better stats maybe? Seems poor.
I am not sure we should block on the fear of more work. If it turns out this creates a lot of work we would need to re-evaluate. Because that indicates we some very unique contribution patterns for a lot of users. I see this as an opportunity to bring this to light.
However, this is not something FAmSCo should be driving, or at least that is the request that was put forward when this ticket was opened. I am proposing a Project wide policy. Well, they drive it for the part of the community they drive. I am not entirely sure to get the benefit of a project-wide policy. Better stats maybe? Seems poor.
What we get is consistency. We also give FAmSCo (and other groups) the ability to focus on their areas without having to drive this for the project.
Also, this is totally up to the person sending the email whether the person will see the reply, so the reply-to should probably be some list.
Nobody has to reply. The users get asked in the email to log into their account to avoid being set as inactive. FAmSCo don't want people to reply to that mail, as it would not resolve anything.
Also, this is totally up to the person sending the email whether the person will see the reply, so the reply-to should probably be some list. Nobody has to reply. The users get asked in the email to log into their account to avoid being set as inactive. FAmSCo don't want people to reply to that mail, as it would not resolve anything.
+1 a reply to the email is actually the kind of behavior we don't want :)
However, this is not something FAmSCo should be driving, or at least that is the request that was put forward when this ticket was opened. I am proposing a Project wide policy. Well, they drive it for the part of the community they drive. I am not entirely sure to get the benefit of a project-wide policy. Better stats maybe? Seems poor. What we get is consistency. We also give FAmSCo (and other groups) the ability to focus on their areas without having to drive this for the project.
Yes, we would get consistency and power. FAmSCo could easily rely on a project wide decision and it would be easier also to remove FAS memberships. The main question remains: We have a rule to set inactive people's account as inactive. I don't see the email alias issue as a real problem, and I also believe setting users' IDs to inactive after 1 and a half year of any fedmsg activity is justified. However I am in favor of having a council driven decision on that if Infra raises so many concerns. We should think more about the problems we have if we list inactive people as active ambassadors on the wiki or get fund requests from those people for events or anything an ambassador is supposed to do, more than thinking just technically. Ambassadors do non technical work, and they are our main promoters between end users.
However I am in favor of having a council driven decision on that if Infra raises so many concerns. We should think more about the problems we have if we list inactive people as active ambassadors on the wiki or get fund requests from those people for events or anything an ambassador is supposed to do, more than thinking just technically. Ambassadors do non technical work, and they are our main promoters between end users.
I am still not convinced that Ambassadors has a clear reason for requesting account deactivation, given that their goals can be accomplished by removing someone from the group. And if the concern is "what about people that come back": just open a ticket for every user you remove from the group for record (or a mass ticket listing them), and if they come back, they can just point to it and ask to be re-added.
I would guess you'd want people that come back to ambassador-ship after a long absence would contact their mentor or someone else anyway, not?
(note that this opinion is not a blocker for the deactivation question in general, purely for the way that ambassadors use it)
I am still not convinced that Ambassadors has a clear reason for requesting account deactivation, given that their goals can be accomplished by removing someone from the group.
My read of this ticket is that everyone agrees with you. I see us discussing a possible project-wide policy.
And if the concern is "what about people that come back": just open a ticket for every user you remove from the group for record (or a mass ticket listing them), and if they come back, they can just point to it and ask to be re-added.
They should probably have a ticket that just lists who they removed every time they do the run. That way we have fewer tickets.
I would guess you'd want people that come back to ambassador-ship after a long absence would contact their mentor or someone else anyway, not? (note that this opinion is not a blocker for the deactivation question in general, purely for the way that ambassadors use it)
I look to FAmSCo to figure this out.
I am still not convinced that Ambassadors has a clear reason for requesting account deactivation, given that their goals can be accomplished by removing someone from the group. And if the concern is "what about people that come back": just open a ticket for every user you remove from the group for record (or a mass ticket listing them), and if they come back, they can just point to it and ask to be re-added. I would guess you'd want people that come back to ambassador-ship after a long absence would contact their mentor or someone else anyway, not? (note that this opinion is not a blocker for the deactivation question in general, purely for the way that ambassadors use it)
Yes that seems a viable solution to me. I'll bring this to FAmSCo to discuss a possible change of our policy. A project wide policy, if possible, is welcome though.
If the discussion goes to the project-wide level ... we might also want to differentiate between members having inactivity set by their own will and those who were made inactive because of lack of activity (or some kind of violation - like spam etc.). I basically have got inspiration from Debian's "emeritus" flag.
My main goal in opening this ticket is to make sure that we have a project wide policy. I don't want to start setting people inactive because any group asks Fedora Infrastructure to set someone inactive. While FAMSCo had many discussions about this and has a clean and reasonable policy on this, I am not in a position to have seen those discussions or know if that policy meets what the Council feels is reasonable. I also don't want to have to deal with getting requests from another group where the reason why someone is being set to inactive is a personal dispute but it is coloured by "they did not meet our policy" then pointing to the fact we followed FAMSCo's policy without question. [Bad past experiences at several places makes me realize this is inevitable.]
In the end, I just want to make sure that we have a clear policy before that happens and not during the :poop: storm. It would also help us deal with other problems like the fact that I closed 8,000+ spam accounts last year but I felt I had no clear authority to do so beyond "no one can work while this is going on". [And I know I closed some legitimate accounts accidentally and missed probably another 8,000 accounts we kept from spamming via other tools.]
FAmSCo worked on this policy change and we got it in by unanimity. Also, there were no concerns from the community, as we asked for feedback before applying the rule. See: https://pagure.io/famsco/issue/424 and: https://fedoraproject.org/wiki/Ambassadors/MembershipService#Inactive_Ambassadors
That means we don't have any rule in subgroups which disable FAS accounts in case of inactivity.
Metadata Update from @bex: - Issue assigned to bex
I am closing this ticket but would like to see someone champion a specific policy implementation draft in a new ticket. Please consider doing this.
Metadata Update from @bex: - Issue close_status updated to: no action needed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.