Automatically move inactive contributors to an alumni team

[gr2m]

Every collaborator on a team with write access is a potential risk. As collaborators become inactive they could be moved to an alumni group with read-access only. That would also help the maintainers to keep an oversight of the amount of active contributors a community has

[anshumanv]

Seems interesting @gr2m, I'll update as I make progress.

[anshumanv]

What would be the ideal time to move the collabs in the alimni group? 15 days sounds legit?
And are we defining inactive as no reviews, merges, commits? Or is there anything else that I'm missing here.

[gr2m]

ideal time to move the collabs in the alimni group

I would give it more time by default, maybe 2 or 3 months. In Open Source, things move slow some time, and that's okay :) We can make the time configurable over time.

And are we defining inactive as no reviews, merges, commits

Anything :) We can start out with just commits because it might be the easiest. It will be enough to build a first version, and then we can iterate from there?

[j-f1]

15 days sounds legit?

I’d say a month or so — people might take (OSS or real-life) vacations and stop contributing for a while, then return to contributing later on. How about a configuration option?

[anshumanv]

Makes sense @gr2m @j-f1
Configuration can be most suitable here, which can be set considering the activity in the project. 😄
I'll lookup things and update/query as I encounter something. 👍

[gr2m]

awesome :) yeah configuration would be great, but okay to start out without it if that makes it simpler for you :)

[anshumanv]

@gr2m Cool, can you perhaps brief me with the requirements for this?
Like what is the expected outcome, and what I'm expected to do?
What I've picked up so far is that-

• I've to understand probot well.
• Then get started by building a probot app for this issue(is it?).

Can you please add any needful points which I'm missing out. 😄

[anshumanv]

cc @bkeepers @j-f1

[gr2m]

@anshumanv we will add more details today, sorry for the delay.

One thing that will be challenging is how to store the authentication token for twitter in the probot app. Ideally we would avoid to depend on a database and instead store the keys in a secure way in the repository.

To get started, I'd suggest you follow the guide to create the hello world application and deploy it to something like glitch.com so that you can install it on a test repository :)

[anshumanv]

@anshumanv we will add more details today, sorry for the delay.

Ah, it's all cool, I'm having fun exploring the docs, experimenting, and seeing the awesome apps that the community has build. 😄

One thing that will be challenging is how to store the authentication token for twitter in the probot app.

I don't seem to get the use-case of twitter authentication? Are we tracking whether the collab. is inactive on social media as well?

To get started, I'd suggest you follow the guide to create the hello world application and deploy it to something like glitch.com so that you can install it on a test repository :)

Sure cool, on it infact, it's so amazing to see that bots can be built in so few lines. :)

One more doubt I had is whether the only task for the entire SoC would be to build a single probot app?

Appreciate the help @gr2m 😄

[j-f1]

The bot could store an encryption key, then provide a web interface for the user to paste their API token into and get the encrypted version. This could be safely stored in the repository and decrypted by the bot as needed (see Travis CI for an example of this)

[JasonEtco]

One more doubt I had is whether the only task for the entire SoC would be to build a single probot app?

@anshumanv Depending on the complexity of the app, it could definitely take that long (or longer). The ideas that we've suggested in this repo are open to interpretation, and in your application we are 100% open to other app ideas (even more ambitious ones)! Or, the project could be a suite of interconnected Probot Apps (like Behaviorbot).

If you have another idea, I'm happy to chat about it with you in Slack 😄

[anshumanv]

Thanks so much all for being so flexible, I'll surely reach out for any ideas/suggestions.
btw behaviorbot is amazing. 😄

[gr2m]

I don't seem to get the use-case of twitter authentication? Are we tracking whether the collab. is inactive on social media as well?

oh my nevermind me, that comment was meant for #32, sorry sorry

[goelrohan6]

Can someone help me getting started, how do I approach the problem, what are the prerequisites?

[ashifa454]

Seems Pretty Interesting, will there be an option to active contributors to invite alumni to back if he wants to contribute again. @gr2m

[ashifa454]

and a config file would be a good option to manage things like the MAX time without activity, marks some contributors to alumni from the day of setup.

[anshumanv]

Yes, certainly I like the idea of the config file to set preferences. 👍

Seems Pretty Interesting, will there be an option to active contributors to invite alumni to back if he wants to contribute again.

We can just invite anyone in the alumni team back to the collab team once they show any activity?

[ashifa454]

Or just to make it more systematic, we can simply add MIN number of Push Required to come back again in collab team, so in that sense, config file would be a centralized configuration area to /PER repo.

[anshumanv]

Yeah makes sense.

[gr2m]

Seems Pretty Interesting, will there be an option to active contributors to invite alumni to back if he wants to contribute again

side note: better to say "... if they want to contribute again" as we can't assume gender ;)

That is a good question. Moving inactive users into an "alumni" group that has only read access has also a security implication: if their account ever gets hacked, they can't do much harm without write access, and the amount of GitHub accounts with write access will get reduced a lot with this bot. So I would not move them back to a team with write access automatically, at least not by default, but make that configurable?

Either way is fine to start out with though, I think that is something that will show its usefulness once more folks use it :)

[anshumanv]

So I would not move them back to a team with write access automatically, at least not by default, but make that configurable?

Either way is fine to start out with though, I think that is something that will show its usefulness once more folks use it :)

Agreed, I'll keep these points in mind.

[ashifa454]

Just to Move it Forward, what I can draw from last few messages create-probot-app will add new entries in the .env file in the environment for the following variable with default entries

1. MAX_TIME_WITHOUT_COTRIBUTION (MAX Number of Days an active contributor can be collaborator without collaborating)
2. INITIAL_ALUMNI (IF I want to mark some users to be alumni from the day of installation)
3. EVENTS_TO_BE_CONTRIBUTOR (Hooks That should be considered for the collaboration)
4. MIN_PUSH_REQ_TO_CONTRIBUTOR (MIN number of push alumni need to become an active collaborator)
   I also don't agree with the idea of automatically adding alumni to active collab, what we can do we can notify active members when alumni is ready to be added to collab team.