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.