The following seems a little bit much, especially considering that the main use case right now is triggering a builds.sr.ht job.
sr.ht by ddevault wants to access your account Repositories Public and private This application will be able to read **and write** all public and private repository data. This includes the following: Code Issues Pull requests Wikis Settings Webhooks and services Deploy keys Collaboration invites
At least for that, read-only access to github should be sufficient.
In two occasions I told a colleague of mine about sr.ht and sparked their interest, with the increased flexibility of builds.sr.ht as the main differentiating feature over github+travis. In both cases, this permissions screen was a deal-breaker.
We need those permissions to install the webhook which notifies sr.ht of pull requests et al. There are no more conservative permissions for this.
Is it not possible to install the webhooks oneself if sr.ht tells us what it wants to have there?
https://github.com/$org/$repo/settings/hooks let's one edit/add webhooks. I wonder whether I could provide the information there that sr.ht needs to be able to react on a commit/pull request.
Permissions on github should be less scary now and similar to the one travis has.