Add script for adding contributors

[mwcraig]

The intent of this is to semi-automate adding people who have had PRs merged in coordinated packages (or astropy core) added to the astropy organization so that coordinated package maintainers can assign them to issues, etc.

To do before merging:

• Add github token to this repo's secrets.
• Add logic to check whether person has an open invitation.
• Add logic to check for blocked users before sending invite (unless github already does that, not sure).

[astrofrog]

I haven't tried running this but just in case it's slow to get the list of PRs and people, you should be able to use GraphQL to get this very quickly - see the first pr_consistency script for an example. That can get info for all PRs in tens of seconds.

[mwcraig]

Add limit of number of repeated invites

[mwcraig]

@eteq @hamogu @adrn -- this is ready for a look and merge if you think it looks good. Note that merging WILL NOT TRIGGER INVITES because the action runs the script with the --dry-run option.

Merging it will allow for further error checking.

Let me know if you want it in a folder of its own so the top level isn't so cluttered.

[adrn]

Just a few minor suggestions, otherwise this looks good!

[adrn]

I just had dependabot update these in a bunch of my own repos, so might as well use the latest version?

Suggested change

	- uses: actions/checkout@v2
	- uses: actions/setup-python@v2
	- uses: actions/checkout@v3
	- uses: actions/setup-python@v3

[adrn]

Did you want to print or raise an exception or return here?

[eteq]

One minor change to suggest , but overall LGTM.

One thing that certainly doesn't need dealing with now but might once we go out of "dry-run" mode: it might be better if the package repos themselves could have the information on their policies, instead of it living in the json file here. That way the individual repo maintainers can keep track of it themselves with their own write powers instead of depending on PRs here.

[adrn]

BTW, I think this is relevant to: astropy/astropy-project#160

[mwcraig]

BTW, I think this is relevant to: astropy/astropy-project#160

It probably requires similar token scope but is checking something a little different. Definitely could be part of a package of regularly-run jobs to handle these sorts of membership things.

[pllim]

As discussed today (2022-04-07) during infrastructure tag-up (@eteq , @bsipocz , @saimn , @tomdonaldson, and myself), there needs to be a "paper trail" more permanent than GitHub Actions log. Perhaps when invitations are sent (or even follow-up actions), memo can be automatically posted over at Matrix (what Stuart would have wanted) or Slack. (I suggested GitHub issue but it was not accepted.)

Motivation of this "paper trail" is for accountability, in case something happens. Useful info would be "who got invited when for what" and so on.

Kudos on this PR to automate some of the policies!

[eteq]

Re: #166 (review) - just to give @mwcraig added context, if you'd rather get the "dry run" mode going now we could do that without what @pllim is saying just to gather data to be sure its behaving right, but I agree that we should address the "paper trail" item before we actually turn it on.

[mwcraig]

As discussed today (2022-04-07) during infrastructure tag-up (@eteq , @bsipocz , @saimn , @tomdonaldson, and myself), there needs to be a "paper trail" more permanent than GitHub Actions log.

I had a couple of thoughts about that.

Right now we have no paper trail at all of who has been invited -- someone emails the CoCo and we, without announcement, add the person.

Suggestions (thinking out loud here):

1. One thought, instead of coupling astropy-tools to slack is to add a page to astropy.org that dynamically generates the list of invites from the GitHub API, or otherwise leverage the API to get GitHub's record of invitations. That would require a token with admin privileges in the org, I think.
   Regardless of the details, leveraging the API to generate the paper trail seems like the way to go.

2. I suppose the paper trail could be as simple as a markdown file in this repo that the bot updates as it issues invitations.

3. If we want some sort of announcement, is to tie it to twitter or maybe facebook and post something like "Thanks to the excellent GitHub user USERNAME (REAL NAME) for making their first contribution to REPO!"
   That would create a sort-of record and serve the purpose of acknowledging new contributors.

I do think we could merge this as-is to see what happens

[mwcraig]

Merging so we can see what happens....opening an issue for remaining items, including paper trail.