Prevent usage of github's noreply mail addresses?
Summary
In the recent past I noticed multiple times that contributors use the generic 'noreply' mail that Github provides for their users as the mail associated with their Eclipse account and for submitting contributions (which pass the ECA).
The mail usually has the form:
12345678+myGitHubUsername@users.noreply.github.com
Since it is a 'noreply' mail I assume it's not possible to really contact one through that mail and e.g. if that contributor becomes a committer mailing lists will then probably also not work.
Therefore I wonder if using a noreply-github mail is discouraged and should be forbidden?
Priority
- Urgent
- High
- Medium
- Low
Severity
- Blocker
- Major
- Normal
- Low
Activity
added EMO service:GitHub team:emo labels
I tend to agree. We see these email addresses when folks use the GitHub UI to create commits. At least one concern is whether or not a patch can be adequately tested when it is created in that manner.
Having said all that... I believe that these pass the ECA checker because it understands these email addresses and know how to track back from the GitHub ID to the corresponding Eclipse Foundation Account. If they are passing the ECA checker, we can be sure that they do have an Eclipse Foundation Account with a real email address attached at the EMO can use to contact somebody if necessary. So, we're confident that we can trace these commits back to the author.
If they're a contributor, you can communicate with the contributor via the pull request. If the vibe doesn't feel right, the EMO/IP Team can help committers sort through it.
IMHO, this sort of restriction would be a big change. We need to have very broad support from the committer community before we consider doing this.
I believe that these pass the ECA checker because it understands these email addresses and know how to track back from the GitHub ID to the corresponding Eclipse Foundation Account.
This is correct! There are 2 formats of noreply email (legacy and modern) that both include the Github ID. We can map to the user account as long as it matches the Github handle set in the user account.
I want my primary GH address to be noreply one.
Even when I use non-noreply - if in EF project my PR (after ECA validates my real address used in original commit) gets accepted and merged with "Squash & Merge" or "Rebase & Merge" - it goes to 4% bin.
Example:
- PR - https://github.com/jakartaee/specifications/pull/784
- commit submitted for review and ECA validation: https://github.com/jakartaee/specifications/commit/cc94ed4962eee7d051437e5ccdc48abb813ef692.patch
- commit as merged: https://github.com/jakartaee/specifications/commit/1bd50b3390019ed295ffaa5f00496a27a16c70c9.patch
Therefore I wonder if using a noreply-github mail is discouraged and should be forbidden?
I think it should be fully supported by EF.
Edited by Piotr Żygieło@wbeaton So long as the ECA validation works, I think this is a non-issue. IMO, the validation is the key component here, not that the commit is associated with an email address someone can cut and paste into an email client and speak with the author. Comments should be kept to the tooling for something like this.
@wbeaton what @jmcconnell said, plus we allow this explicitly because of a previous decision of the AC.
Please see https://www.eclipse.org/lists/eclipse.org-architecture-council/msg04442.html
The handbook MR is eclipse/technology/dash/org.eclipse.dash.handbook!1 (merged)
@jograham merged. Sorry for the long delay. Thanks for the contribution.
mentioned in merge request eclipse/technology/dash/org.eclipse.dash.handbook!1 (merged)
@wbeaton I also think it should be permitted and explicitly supported:
- We can always communicate through the official channels (PR, Issue, Discussion, ...) if any direct communication is desired one can ask the person to contact one.
- If one wants to register to an mailinglist it needs to use the eclipse account anyways
- If the person later wants to become an committer it only works by providing the "official" mail address
- Protecting the email address from being public available could have several valid reasons, this is not only when using the Github UI see here https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/setting-your-commit-email-address is explicitly mentions the "private" option and how one prevents to expose the email address by accident.
I would even go further and make the whole contribution process easier for committers, e.g when I open an issue on Apache and it is only a few lines I can tick a checkbox:
Others offer some automated one-click-workflow see for example here:
so whatever we can do to make the first contribution easier the higher the chance people do it and maybe then contribute more, requiring them to expose their real mail-address "just in case" seem not to fit to such goal.
Edited by Christoph LaeubrichI would even go further and make the whole contribution process easier for committers
Please open a separate issue to discuss this.
requiring them to expose their real mail-address "just in case" seem not to fit to such goal.
By way of expectation management, I do not see any future in which we accept anonymous contributions.
-
Please open a separate issue to discuss this.
There already is #1579 ...
For small contributions I understand that one wants to keep it simple and doesn't want to setup more than absolutely necessary.
plus we allow this explicitly because of a previous decision of the AC.
Please see https://www.eclipse.org/lists/eclipse.org-architecture-council/msg04442.html
Since open-source projects and especially Eclipse projects care a lot about transparency I think it's also fair to ask a contributor to be transparent about their real identity. I know everything can be faked, but a completely hidden identity is even less trustworthy to me. Also I think it would be bad for a community if this is used often and we just have anonymous Github accounts that contribute.
And there are also technical aspects that IMO speak against it: What happens if one day Github goes away or at least if EF-projects migrate away from GH, then it will become very difficult to identify the real person that did a change from the Git history. As the git history to be the source that I think will last the longest I think we should have as much information in it as possible (this also applies to commit messages).
Furthermore as a committer and PL I'm really not willing to put extra effort into finding out how to contact a person that makes significant contribution, for example to ask if there is interest to become a committer. If one uses a no-reply mail, well then I respect that and doesn't contact that person.
@hwellmannwr6 I agree with the general sentiments you have on this topic and I think that any committer / PL that sees a commit come through from a non-obvious identity (regardless of whether it passes ECA) has an obligation to raise questions on it.
However, I want to ensure that we maintain lower barriers for people providing small fixes as just their GitHub identity.
If one uses a no-reply mail, well then I respect that and doesn't contact that person.
+1. If they are using no-reply emails then it is hard to imagine them fully participating in responsibilities of a committer (dev list, voting, dev calls, etc).
And there are also technical aspects that IMO speak against it: What happens if one day Github goes away or at least if EF-projects migrate away from GH, then it will become very difficult to identify the real person that did a change from the Git history.
AFAIU we do not rely on GitHub's presence to identify real identity. The noreply email address is looked up in EF's ECA database for the full details, including real name + real email address if needed. I don't think it is any easier or harder than identifying other ways people disappear (e.g. not updating email address with EF, the old CVS user ids, etc)
From the EF's perspective, we believe that we have what we need with regard to record keeping.
I completely support this position:
If one uses a no-reply mail, well then I respect that and doesn't contact that person.
+1
FWIW, if you feel that a contributor is not representing themselves in good faith, you can reach out to emo-ip-team@eclipse-foundation.org for advice and assistance.
@wbeaton - I am not able to attend the AC meeting on that date - I hope that my previous comments on this subject are sufficient explanation of my position that you can resolve this during the AC meeting.
As of today, there have been no comments on the thread.
https://www.eclipse.org/lists/eclipse.org-architecture-council/msg04797.html
added team:projects label and removed EMO team:emo labels
EMO is satisfied that the documentation requirements in the IP Policy are met when contributors (who must have signed the ECA) provide us with commits using their GitHub "noreply" email.
Based on the responses that we've received from the Eclipse Architecture Council, the EMO will not escalate this matter at this time.
