Show Developers, Support Reps and Contributors separated on single plugin page

[zodiac1978]

I would like to raise awareness for an issue I see on the plugin and profile pages:

We list every contributor for a plugin if the account name is added to the plugins readme.txt file - but there is no way to opt-out. And there is no way to differentiate between active and emerit contributors.

We also show every contributor on the plugin page, but without any specifics. On the profile page we differentiate between Developer, Contributor and Support Rep, but on the plugin page we just see a list of Developers & Contributors. You can also be Support Rep for this plugin without being listed here …

Therefore, I would recommend changing the list of “Contributors & Developers” on the plugin page according to the areas in the profile page as a first step:

• Developers: Everyone with commit access or ownership.
• Support Reps: Everyone marked as support rep for this plugin.
• Contributors: Everyone listed in the readme.txt as contributor (without all accounts already in “Developers” or "Support Reps" listed)

To my understanding this should be possible with the already existing data.

Active/Emerit contributors or opting-out of a listing needs changes to the header or something else, so I think this would be phase 2, if we want to have this feature.

What do you think?

[obenland]

I'd say the way to opt out would be to ask a plugin committer to remove one's name from the readme, what do you think?

[zodiac1978]

Replying to obenland:

I'd say the way to opt out would be to ask a plugin committer to remove one's name from the readme, what do you think?

Yeah, in a perfect world, this would be sufficient. I was thinking about the edge cases. Developer is not reacting, abandoned project, no time, ... and you don't want to be connected with the project anymore. But maybe I'm overengineering here.

[obenland]

Yeah, for those cases I'd recommend an email to plugins@….

[zodiac1978]

Replying to obenland:

Yeah, for those cases I'd recommend an email to plugins@….

Agreed!

Any thoughts about the other ideas?

[obenland]

I'd avoid separating contributors. Keeping them all in one section places a similar value to their contributions, regardless of their role.

[zodiac1978]

Replying to obenland:

I'd avoid separating contributors. Keeping them all in one section places a similar value to their contributions, regardless of their role.

If we do not separate them, there is no semantic differentiation possible. I don't know if you are a support rep, a committer, or you just contributed a fixed typo ...

Why do you think we shouldn't differentiate those roles? They have many different levels of commitment and responsibility to a plugin. I think we should show that. That's the whole point of this ticket.

[obenland]

I guess for me it comes down to not valuing contributions differently.

Core has tried for years to overcome the perceived difference between developer contributions, docs contributions, support forum volunteering, and so on. To me, it's a benefit that the plugin directory doesn't make that same distinction.

[zodiac1978]

Replying to obenland:

I guess for me it comes down to not valuing contributions differently.

Core has tried for years to overcome the perceived difference between developer contributions, docs contributions, support forum volunteering, and so on. To me, it's a benefit that the plugin directory doesn't make that same distinction.

On the new profile pages we do differentiate plugin contributions (Developer, Support Rep, Contributor) and we even value other contributions in med, high, etc. - how does this work together for you?

I would like to hear some other opinions to see if I am the only one with this view on this:
Ping @jonoaldersonwp @jeffpaul @_dorsvenabili @yaniiliev
(These people have reacted in Slack, so maybe they have opinions on this ...)

[zodiac1978]

I'd avoid separating contributors. Keeping them all in one section places a similar value to their contributions, regardless of their role.

I guess for me it comes down to not valuing contributions differently.

Core has tried for years to overcome the perceived difference between developer contributions, docs contributions, support forum volunteering, and so on. To me, it's a benefit that the plugin directory doesn't make that same distinction.

Let me try to make my point a bit clearer:

1. Unclear, untransparent information

There are clear semantic differences in the contributions between committer, support rep and general contributor. Core needed to overcome the ignorance of other contributions, this is not the case here. It just needs context. In Core this context is shown in the ticket for every contributor - Committer, Component Maintainer, etc.- are all recognizable via extra badge - but in the contributor list, there is no additional information.

Other platforms, like GitHub, are also showing via badge what is the role of the contributor.

2. Brand account misuse

Plugins are using there brand accounts as advertising possibility. A brand account shouldn't be eligible as a contributor, only as owner. This would be technical possible and would fix this abusing usage.

3. Show context of contribution

If your goal is to show all contributions equally no matter what, it looses the main point. People want to see their impact, gain reputation, get gratification - all this gets weaker, if you don't show why they are in this list.

4. Security Supply Chain

In the age of AI it gets more and more important to show the responsibilities and involements of each contributor. Do they have commit access, can officially answer (support) questions, etc. or are just contributor without more involvement for this plugin.

5. Cyber Resilience Act

Although there is no explicit rule for this, CRA is demanding transparency, clear responsibilities, etc. - and this will get more important in the future.

6. NIS2 (EU 2022/2555)

This EU rule demands supply chain risk management and if the roles are clear (committer vs. "just" contributor without commit access) it will be easier to get compliance.

7. Software Bill of Materials (SBOM)

In the SBOM there is a difference between Supplier, Maintainer, Author and Organization. If we need to provide SBOM it would be easier to have this differentiation between those roles.

8. SPDX (Software Package Data Exchange)

There is clear difference in the spec between Creator, Package Supplier and Originator for example.

9. SLSA / OpenSSF

This initiative is also differentiating between different roles, to show who can commit, release or maintain.

10. User Experience (UX) reputation analysis

As a user I want to know who is the owner, who can officially answer support questions and who has just provided code but has no other commitment/commit access. I need this information to evaluate the plugin.

11. Fairness

Showing each contribution equally devalues higher involvement. Especially if the contributor list is polluted by brand accounts devaluing the human involvement.

Conclusion

The user interface communicates with millions of end users. In that context, “Contributor” is generally understood to mean someone who has contributed to the software. If committers, support reps, and brand accounts are displayed together without distinction, it creates a false impression regarding responsibilities and actual contributions. A role-based display increases transparency, improves traceability, and meets today’s expectations for open-source projects and software supply chains.