Bot to automate countdown process for standard name proposals

[sadielbartholomew]

As suggested with some subsequent approval by others in https://github.com/cf-convention/vocabularies/issues/93, it would be beneficial to have a tool to automate the management (time-tracking, repeated announcement, pausing etc.) of time periods initiated by lack of further comment on a given issue to propose a new standard name. Specifically this was suggested about the "cooling-off" period proposed in cf-convention/vocabularies#93 but it could be generalised to assist with any aspect relating to a triggered countdown or events dependent on the lack or otherwise of new comments.

I am yet to investigate possibilities for implementation, but off the top of my head I think there are various options including:

• writing scripts to directly query the GitHub API;
• using GitHub Actions (including re-using pre-build Actions and adapting them to our needs via a specialised workflow);
• using and customising some dedicated GitHub Issue bot library (I think it is safe to assume there are many in existence).

[erget]

Hi @sadielbartholomew (oops, sent the previous incarnation of this comment prematurely), this is definitely a cool idea that will be helpful for moderators and hopefully the community alike.

I may not be aware of the full set of ways in which this group uses automation, but I believe it's mostly via a mix of GitHub Actions and Travis, as described here.

At some point we'd discussed also consolidating the Travis automation to GitHub Actions, and I've got that on my list of things to look at, because it would simplify things, but first it makes sense to pursue what you're proposing, I think (keeping track of secretarial tasks). Do you think it'd be possible to make a prototype that we can try out somewhere without risking spamming everybody in the main repo? I'm happy to test and troubleshoot with you.

[ngalbraith]

I support this proposal; I'd like to add a mechanism, at least for the standard name issues, whereby the originator can flag a request, once it appears that consensus has been reached, so that there's no need to wait for the proposal to become inactive.

Some sort of tag could be used - like 'ready to go' - to initiate the process. I'd hate to have a late comment in support of a proposal act to delay its actual acceptance. It doesn't seem like this would complicate the code too much, and could make it considerably more effective.

[sadielbartholomew]

Thanks @erget. I'd be happy to make a prototype in collaboration with yourself and anyone else that would like to chip in. Maybe I could start to create something in a repo under my userspace and once it matures and is tested sufficiently we can transfer it here to the cf-convention organisation? Or indeed under this organisation straight away if you think that is better.

BTW, I'm also happy to help RE migrating from Travis to GitHub Actions if it would help to have someone else working on that too. I did some Actions work with cf-python, cfdm and cf-units so have a bit of experience with it.

[sadielbartholomew]

Thanks @ngalbraith I like that idea and agree it would prevent delays which would make the proposal process more efficient. I'll add that to the list of requirements for the bot.

When I get round to starting this up, which will be next week at the earliest as I have some priority work to finish this week, I will post a list of tags suggested so far (e.g. 'trigger cooling period' by Alison or Fran, your new idea 'ready to go' by the proposer) with some proposed details for what the bot should do in each case. I'm sure there are further tags that would be useful so by starting a list it might help to generate other ideas.

[erget]

Hi @sadielbartholomew either approach is fine for me; I personally prefer to work in a public repo owned by me so that I can wreak change boldly without the fear I'll break anything, without sacrificing the ease of requesting input from others. But that's my personal preference. Either way your signature stays on the commits when we fork here so everybody knows who to blame in the end ;)

What's your plan, make a repo of the bot's actions that we then ask the bot to complete? I've never built anything like this before so this is terra incognita for me. Let me now as soon as there's anything you'd like my input on and I'll be happy to provide.

[sadielbartholomew]

I personally prefer to work in a public repo owned by me so that I can wreak change boldly without the fear I'll break anything, without sacrificing the ease of requesting input from others. But that's my personal preference.

Yes I agree, I think it's a very good means to have a testing ground that is self-contained, informal and open. I'm happy to go with that so I've just set up a public repo to use: https://github.com/sadielbartholomew/stan. For now I've called it 'stan' since that's a short abbreviated anthropomorphic name for the bot that we can use until we have something mature enough that the CF Conventions community will hopefully want to embrace it and christen it properly as they wish.

What's your plan, make a repo of the bot's actions that we then ask the bot to complete?

I think it will be best not to dive in with any development yet, rather gather some ideas for approaches and gather requirements ('desires' would be a more appropriate word really) i.e. services that could be done by a bot that people think could help with the proposals process. So first I might just have a directory, or a wiki attached to the repo, containing some notes. Then the repo can eventually contain the scripts or API or whatever we have that implements the bot. We might need a separate username to operate on and with, like @cf-conventions-bot.

I won't have time to work on this until the New Year but in early January I'll start to do some research into possible implementation approaches and think about how we can go about planning the specific utilities to implement that the community would benefit from to streamline the standard names proposal process, as we've been informally brainstorming in our comments. It might be good to set up a discussion with key people such as Alison and Fran to gather thoughts.

I'll note any significant progress on the above by comment on this issue.

I've never built anything like this before so this is terra incognita for me.

Same here! It will be interesting indeed. Since opening this issue I've discovered that the term ChatOps is used nowadays to cover bots and the like of which we are considering, so searching on that term will be a good way to locate resources.

Let me now as soon as there's anything you'd like my input on and I'll be happy to provide.

