[Feature] Show the role of orgs that contribute to a challenge ⭐

[tschaffter]

What product(s) is this feature for?

OpenChallenges

Description

On a challenge page, we show all the orgs that contributes to it without showing their role(s). The goal of this ticket is to show this information to the users. The information is already made available to the web app by the backend.

Tasks:

• Design
• Frontend implementation

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[vpchung]

Expanding on #1666 , I have come up with a couple of options:

Option 1

Update the layout of the Contributors page/section:

Option 2

Update the organization card. With this, there are 3 proposed changes:

1. replace the organization members with the organization role
2. add the role to the card, not replacing any existing elements
3. replace the footer info (# of contributions) with the role

@tschaffter @rrchai @gaiaandreoletti @mdsage1

[vpchung]

^ currently working with Adam to see which option(s) would be better and/or more user-friendly. Stay tuned.

[tschaffter]

One think to keep in mind is that an org can have more than one contributor role (e.g. data provider AND Challenge Organizer).

[rrchai]

On the profile page, option 1 seems a better option with less adjustment on the UI of org card and easier navigation for roles.

On the org search page, I feel the option 2.2 is too long and condensed with both roles and members info.
I prefer option 2.3 (replace the footer info (# of contributions) with the role) if we do need to display member info, but I like "# of challenges" as well TAT. Do you think if replacing the "# of challenges" by an icon will fit?

[vpchung]

On the org search page

To be clear, the intention was for the card design to only change when it's loaded on the profile page. When on the search org page, the design will remain as it is currently. I don't know the feasibility of this idea though.

On the profile page, option 1 seems a better option

I agree; I think Option 1 would be the easiest to implement and maybe the most user-friendly? option.

[tschaffter]

Option 1 has several benefits:

• We can continue to use the org card
• The data we get from the backend are easy to split for the different contribution type, then we iterate on these lists to render the cards for each section

[vpchung]

10/27 update

I haven't heard back from Adam yet, but I think we all agree that Option 1 would be the best (and safest) choice to move forward with

EDIT: The UI portion for the feature will be tracked in #2284

[tschaffter]

Added to Sprint 23.11