Revoke commit bit after a year of inactivity

[aslakhellesoy]

From @mpkorstanje on the mailing list:

Aslak, could you modify the commit bit bot in such a way it revokes the commit bit after a year or so when it has gone unused. This should reduce some of the risks that happen when people fade away I think.

Any idea how to trigger that action?

[mpkorstanje]

On the mailing list you suggested something like this for the core team:

(We'll occasionally run git shortlog -n -s --since "1 year ago" to see who should be on the core team).

Can this be made to work for the commit bit? With perhaps a whitelist so you dont lock yourself out.

On Aug 16, 2017 9:28 PM, "Aslak Hellesøy" notifications@github.com wrote:

From @mpkorstanje https://github.com/mpkorstanje on the mailing list:

Aslak, could you modify the commit bit bot in such a way it revokes the commit bit after a year or so when it has gone unused. This should reduce some of the risks that happen when people fade away I think.

Any idea how to trigger that action?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cucumber/commitbit/issues/3, or mute the thread https://github.com/notifications/unsubscribe-auth/AGoAZ_xSl93RD2WHglaRgGIcMYO0stRfks5sY0LLgaJpZM4O5Xo3 .

[aslakhellesoy]

That command requires a working copy, and commitbit doesn't have that.

This is a pretty dumb service that receives a WebHook request from GitHub when a PR is merged, then makes some API calls to GitHub to add a user to a team.

The other problem, which I mentioned above, is triggering. How would you trigger the action tp remove someone?

[tsundberg]

Triggering need some kind of scheduled invocation. This may not be too easy to set up.

Could an alternative be to check the status after each PR is merged? PRs are merged rather frequently so this might be good enough.

[olleolleolle]

In the HowIs project I recently added a thing like Who Did New Commits During A Period using the Github API. I'll link to it.

[olleolleolle]

This class does it: https://github.com/how-is/how_is/blob/master/lib/how_is/contributions.rb - and something like it could be done. It's a bit intensive though, a year's worth of commits using the REST API.

Updated link: https://github.com/duckinator/inq/blob/main/lib/inq/sources/github/contributions.rb#L14

[aslakhellesoy]

Who did new commits during a period is also done with the git shortlog command above.

I don't understand why we'd need to remove people from the committers team after inactivity.

I only care about removing people from the core teams, and this can be done manually in 10 minutes once a quarter or so.

Enlighten me

[tsundberg]

I have been thinking a bit more and I think that this is one of those issues that have an academic interest, but isn't worth solving in the practical world. Those who have commit right but don't use it exists but since they don't use the opportunity to contribute they might have it or not. They are not contributing and therefore not creating any problems.

I vote for closing this issue with a "Let's wait and see if this really is necessary'.

(And now I'm looking at the close button, but I will not use it...)

[mpkorstanje]

I have seen it happen in some online communities. Accounts of older inactive admins are hacked, credentials stolen from elsewhere, ect and trolls trash the place in no time.

I am okay with dealing with this when it happens as it happens. As long as we are are aware.

[mattwynne]

I think we could do this with a GitHub Actions workflow:

• Iterate over the members of the @cucumber/committers team.
• Query for each member's latest contributions.
• Revoke access for anyone who has not contributed in over a year.
• Ideally, send them a polite message.

[pabender]

I think we could do this with a GitHub Actions workflow:

• Iterate over the members of the @cucumber/committers team.
• Query for each member's latest contributions.
• Revoke access for anyone who has not contributed in over a year.
• Ideally, send them a polite message.

Not contributed to this project, or not committed to any project?

My own contributions to this project tend to be sporadic at best due to other commitments ( and changing jobs has given me less time for extracurricular programming activities ).

[zdenek-jonas]

While I don't have the time to actively participate in the project right now, it doesn't mean I'm ignoring it completely.

The situation may change again in time. Is there a problem with that, that you need to remove people who are currently working on other open source projects?

[bv]

Same here, I am following the project anf not ignoring it, although have not contributed for quite a while.

[luke-hill]

I think people are missing the point of the commit-bit. It allows people to automatically merge.

When we revoke a commit-bit, we're not preventing people from contributing. Just they won't be treated as a regular contributor, so they will need to get people to review and approve their PR (As you'd expect with any normal OSS project)

[zdenek-jonas]

Okay, I would never merge anything without someone else checking anyway.

[eduardrudko]

How about to have a seperate team with restricted privileges? I think it would be a shame to revoke access entirly from those who once contributed but stopped.

[mvz]

@eduardrudko what privileges do you have in mind that are not covered by just being a regular github user?

[eduardrudko]

@mvz for me contributing directly to the probject without havign to fork it first is quite a privilege, even though i won't have a privilige to merge it without a need to approve, although i also would never merge it without a review.

[pabender]

I think people are missing the point of the commit-bit. It allows people to automatically merge.

as in merge without a PR or merge a PR without approval from others?

IMO either of those cases is a dangerous practice in any project with more than one contributor.

[mvz]

@eduardrudko thanks for clarifying!

[qvdk]

@mvz for me contributing directly to the probject without havign to fork it first is quite a privilege, even though i won't have a privilige to merge it without a need to approve, although i also would never merge it without a review.

Even I am agree, some part of the project are too few contributors to do that. This is the case for @cucumber/cucumber-eclipse project where you are 2 peoples (@laeubi and me), with few activities currently.

[richardxia]

As someone who submitted just one PR to Cucumber (aruba.git) years ago and got added to the committers team, I would be fine with losing commit access, since if I ever needed to submit another PR, I could easily do it from a fork. While I think it's great to be welcoming of new contributors, my own situation was much more pragmatic, as my PR was to fix a minor bug that I was hitting in aruba, and I did not have any intent to make contribute in an ongoing basis.

[gurjeet]

I'm in the same boat as Richard Xia here. In fact, I was surprised to see a project give me a commit bit after my first contribution was accepted; it did feel nice to have that privilege, though.

I wouldn't mind giving up the commit bit at all since losing it won't affect my quality of life even a bit ;-)

Best regards,

Gurjeet Singh http://gurjeet.singh.im/

On Fri, Jul 16, 2021 at 9:22 AM Richard Xia @.***> wrote:

As someone who submitted just one PR to Cucumber (aruba.git) years ago and got added to the committers team, I would be fine with losing commit access, since if I ever needed to submit another PR, I could easily do it from a fork. While I think it's great to be welcoming of new contributors, my own situation was much more pragmatic, as my PR was to fix a minor bug that I was hitting in aruba, and I did not have any intent to make contribute in an ongoing basis.

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/cucumber/commitbit/issues/3#issuecomment-881567297, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABG2666B3OVNUCZWVICO4TTYBMDHANCNFSM4DXFPI3Q .

[aslakhellesoy]

I think we should decommission this bot and adopt the following two bots instead:

• https://probot.github.io/apps/invite-contributors/
• https://github.com/apps/welcome (alternatively https://github.com/hoodiehq/first-timers-bot)

There doesn't seem to be any bots that remove a contributor fro an organisation after inactivity. I'd suggest implementing this as a new probot.

[aurelien-reeves]

I think we should decommission this bot and adopt the following two bots instead:

* https://probot.github.io/apps/invite-contributors/

* https://github.com/apps/welcome (alternatively https://github.com/hoodiehq/first-timers-bot)

There doesn't seem to be any bots that remove a contributor fro an organisation after inactivity. I'd suggest implementing this as a new probot.

The first timer bot is great! I would definitely suggest to install that one!

[mattwynne]

I agree Aslak. I'm not sure Hoodie's first-timers bot is quite what we need, for this particular problem, is it? If I understand correctly it's for automatically creating an issues to help first-timers. A great idea but not on-topic for this problem.

[jarl-dk]

Hi All

For me, it's a couple of years since my active contributions to cucumber. I am such a fan of BDD and has introduced it to many organisation. Even though it is some time ago I was maintainer of aruba, I am actually quite prod of my core committer membership. I would be sad to see the nice green cucumber logo disappear from my github account. :-(

Regards, Jarl

Den man. 19. jul. 2021 kl. 20.21 skrev Matt Wynne @.***

:

I agree Aslak. I'm not sure Hoodie's first-timers bot is quite what we need, for this particular problem, is it? If I understand correctly it's for automatically creating an issues to help first-timers. A great idea but not on-topic for this problem.

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/cucumber/commitbit/issues/3#issuecomment-882760978, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABOYIIRCGNXXYNDQXZ7E6LTYRUL7ANCNFSM4DXFPI3Q .

-- Jarl Friis Softace ApS Rådhustorvet 7, 2. 3520 Farum +45 26132090 LinkedIn: http://dk.linkedin.com/in/jarlfriis

[mattwynne]

I hear you @jarl-dk!

What about if we made a separate @cucumber/alumni team and move people over into that when they haven't contributed in a while?

[dkowis]

I certainly don't need commit access any more, it's been a long, long time since I've been a contributor in any concrete way.

Alumni suits me just fine :)

[jarl-dk]

Hi Matt

Sorry for the late answer. I would of course prefer to be a member of the core cucumber team :-) But I do also understand and respect the need to separate current active developers from former contributors. So making a separate alumni team seems like a reasonable compromise.

Jarl

Den fre. 6. aug. 2021 kl. 21.54 skrev Matt Wynne @.***>:

I hear you @jarl-dk https://github.com/jarl-dk!

What about if we made a separate @cucumber/alumni team and move people over into that when they haven't contributed in a while?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cucumber/commitbit/issues/3#issuecomment-894485812, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABOYIKC64JOMIVVIVS5QXDT3Q4XNANCNFSM4DXFPI3Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

-- Jarl Friis Softace ApS Rådhustorvet 7, 2. 3520 Farum +45 26132090 LinkedIn: http://dk.linkedin.com/in/jarlfriis

[mattwynne]

I've started digging into this work with the new contributors ensemble. We ran an example mapping session today. I'm hoping to start work on the scenarios next week.

I'm not sure yet whether to implement it in this codebase or as a stand-alone github action / bot.

[mattwynne]

I'm not sure yet whether to implement it in this codebase or as a stand-alone github action.

Given Aslak's comment here maybe we should implement this as a new probot.