MattiSG
commented
1 year ago Thanks @kissaki!
This is currently an accepted shortcoming.
The good solution would be to enable user authentication. We have decided against this route for the moment as the cost-to-benefit ratio of setting up such a solution seems too big considering how many contributors might not even have a GitHub account, and that as we understand the auth system, this would entail setting up a database on the server.
The easy solution would be to collect, beyond the email address, a declarative GitHub username to be stored in local storage that would be then passed to the PR template so that the user gets mentioned and thus automatically subscribed. This would enable spam, but at our current scale we consider that a risk just as acceptable as the current risk of impersonation by declarative email. A slight improvement in UX would be to use the search user GitHub API to detect username from primary email, but honestly that is probably overinvesting to save the user one step of setup, and would not account for cases where the email used by the user for contributing to Open Terms Archive does not match their primary GitHub email address.
We would welcome such a contribution 🙂
A contributor that is a GitHub user will not receive PR review comments. Unless they themselves discover the PR and manually subscribe to updates they will not know about or respond to review comments. In that case reviewers or other contributors have to make the requested changes. The contributors will not be able to describe their intention or thought process for specific implementations of selectors etc.
On contribution submit a bot creates the PR, using the submitted author information as git commit author. GitHub will show the commit author (email) associated GitHub account. However, the user is not tagged nor the creator of the PR created by the tool.
Other than the "pull requests" link on the submit confirmation page the GitHub user will not be aware of the PR and not be notified of review comments.
This may be intended or an accepted shortcoming [for technical reasons] but AFAIK this is not documented.
A viable addition would be querying for a GitHub user and then tagging them on PR creation.
An extensive solution would be authenticating in the tool with a GitHub account so we know the definite GitHub username handle and could also query for preferred commit author settings (name + email) of the account. The definitely correct user could then be tagged in the created PR.
Personally I currently always open the PR via the "pull request" link and subscribe manually. And I add implementation notes as a comment then if I have any.