Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EPIC: Ideas to improve website information and user flow #1253

Open
CarmenDelgadoEclipse opened this issue Nov 29, 2022 · 15 comments
Open

EPIC: Ideas to improve website information and user flow #1253

CarmenDelgadoEclipse opened this issue Nov 29, 2022 · 15 comments
Labels
enhancement New feature or request

Comments

@CarmenDelgadoEclipse
Copy link

CarmenDelgadoEclipse commented Nov 29, 2022

Is your feature request related to a problem? Please describe.
as part of the 2023 program plan and improvement ideas (new members onboarding). I've been listing some ideas for website information and user experience improvements.

Describe the solution you'd like
Here are some ideas collected during our community talks, Community Day, and other meetings. Of course, they need more development:

If you don't want to just download Temurin define a proper flow:

  • Evaluate the current flow, and define a new one for these users.
  • Improve about us

For new members and sponsors to come:

  • Have the same UX as others Eclise foundation working groups:

Additional context
Here is the miro board from 2021, when the community was working on the current website: https://miro.com/app/board/o9J_lS-P2Qs=/

[Updated 2023-03-29]
More ideas from the community:

@CarmenDelgadoEclipse CarmenDelgadoEclipse added the enhancement New feature or request label Nov 29, 2022
@smlambert
Copy link
Contributor

Related to this is the need to organize our messages based on the audience (different personas we are targeting):

  • Getting involved / contributors -> potential contributors / developer audience
  • Release calendar / release details -> existing contributors
  • Support -> enterprise consumer audience
    etc.

For the record I do not find the jakarta.ee get-involved doc remotely compelling, so I guess we will need to do better than that. We also need to identify 'upstream' problems for first time contributors and attempt to fix them (adoptium/containers#317 (comment)) since we constantly bash our heads against friction-filled/awkward process (why is the process so difficult that we need a full support page for it? https://adoptium.net/docs/eca-sign-off/). As in fix the Eclipse process to be easier, so less documentation is required.

@smlambert
Copy link
Contributor

@CarmenDelgadoEclipse - can you check with Tanya or others at Eclipse how does this work? https://youtu.be/eSY6Uo62IH8?t=27 - that is someone is already working for a company who has signed an agreement, they do not need to do anything? We have not found this to be sufficient, since all PRs to all Eclipse project repos pass through the ECA validation tool (eclipsefdn/eca) and fail in the case where people have followed the instruction of "you do not need to do anything".

@CarmenDelgadoEclipse
Copy link
Author

@smlambert about your doubt this is the answer from the Eclipse team:
This is the answer from @chrisguindon : Employees covered by an MCCA don't need to sign an ECA. If notice somewhere where that's not the case, please share links or reproducible steps and we will investigate!
One important step is when the contributor/author follows the registration process they need to indicate that they work for the company that has already signed the MCCA (Eclipse Member Committer and Contributor Agreement).
If you know a specific case with this issue, please report them to the EF team, so they can solve the problem (IT or EMO).
I hope this helps!

@smlambert
Copy link
Contributor

One important step is when the contributor/author follows the registration process they need to indicate that they work for the company that has already signed the MCCA (Eclipse Member Committer and Contributor Agreement).

where is that described, as we should link to the documentation for how to do that

@CarmenDelgadoEclipse
Copy link
Author

According to @chrisguindon, but he will confirm with membership team:

  1. When a company is registered as a new member, it becomes possible for employees to update their employer in their account to indicate that 1) They work for an Eclipse Members and 2) which one. Once their account is updated, they would be automatically covered by an ECA if their employer has a valid MCCA on file with us.
  2. Company reps can visit our Member portals to view a list of users who indicated that they work for them. They must inform us if someone is someone is incorrectly listed. Zahra should also be able to help with the Membership Portal if they have questions about it!

@CarmenDelgadoEclipse
Copy link
Author

If you don't want to just download Temurin define a proper flow:

  • Evaluate the current flow, and define a new one for these users.
  • Improve about us

@smlambert
Copy link
Contributor

smlambert commented Mar 2, 2023

@CarmenDelgadoEclipse re: #1253 (comment), I guess we need to check:

  1. who is the Red Hat rep or EF person that would have access to check our agreements
  2. ask them to make sure they have properly set up the MCCA (Eclipse Member Committer and Contributor Agreement)