Thanks, that's very kind and will be really useful :grinning:. Let me know if at any point you have thoughts or ideas by commenting here or in the new repo (or email, etc.)! I will indeed ping you when I have made progress to share and discuss etc., probably in mid to late January.

[davidhassell]

Hi @sadielbartholomew - thanks, I think that your approach sounds sound. I have nothing technical to give in this arena, but I'm more than happy to take part in the designing discussions. Have good weekends, all.

[dopplershift]

Really good idea to move away from Travis. They're greatly reducing the freely available resources for those unaware.

Most of us over at Unidata have been moving to GH Actions instead.

[ethanrd]

Hi all - The “Issue Label Notifications” GitHub Action looks like it could be useful. It can be used to send notifications (to individuals or teams) when a label gets added to an issue. Perhaps a label, something like “Std Name - Agreed”, could be used by the proposer or a moderator to indicate that they believe agreement has been reached on a new standard name(s) issue/proposal. The GitHub Action could be configured to send a notification to Alison and Fran (or to the full CF Information Management and Support Team?) so a comment on the issue can be made to start the cooling-off period.

I’m afraid that’s all I have for now. I thought I had seen some other GitHub Actions that might be useful for automating 3-week countdown reminder(s) but now I’m not seeing anything. The “Close Stale Issues” GitHub Action looks promising but I think it would need some tweaking before it could be used for this.

[sadielbartholomew]

Thanks @ethanrd, I really like the idea of using labels too and think additionally they will make the status of an issue clear to see without the need to read through the latest comments on a given thread.

GitHub Actions generally looks promising too as a means to help with the countdown process. If we can't find a good Action externally it might be easy enough top write our own.

I am still looking into the possibilities and potential approaches and will report back here with details and thoughts shortly, in late January or early February.

[sadielbartholomew]

This issue went stale, but I am keen to re-activate it (there's a slight irony there as we're thinking about bots that monitor activity on issues)!

I have been doing a little research and it seems like protobot is the simplest and most flexible way forward. It is a well-established and actively maintained and developed project which allows for "building GitHub Apps to automate and improve your workflow". In fact, there are already some applications built for protobot that do something very conceptually similar to what we want to do here, namely:

• a "stale" application (and see also https://github.com/probot/ideas/issues/92) which closes issues when there hasn't been any activity on an issue for a configured amount of time, that could even be used as-is for a starting point if we configure it to not ever close the issues, only mark them as 'stale';
• a "sentiment" application which "replies to toxic comments with a maintainer designated reply and a link to the repo's code of conduct".

If we adapt the "stale" application or "sentiment" applications in a basic way to provide a given reply after a certain amount of time, rather than a message with the specific context of the latter, and not closing any issue, we should have something we can use already, I would think.

So, in short, there are tools available that could allow us to configure this in a short-ish amount of time. For this reason I will be proposing this for the 2022 CF Meeting Hackathon (I will add a summary to cf-convention/discuss#152).

[erget]

I support this idea. Particularly the "stale" application might be used to trigger the timely merging of things.

[feggleton]

I have just created a GitHub Action and workflow based on what I think we need for this and discussed with Alison too. I have 3 actions in mind to start with. This is in a fork of the discuss repo so I can create and test before sharing.

[sadielbartholomew]

I have just created a GitHub Action and workflow based on what I think we need for this and discussed with Alison too. I have 3 actions in mind to start with. This is in a fork of the discuss repo so I can create and test before sharing.

Brilliant, thanks Fran/@feggleton! I look forward to hearing about your progress when you are ready to share it.

[JonathanGregory]

Fran @feggleton has written as follows in the linked pull request

I have done some work to add a bit of automation into the standard name process using GitHub Actions. I have currently added the following actions:

• When a new issue is added with the label 'standard name', a comment will be added to explain a little bit about the next steps and link to the cfeditor where name requests are added. [happy for text to edited or suggestions given]
• When an issue with the label 'standard name' has not been commented on or seen activity for 30 days (date can be amended), a label will be added of 'moderator attention' and a comment will be added to encourage discussion whilst notifying standard name managers so they can also comment [again, happy for text suggestions or changes]

I have thought about some other Actions which could be added but they are a bit more complicated so would need to be considered carefully before implementing. For example, after adding the 'accept within 7 days' label it would great to have a comment added after 7 days tagging either myself or Alison so we can set the label to accepted if that's appropriate. However, this would depend on any comments being added in that 7 days and then those comments being assessed as either agreement or opposition. I'd need to think about how this might work and whether this would actually be useful.

In the original ticket, someone had also requested 'the originator can flag a request, once it appears that consensus has been reached, so that there's no need to wait for the proposal to become inactive' - I think this would work by adding the 'moderator attention' label and tagging either myself or Alison.

I have tested as many scenarios as I could think of but would appreciate any other testing or test cases others can suggest in order to get this implemented.

[JonathanGregory]

Thank you very much for your work on this, Fran. I am sure that what you have done will be useful. Karl @taylor13 made a useful suggestion about reminding people in new issues about the guidelines for standard name construction. Perhaps you could consider that comment?

[feggleton]

Ah thanks Jonathan, I was just going to link to my comment in this issue. Yes that's a good idea, I can easily amend the comment that is added to new issues. I will look into the wording and discuss with @japamment