Community
Participate
Working Groups
Some potential users have reported being OK signing the ECA, but not willing to create an Eclipse.org account. Basically, they're fine with the IP part but don't plan to be much more involved in the Eclipse.org ecosystem on long term for registration to be worth it at the moment. It should be possible for users to sign the ECA without creating an Eclipse.org account.
(In reply to Mickael Istria from comment #0) > Some potential users have reported being OK signing the ECA, but not willing > to create an Eclipse.org account. Can you post some data (eg., links to discussions/comments on GH issues or elsewhere) that allows quantifying the number of users?
(In reply to Gunnar Wagenknecht from comment #1) > Can you post some data (eg., links to discussions/comments on GH issues or > elsewhere) that allows quantifying the number of users? https://github.com/eclipse/tycho/pull/20 is the just recent example. I did post on some other PRs. I also remember that has happened on another project a couple of weeks ago (same kind of trivial change) but couldn't remember where. Overall, it's not a too frequent issue; but it's the most frequent one I see now that Signed-Off-By is off.
See also bug 571711. This should lower the barrier at least. Something like a "trivial change"-exception for typos, documentation, etc would be good as well. As soon as any code is involved, it's a lot harder to judge though.
I do not see us removing the requirement to "create an account". We need to have a record in our database of who has signed the ECA. But by I could imagine us using OAuth so that the account creation is painless, and so they do not need to create a separate userid/password combination with us. Would this be a step in the right direction: - contributor arrives at our site and is requested to create/sign an ECA. - as an alternative to "create an account on eclipse.org" they have an option to use an existing account on (say) GitHub or Google to authenticate. Under the hood we use the information provided by OAuth to create an account record in our database. - after authenticating we would need them to answer some additional questions (e.g. do you work for a Member company?), plus offer them the ability to sign the ECA. Thoughts?
(In reply to Mike Milinkovich from comment #4) > Would this be a step in the right direction: > - contributor arrives at our site and is requested to create/sign an ECA. > - as an alternative to "create an account on eclipse.org" they have an > option to use an existing account on (say) GitHub or Google to authenticate. > Under the hood we use the information provided by OAuth to create an account > record in our database. > - after authenticating we would need them to answer some additional > questions (e.g. do you work for a Member company?), plus offer them the > ability to sign the ECA. > > Thoughts? That would be a good improvement. I imagine what people particularly dislike in creating a new account are 1. creating a new password 2. Filling forms they already filled everywhere else 3. Facing a long "page-flow" 4. Receiving undesired mail notifications Your proposal fixes concerns 1 and 2; current state of things with GPDR fixes concern 4, and I'm confident that the flow can be made simple enough to have all that on a single simple page and avoid concern 3. So unless we're missing another concern, the proposed plan seems to be a good one.
(In reply to Mickael Istria from comment #5) > (In reply to Mike Milinkovich from comment #4) > > Thoughts? > > That would be a good improvement. +1 That's similar to how I've seen it work in other organizations. It's possible to implement an optimized flow for users arriving from GitHub, i.e.: 1. ECA Bot posts comment (request for ECA) with link on PR. 2. User clicks links, is redirected to Eclipse.org and immediately redirected back to GitHub as part of oauth dance. 3. User clicks "authorize" to allow Eclipse.org seeing GitHub id and email address, then redirect happens to Eclipse.org 4. User signs ECA on Eclipse.org and is redirected back to GitHub PR.
@Chris Guindon, WDYT?
(In reply to Mike Milinkovich from comment #7) > @Chris Guindon, WDYT? +1 to allow users to create an account using Github/Google OAuth. I recently posted a comment about this on Bug 571711 - Allow "Login with GitHub" on Eclipse.org https://bugs.eclipse.org/bugs/show_bug.cgi?id=571711#c2 Here some additional thoughts: > That would be a good improvement. > I imagine what people particularly dislike in creating a new account are > 1. creating a new password We currently require the current password to update profile information such as an email. We put this in place to stop someone from hijacking a session and change their profile. The user must know the password of the account to make this change. > 2. Filling forms they already filled everywhere else Looking at our current "Create an account form" (https://accounts.eclipse.org/user/register?destination=user/login%3Ftakemeback%3Dhttps%253A//www.eclipse.org), the user won't be required to enter their name, email, and GitHub id. However, we will probably need them to pick a username, share their employment status and pick a password. I don't think Country should be a required field. > 3. Facing a long "page-flow" I think the real benefit to the user is that we won't need them to confirm their email. One less step is a win in my book! > 4. Receiving undesired mail notifications Users can manage their mailing list subscriptions and privacy settings via accounts.eclipse.org. (In reply to Gunnar Wagenknecht from comment #6) > (In reply to Mickael Istria from comment #5) > 1. ECA Bot posts comment (request for ECA) with link on PR. > 2. User clicks links, is redirected to Eclipse.org and immediately > redirected back to GitHub as part of oauth dance. > 3. User clicks "authorize" to allow Eclipse.org seeing GitHub id and email > address, then redirect happens to Eclipse.org > 4. User signs ECA on Eclipse.org and is redirected back to GitHub PR. This is missing the step where we would ask the user about their employment status, username, and password. This sounds like we would allow users to sign the ECA while creating an account. I think this is a good idea.
(In reply to Christopher Guindon from comment #8) > This is missing the step where we would ask the user about their employment > status, username, and password. Username can be eliminated if email becomes he username. I always login with my email so I am not sure why a username is required. If it is for becoming a committer than it can be postponed till the user actually wants to become a committer. I am not sure why employment status is required. It should be eliminated IMO. It does not provide any value in addition to the ECA. At least not at this initial. stage. When user arrives from GitHub there are two situations possible: 1. existing user (email matched) 2. new user (email never seen before) Case #1 requires a log-in to prevent hijacking. So query for password is ok as well as a password reset feature. Password would not be required in case #2 because authentication happens via external provider. A flag on the account should indicate that this account has no password set and needs authentication via GitHub. We *can* offer to set a password but it should not required IMO. I've seen some sites doing it but I dislike it TBH. > This sounds like we would allow users to sign the ECA while creating an > account. I think this is a good idea. Correct. Single step.
(In reply to Gunnar Wagenknecht from comment #9) > (In reply to Christopher Guindon from comment #8) > I am not sure why employment status is required. It should be eliminated > IMO. It does not provide any value in addition to the ECA. At least not at > this initial. stage. I think this is required because of the Member Committer and *Contributor* Agreement. An individual who works for a company that has signed the MCCA is not required to sign an ECA. Some companies really prefer this ability and we would hate to lose it.
(In reply to Mike Milinkovich from comment #10) > (In reply to Gunnar Wagenknecht from comment #9) > > (In reply to Christopher Guindon from comment #8) > > I am not sure why employment status is required. It should be eliminated > > IMO. It does not provide any value in addition to the ECA. At least not at > > this initial. stage. > > I think this is required because of the Member Committer and *Contributor* > Agreement. An individual who works for a company that has signed the MCCA is > not required to sign an ECA. Some companies really prefer this ability and > we would hate to lose it. 🤔 This is an interesting optimization, indeed! Can this also be done with the email domain? What if the typed in name does not match the company name on the MCCA? I haven't looked at the form in a while. Is this explained there as part of the checks to verify an ECA is needed. Because then the motivation to enter the data is different. :)
(In reply to Gunnar Wagenknecht from comment #9) > Username can be eliminated if email becomes he username. I always login with > my email so I am not sure why a username is required. If it is for becoming > a committer than it can be postponed till the user actually wants to become > a committer. You are right, we can pick a random username for the user. We did that until last week! I do want to say that it's very time-consuming for us to change the user id after the account was created. A compromise would be to make the username field optional. > > I am not sure why employment status is required. It should be eliminated > IMO. It does not provide any value in addition to the ECA. At least not at > this initial. stage. I believe the employment status is still a relevant question for us to ask. For example, if your employer signs an MCCA, you don't need to sign an ECA. > Password would not be required in case #2 because authentication happens via > external provider. A flag on the account should indicate that this account > has no password set and needs authentication via GitHub. We *can* offer to > set a password but it should not required IMO. I've seen some sites doing it > but I dislike it TBH. Correct, users will be able to login without a password if they decide to link their Github ID with their Eclipse account. From my perspective, we should allow new and existing users to link their github account with their Eclipse account. I think we can come up with solutions for the password field but I don't think it's a good idea right now. Users without a password won't be able to log in to Bugzilla and Gerrit. I would recommend that we update how users can login to these services before we consider dropping the password field.
(In reply to Christopher Guindon from comment #12) > I think we can come up with solutions for the password field but I don't > think it's a good idea right now. Users without a password won't be able to > log in to Bugzilla and Gerrit. I would recommend that we update how users > can login to these services before we consider dropping the password field. I have a hypothesis that users on GitHub complaining about paperwork for contributing to Eclipse do not care about ability to log into Bugzilla and Gerrit right away. (In reply to Christopher Guindon from comment #12) > A compromise would be to make the username field optional. Or: pre-populate it based on a string from the email address or github id with a random number to make it unique. Then users can decided to customize it or just accept it.
> You are right, we can pick a random username for the user. We did that until > last week! The user name is used quite a lot in GitLab (e.g. [1]) and, especially, in @-references in issue comments. At some point @amisingname42 is going to ask us to fix their user name. In the GitHub case, shouldn't we just grab and use the GitHub Id (assuming that's an option)? In the general case, we need to at least give new users the option of providing a user name. Ultimately, we're going to need to provide a self-service means of changing it. [1] https://gitlab.eclipse.org/wbeaton
(In reply to Wayne Beaton from comment #14) er name is used quite a lot in GitLab (e.g. [1]) and, especially, in > @-references in issue comments. At some point @amisingname42 is going to ask > us to fix their user name. +2 on Wayne's comment. We've moving back into the era where the username is front-and-center, let's not short-change it.
This issue has been migrated to https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/587.
