EPIC: Ideas to improve website information and user flow

[CarmenDelgadoEclipse]

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:

• 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 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 he level of involvement).
• Improve first timers https://adoptium.net/es/docs/first-timer-support/, move this to a specific space within the web. Ther is already a ticket for this one #1151
• Have more information about how the project works. We have this https://github.com/adoptium/adoptium and some blog posting and Eclipse foundation page https://projects.eclipse.org/projects/adoptium, but we could have easy-to-understand information on the website.
• Easier to find other JDK versions.
• Improve the "Donate" bottom allocation in the Adoptium.net/download
• Add new project: Incubator and migration toolkit. https://projects.eclipse.org/projects/adoptium.incubator
• Create an "Adopter page", a free badge for Temurin users, as: https://ecdtools.eclipse.org/adopters/ or https://iot.eclipse.org/adopters/
• Community vocabulary: Ideal for new contributors during their onboarding process, "never give for granted that people understand all the acronyms" community-specific terms, acronyms, or jargon. such as: LSA, SSDF, SBOM stand for, and what does PMC, WG, (Eclipse documentation to point to describe PMC, WG, ECa, and other EF Acronyms), etc.

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:

• Access to the latest JDK version released: #1564
• When looking at the released version page, remember the filter choice of preference: download page lacks checksum info #1643

[smlambert]

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]

@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]

@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]

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]

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]

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]

@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]

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

[waynebeaton]

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:

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:

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]

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]

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]

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

[pandenaman007]

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]

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/

[pandenaman007]

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.