I am seeing many examples of Red Hat employees that we are on-boarding into Adoptium that have indicated in their profile that they work for Red Hat, but they are still needing to sign the ECA before we can merge their PRs (including myself). (see adoptium/aqa-tests#4280 as one example). Since we will be on-boarding more Red Hat folks to the project over the coming months, it would be nice to get this figured out.

Further to this, is there a way to survey all of the member companies, to ensure they have set things up correctly, if we proactively check them all, it could greatly reduce the aggravation to contributors and committers.

@CarmenDelgadoEclipse
Copy link
Author

@chrisguindon can you help us here? #1253 (comment)

@waynebeaton
Copy link

waynebeaton commented Mar 2, 2023

I am seeing many examples of Red Hat employees that we are on-boarding into Adoptium that have indicated in their profile that they work for Red Hat, but they are still needing to sign the ECA before we can merge their PRs (including myself). (see adoptium/aqa-tests#4280 as one example). Since we will be on-boarding more Red Hat folks to the project over the coming months, it would be nice to get this figured out.

I looked a little deeper into this example. This particular contributor specified their employer in this manner:

image

Now, of course, they have no way of knowing that this doesn't actually hook up the MCCA. While they do indeed specify that their employer is Red Hat, they've done so as an "Other".

What we need folks to do is to specify that they "Work for a Member Company" and pick their employer from the list:

image

We need to do a better job with this. @chrisguindon, I don't think that we can assume that an arbitrary person will necessarily understand the significance of "Work for a Member Company".

In the meantime... workarounds...

  • If somebody from Red Hat can send us a list of names (and, ideally, email addresses), to [email protected], we can fix the records;
  • I'll see if I can come up with a short description that you can share with your colleagues to help them get this right next time;
  • Chris, can we query for folks who have manually entered some version of "Red Hat" as an "Other" employer and send that to EMO Records as a starting point?
  • I've opened an issue to track a UX update.

@chrisguindon
Copy link

chrisguindon commented Mar 2, 2023

I took a closer look at our logs to better understand the steps that the user took for adoptium/aqa-tests#4280

I can see that the account was created on 2023-01-26 11:57:19 AM EST and the MR was created on Jan 26, 2023, at 11:32 AM EST. The ECA was signed at 16:02:37 EST. In this situation, the ECA had to fail since when the MR was created, we had no record. T

This tells me that the problem, in this case, originated on our "Create an Eclipse Account" form. On that page, the default value is set to others and I believe that most users simply type the name of their organization because we offer a text field by default.

A good start, before re-design this field would be to remove the default for the "What is your employment status?" field on the create my account form to force the user to read the options and pick the one that applies.

I believe this small change could reduce some errors while we work on re-design this field which will take longer.

@chrisguindon
Copy link

chrisguindon commented Mar 2, 2023

Chris, can we query for folks who have manually entered some version of "Red Hat" as an "Other" employer and send that to EMO Records as a starting point?

I can provide a list of all the user accounts on accounts.eclipse.org with an @redhat.com email address.

We would then need to compare that data with the Foundation DB which is where this relationship is actually tracked.

I will start by sending you a list of user accounts on accounts.eclipse.org.

@smlambert
Copy link
Contributor

Thanks to both of you, Wayne and Chris, for taking a look at this.

@pandenaman007
Copy link

Hi I am replying on the issue #1561
According to me we should place the "want to join" button at the starting of the webpage rather than at the end as the user would have to scroll all the way down in the same way as the Eclipse foundation page is designed. We can have two button placed side-by-side one of "want to join" and the other should be about the contact for the membership. These should be at the top of the page just like that of the page of The Eclipse Foundation. For the "want to sponsor" we can place that one at the end of the webpage. This can be the improvements over the current format.

@CarmenDelgadoEclipse
Copy link
Author

About this idea:
Have a description of how to collaborate with the project, like Jakarta EE: https://jakarta.ee/community/get-involved/, I know we have some information in this Github space and also on the web, but we need clearer and simpler information. (editing notes: the Jakarta example is not about the look an feel is a way they are sharing the information :)) simple card with the level of involvement).

This talk gives some interesting insides: https://program.foss-backstage.de/fossback23/talk/XAUMNL/
Onboarding UX

@pandenaman007
Copy link

Okay Ma'am I will just check the resources you mentioned and will get back to you on this issue. Thanks a lot for your kind support.

@smlambert smlambert changed the title Ideas to improve website information and user flow EPIC: Ideas to improve website information and user flow Mar 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants