#4259 Create automated process to set Ambassadors accounts to inactive
Closed: Fixed None Opened 10 years ago by robyduck.

= Background analysis =

FAmSCo agreed to set Ambassadors accounts as inactive after a certain period of inactivity. The goal is to tag ambassadors as inactive after 18 months of complete inactivity. [[br]]
Inactive Ambassadors should also be notified about the change of their account status two weeks and 3 days before proceeding, to give them the chance to maintain their status as active.

= Implementation recommendation =

It's clear there is no chance to handle all the process automatically, but it would be nice to have at least the script/query running automatically with a cronjob. The more we can do automatically the better![[br]]
FAmSCo also agreed to run this query every 3 months, in order to be able to handle the rest of the process (mails, notifies or anything else needed) manually, only 4 times a year.

Accounts should be set as inactive and not removed, this means Ambassadors should be able to re-activate themselves in every moment.

FAmSCo also don't want to rely to much on Infra creating additional work, so I volunteer to help with the manual part in order to get this process happen.

== Possible solution ==

Pingou already run this script to retrieve all the people in the ambassador group using FAS and datagrepper to figure out the last time they have been active in the Fedora Infrastructure. [[br]]
http://ambre.pingoured.fr/cgit/fedautorebuild.git/tree/ambassadors_activity2.py


So, a few questions:

  • inactive here means no activity in fedmsg? Or that + other non fedmsg stuff too?

  • If you are wanting to run it every 3months it sounds like it doesn't actually need to be a cron or run in infrastructure? you could just run it manually when you wanted?

  • So it sounds like the only thing you need from us is the ability to mark a list of people inactive?

Replying to [comment:1 kevin]:

So, a few questions:

  • inactive here means no activity in fedmsg? Or that + other non fedmsg stuff too?

We want to set and identify them as inactive, this will be in fedmsg but also on FAS I guess. Other users should be able to understand that a certain ambassador is inactive.

  • If you are wanting to run it every 3months it sounds like it doesn't actually need to be a cron or run in infrastructure? you could just run it manually when you wanted?

Yes, sure. Question was more, is there any other idea than running it manually? I volunteered to run it 4 times a year (including notifies to the ambassadors who will be set as inactive), so running a script is not an effort.

  • So it sounds like the only thing you need from us is the ability to mark a list of people inactive?

Yes, and I'd add, setting them as inactive with a script (probably you already have one) could also be done manually by me (or any other volunteer in the future), in order to not create too much additional work for Infra. (perhaps just setting permissions)

Thank you.

If all the data you need to make the decision about if someone is inactive is available to the script, it could make this decision? Or you want a human to check it before any action(s) are taken?

The problem with allowing a script to set users inactive is that it's a security issue. If anyone could mark anyone inactive you could disrupt the project by marking people who need access inactive, etc. If we are running the script inside infrastructure we could run that script as a privleged user who can mark people inactive. However, that doesn't work if the script needs to be run manually.

So, I guess our options are:

  • Create the script to run inside infra with a priv user, but then there may not be a way to easily let you run it manually to do the inactives. I guess it could run from cron with a --dry-run and you could run it with sudo if you found all the actions valid.

  • Add something to FAS to allow specific users to mark others as inactive. This would need code in fas, but would allow you to run the scripts as you liked at home and run them as your user (or any of a group of users) to do the inactive.

Thoughts?

If I understood correctly the idea is to run the script, email the people that are potentially inactive and few weeks later, re-run the script and mark the people that did not re-login into FAS as inactive.

So to automate the process completely, it would need a database storing the user found as inactive per round, send the email, and at the re-run few weeks later finds out which are the user that were inactive X times ago and still are and mark these as inactive.

The current script clearly is not doing all this :)

Replying to [comment:3 kevin]:

If all the data you need to make the decision about if someone is inactive is available to the script, it could make this decision? Or you want a human to check it before any action(s) are taken?

The current idea is that we make a decision in the regional IRC meetings.

In the future, I would like something more automated, especially if we [http://blog.linuxgrrl.com/2014/04/01/a-proposal-for-fedoras-website-considering-fedora-next/ implement the latest proposals for the Fedora website] where you have FAS authenticate everything, even ask.fedoraproject.org, so we will have plenty of accounts and a githug like community. We will have way more users than today, not all are contributors in the traditional sense. When we lower the bar for for Fedora accounts, we also need an automated clean-up I think.

That means:
- people should only have a fedoraproject.org email when they are member of CLA+1
- cleanup script needs to be run automatically
- send reminders to people in question
- people should be marked inactive automatically
- as inactive is something different than deleted or whatever, this needs to be a new flag in FAS. We want people to easily join again when they want/have time etc.
- group members should only be marked inactive, but accounts without additional roles could be IHMO purged.

Anyway, all of this is outside the scope of this ticket I think. For now, let's start with the ambassadors and only partly automated. active/inactive will be decided by the participants of the regional meetings and their decision is implemented by [https://fedorahosted.org/fama/ FAMA].

well, I was trying to address this smaller scope, not open it up to all groups or whatever.

inactive is already a state a user account can be in. In order to move from inactive -> active you have to login and reset your password. So you need access to the email associated with the account.

We do not currently ever delete accounts. This is for a number of (IMHO good) reasons. If we did want to start doing that we would need to keep a lot more information in case we needed to see "which" user named something did some action.

Back to the question at hand. A first cut of this would be just to have you generate the list and send it to us in a ticket or whatever and we could mark all those people inactive. For more automated, see the ideas in comment#3

I think this could be ok to let the process start. The current script should be able to filter out the users who are inactive > x days, and we could notify these users with a mail that we are going to set them as inactive (manually).

After 2 weeks we need to run the script again, because someone would have done something, logging into FAS to avoid being set as inactive. Once we have this final list we can for sure pass this list to infra.

For a more automated process I'd prefer the second option, although it requires some FAS coding. This way way we don't need to nag the Infra team every 3 months to set people as inactive. Would this work for you?

Sounds Fine.

Shall we close this in favor of a ticket against fas to allow members of some group to be able to mark other people inactive? Would you like to file it, or shall I?

Yes that would be fine, could you file it against FAS?

In the meanwhile we will start to do these steps manually to see how it works and where we encounter issues in the process.

Thank you.

Feature added in upstream-side, will be part of next fas release 0.10.0.

Login to comment on this ticket.

Metadata