Bot for automatic merging apprroved RFCs/closing rejected RFCs

[bkchr]

After RFCs are approved on chain, they can be merged directly. This should be done by a bot and should not require any manual intervention. The same applies for rejects.

The bot should monitor the fellowship referenda for referendums that want to enact a remark with RFC_APPROVE or RFC_REJECT. The exact process on how a referendum is executed, is documented in the README. After the referendum was approved, the bot should do the appropriate action(merge for RFC_APPROVE and close for RFC_REJECT).

[xlc]

To keep things simple, we don’t necessarily need to constantly monitor the chain. We could for example have a github action trigger that takes a block number as input, and manually trigger an action based on the event in that block. In this way we don’t have external server dependency.

[rzadp]

@xlc I'm not sure I understand your proposed workflow. If I'm manually triggering an action, have the access rights to do so, and I have checked the block number, I could check the output of the referendum and close/merge the PR instead - similar amount of steps.

Isn't the idea to have it 100% automated? If it's somewhat manual, then manual close/merge is the simplest solution, if I'm not missing something here.

[xlc]

It is just like how most of the onchain contracts works. The monitor is offchain and trigger is a permisionless onchain action that verifies some conditions and enforce it.

In this case, the monitor is manual, or could be a server, doesn't matter. The trigger is a permisionless Github Action bot. It could be a comment to the PR for example that anyone can do it. It is the bot/GH action verifies if the RP is indeed approved and then perform the merge. The whole point is following the onchain decision, not depending on some specific admins on this repo.

[tomaka]

My two cents is that a manual bot is a better idea, just because it's more simple.

If the bot is automatic, that means we need a server, which raises the question of who maintains and monitors the server. The entire point of having a bot is that the process becomes decentralized and not owned by anyone. If someone has to maintain a server, you might as well just ask that person to merge the PRs in this repo instead.

Plus, we all know that the server maintenance will be half-assed and that the bot will likely break down all the time.

And if the bot breaks down (which will definitely happen at some point if it's automatic), we have to fall back to a manual process anyway.

[bkchr]

It could be a comment to the PR for example that anyone can do it.

Like the bot @rzadp for creating the proposal. I like the idea!

[xlc]

I already have a working PoC.

Demo: https://github.com/xlc/RFCs/pull/14 GH action code: https://github.com/xlc/fellowship-process-bot

[rzadp]

I already have a working PoC.

Demo: xlc#14 GH action code: https://github.com/xlc/fellowship-process-bot

Looks neat to me. I see it includes the part where you have to look at a block before the referendum is confirmed to read the data. @xlc Did you take into account that the referendum proposal can be Inlined, not only made as a Lookup? In fact Inlining is the approach I took in the PoC bot that facilitates the creation of those referenda.

Also this inspires me to change the bot into a GH action, to remove the need of a running server.

[xlc]

It is a PoC and therefore don’t cover every edge cases. But it is easy to support in-line proposal.

The pjs apps UI doesn’t offer a way to create inline proposal other than manual construction.

[rzadp]

I have ported my thing to work as a GitHub Action.

Here it is in action: https://github.com/paritytech/rfc-propose/pull/5

[xlc]

So what's the next step? Should we collaborate on rfc-propose or fellowship-rfc-process-bot? Should we start to integrate one into here?

[rzadp]

@bkchr @tomaka Do you have any feedback on what we have?

To sum up:

• There is the first action, configured like this, is gonna work like that.
• There is the second action, configured like this, is gonna work like that.
  • I think we can remove the need of specifying the blockhash manually if we make the action hunt down a matching referendum automatically.

[bkchr]

What kind of feedback you want? :D I mean from the first look, it seems to be okay.

[tomaka]

I think we can remove the need of specifying the blockhash manually if we make the action hunt down a matching referendum automatically.

Well, you can't do that unless you iterate over every single block that has been authored since the RFC has been proposed (assuming the bot could know when the RFC has been proposed), which takes a large amount of time and bandwidth.

Also, correct me if I'm wrong, but you're looking into the block storage (the list of events) to determine whether an RFC has been approved, meaning that you specifically need to target an archive node.

In general I feel like remarks are a very very poor mechanism, especially when triggered through a referendum instead of being included in a block body (block bodies are kept forever by every node).

[tomaka]

There is the first action, configured like this, is gonna work https://github.com/paritytech/rfc-propose/pull/5#issuecomment-1695626791.

To give some feedback: I've been in the Polkadot ecosystem for 6 years, and I've been using PolkadotJS extensively, and despite that I literally have no idea how to open this referendum, pragmatically speaking. I feel like some more detailed instructions wouldn't hurt.

[rzadp]

Update:

1. I have added detailed instructions with screenshots about what is expected from the user (example).
2. We have integrated @xlc's work regarding PR merging/closing into the action.
3. A PR with the new version of the action is here.

[mordamax]

I guess we can close it per https://github.com/paritytech/opstooling/issues/283 But I don't have permissions

[tomaka]

I guess we can close it per https://github.com/paritytech/opstooling/issues/283

This repository is private and inaccessible for anyone non-Parity.