⚒️ Automate 'thanking' tracking

[tatianamac]

Overview

As we release new features, I manually go through and track who did it in order to thank them on our Twitter. It's a manual process which means that I sometimes overlook contributions. I don't like the type of erasure this can cause.

I'd love if we can use GitHub actions somehow to ensure that I don't skip anyone. I'm not exactly sure what this looks like, but the manual process above isn't working.

Perhaps as a PR is closed, a bot can remind me about attribution? Very open to ideas here.

Needs

• Ask person permission (I still think this is best done at this scale by the approver) to thank them publicly on Twitter from SelfDefinedApp on Twitter.
• Label addition of "Status Attribution" perhaps?
• Aggregate labelled PR somehow so I have it on a list.

[kathryngraysonnanz]

As a question – do we know everyone wants to be automatically tagged in a "thanks" tweet?

I was thinking about that earlier today, as I worked on the boogaloo definition...I don't think I'd want to be tagged in a tweet that includes the word "boogaloo", or potentially some other ableist / racist slur that I helped define, even if (in context!) it was clear I wasn't really using / associated with that word. It just seems like an easy way to become bot bait or get put on unfortunate lists. Just want to make sure we're thinking through any potential harm before automating a process!

[tatianamac]

Thanks for the clarification! No, I'm not hoping to suggest someone would be automatically thanked in the post, but rather that the flagging on the backend of GitHub would happen here in the PRs so we don't forget to ask the person permission either way.

[SeanKilleen]

Hi @tatianamac! Love this project and would like to support in at least a small way. I think this issue might be a place where I can jump in.

I think we could use the mergeable github bot in combination with some specialized labels to achieve at least a portion of this pretty quickly.

My draft suggestion --

First phase -- use the bot to:

• Label a PR with AttribtutionType - Pending (or any other label of your choice of course) whenever a PR is not labeled as Attribution Type - Public or Attribution Type - Anonymous
• Prevent a PR from being merged when it has an Attribution Type - Pending label.
• Label a PR with Attribution - Pending whenever it lacks an Attribution - Complete label.

So the workflow would look like:

• A PR is opened
• It automatically receives the AttributionType - Pending and Attribution - Pending labels.
• The PR can't be merged until a conversation happens on whether it should be attributed or not. A conversation happens, and one of the labels is chosen, at which point the AttributionType - Pending label is removed and the PR can be merged.
• Your to-do list becomes looking at all merged PRs that have the Attribution - Pending label.
• As you attribute each PR, you add the Attribution - Complete label, which auto-removes the pending label.

Potential future phases: Collect twitter handles from the GitHub profile or user input and prompt as to whether they'd like to be credited. Could also maybe figure out a storage mechanism so the twitter handles associated with a username are populated somewhere (thought here could be concerns there, of course.)

---

If you like the idea of the auto-labeling, I could submit a PR for the YAML configuration for mergeable that I think would result in those outcomes. You could create the necessary labels so that they exist & are color-coded as you'd prefer, and then when ready you could install mergeable into this repo which should respect the configuration we specify in the PR.

Let me know if you're interested in it!

[tatianamac]

@SeanKilleen I'd love your help with this!
I'm wondering if instead of having the workflow change from when a PR is opened to when it is "approved?" For any PRs that are duplicates or closed for any other reason, this would become mute.

If that works for you, I'd love to see a PR from you!

Also, we invite everyone who contributes to our Slack community! No pressure but it's a low key place to get feedback and introduce yourself!

[SeanKilleen]

@tatianamac I'm fine with that suggestion in theory but not sure the tools I mentioned have existing support for it. I'll try to confirm.

Is it more important to you at this point to have it happen only on approvals or to get a system in place? If it's the latter, I can get the system I outlined above in place and then we can iterate on it.

[tatianamac]

Sure. The latter is fine if the former isn't possible.

[SeanKilleen]

Some updates on this -- hasn't gone quite as smoothly as I thought it would, but I've got some next steps to try.

• I looked into the mergeable probot app but it wasn't as currently supportive of doing what we want with labels, even though the trigger piece could have worked.
• looked into the probot-require-label app, which does what we need it to do at a pull request (not approval) granularity. I set up a test rep and can't get it to run against though, so I may need to do our own deployment of it to get it to work.

So next step is to take the probot-require-label code, see if I can get it running via glitch or somewhere easily, and then get it to work on my repo. If that works, I can submit it as a PR using the one I set up along with instructions for anyone else to redeploy.

I'm also looking into github actions, which will work fine but are I think a little too slow because they'd need to build a docker container. I could also publish a docker container and have it use that for more speed, but then that's a separate thing to maintain.

So we've got some paths forward but I'll be working to find the simplest one.