Figure out the future of the OSPR Bot

[sarina]

Ticket Intention

This ticket is an exploratory issue. Figuring out how to move forward and generating necessary tickets to execute on will be the outcome of this ticket.

Decoupling questions

In light of the edX-tCRIL decoupling and increasing distribution of code ownership...

Who will depend on the bot, and for what?

• edX: creating and linking Jira tickets for each OSPR on the Jira project of the owning team.
• tCRIL: putting OSPRs on our team project board for code we own?
• others firms: pushing to their preferred issue tracking system when a PR is opened on owned code?
• tCRIL: automating the CLA flow by hooking into Salesforce.
• anything else?

Who will maintain the bot?

• edX Arch-BOM?
• tCRIL?

Where do bot-related issues go?

• edX Jira, in the BOM project?
• this tcril-engineering GitHub repo?

Other issues

Cataloging these here until we have a proper place for issues.

Personal access token vs App

Until recently, the OSPR bot was implemented as an OAuth App in GitHub. Because the openedx GitHub org is configured not to allow arbitrary OAuth Application access, we either needed to
(i) do the legwork to make the OSPR bot an approved OAuth App, or
(ii) change the bot to use a personal access token from the openedx-webhooks account, or
(iii) change the openedx GitHub org to allow arbitrary OAuth application access.

We took approach (ii).

We have some concern that because this is not the "proper" way to integrate with GitHub (they technically have a one-user-account-per-human policy) that this may expose us to being rate-limited more aggressively than if it were a proper OAuth App or GitHub App (which, mind you, are different things). For now, we've decided to proceed with a personal access token, with Ned keeping an eye on the logs to see if we're approaching or hitting a rate limit.

In the future, though, it would probably be prudent to turn the OSPR bot into an approved GitHub App or OAuth App.

[sarina]

oops duplicate