Bot Requirements

[IgnoredAmbience]

On PR update:

1. If PR is Normative, continue, otherwise ignore
2. Check that PR submitter has signed, otherwise fail.
3. (Optional?) For each commit in the PR:
   1. If GitHub has matched the user, and the user has signed, continue.
   2. If GitHub has matched the user, and the user has not signed, fail (or flag?)
   3. Else if GitHub has not matched the user, fail (or flag?)
4. Set a status on the head commit of PR.

User has signed, if one of the following applies:

• User is member of @tc39/delegates
• User is a member of a TC39 member organisation
• User is present in signatory form, and has digitally signed correctly ("I agree" in final field)

Relevant GitHub APIs:

• Organisation teams
• Commit Statuses
• PRs

Existing GH JS bot framework: Probot, sketch implementation.

Deployment options: (General assumption for prototyping/initial deployment is a free tier of a cloud service, resource usage should be low enough to fit within most free offerings).

• Google App Engine, pros: (Googlers on tc39), cons: not an option for free tier as Node.js support requires the flexible environment.
• Azure, pros: others already have experience through TCQ deployment, (MS employees on tc39)
• Heroku, pros: I've already got experience with this platform.
• Glitch, pros: minimal setup, free, cons: limited deployment options, seems easy to slip up admin permission granting through UI - only invite link available
• Now, pros: minimal setup, free, someone(?) already has experience with the platform due to timebox deployment, cons: deployment only through their client
• CI platforms: not an option (see below)
• (List not exhaustive)

[littledan]

For deployment, why not Travis CI?

[IgnoredAmbience]

Apologies Dan, I had begun drafting a reply to this, but seem to have lost it.

Not Travis CI for a few reasons:

1. Secret configuration variables are not available to PR builds due to the possibility of the PR code being modified to leak the secrets via the build log.
2. PR code could simply drop the call to the bot in the PR commits. This would probably be picked up by review.
3. It may be wished for the bot to be expanded to take on other administrative tasks in the future, that need to be run independently of the build cycle.

Downsides are of course that it requires an additional maintenance responsibility, but I was hoping to mitigate that with clear re-deployment instructions and granting multiple committee members admin rights to the app deployment on whatever cloud platform is chosen, in the event that the primary maintainer is unreachable.

[littledan]

How is development here going? I wanted to mention, it's possible to encrypt things and decrypt them with keys stored in Travis-CI environment variables, so 1) is a solvable problem. As you mention, 2) doesn't seem like a big risk. If you have ideas for tasks for 3), though, that sounds like the biggest factor.

We have another relevant data source: @patrickcharollais has sent me a list of member organizations of Ecma who have signed the RFTG agreement. Ideally, we could hook up these organizations' accounts to an automated system to say that individuals who belong to one of those organizations are able to write normative PRs (rather than making reference to the manually maintained Delegates group). @domenic or @annevk may be able to give more information about WHATWG's implementation of something similar.

[IgnoredAmbience]

For 1) even though it is possible to encrypt and decrypt things in TravisCI, it explicitly doesn't permit this during PR builds. Documentation on their policy

The member organizations seems like a good approach in addition to the delegates. Assuming the organizations have an official github org, and the user displays it publicly on their GH profile, then I hope that the membership information should be available through the API. I'll take a look into this.

I've had the various parts of the automation functioning separately, I just need to put them together now. I've been slow on progressing this for various reasons, that I won't go into further here.

[littledan]

For 1) even though it is possible to encrypt and decrypt things in TravisCI, it explicitly doesn't permit this during PR builds. Documentation on their policy

Of course, how could I not have realized that. OK, great, thanks for architecting this well.

I've had the various parts of the automation functioning separately, I just need to put them together now. I've been slow on progressing this for various reasons, that I won't go into further here.

Great to hear about this progress. Don't worry about it taking time; I can understanding that this is nobody's primary responsibility.

[domenic]

@domenic or @annevk may be able to give more information about WHATWG's implementation of something similar.

The code implementing this is in https://github.com/whatwg/participate.whatwg.org.

[IgnoredAmbience]

@domenic Thanks! I may borrow some parts of the code for normalization of GitHub IDs. It also confirms that public membership of member organisations is feasable. However, much of the GitHub webhook heavy lifting seems more suited to the @probot library that I'm already prototyping with.