feat: sort contributors list by role #1369
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
📝 WalkthroughWalkthroughThe pull request updates two areas. server/api/contributors.get.ts introduces a Role type, a roleMembers mapping and getRoleInfo to assign roles; contributors are assigned a 🚥 Pre-merge checks | ✅ 1✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
|
Note: I thought I was looking at an issue 🤦🏼
|
|
It would be good to also show for governance folk their github, npm, etc too. Maybe at one point we find a way to do it for everyone once we have more people connecting their accounts together. 
One interesting discussion, we decided to remove the sponsors button for stewards in the main page of the repo. It didn't feel right that we were the only ones having the exposure there. But maybe we could add them back for everybody (or as many of us as possible, maybe first governance, later when people connect to github we could do better). I think we need to start trying to start working to help with OSS funding. I don't think people will give us a lot of money through this, I care more about the symbol that we should show that money is needed for npmx to work. It will also get better once we can start adding sponsors (soon!). |
|
Now that I know this is a PR, I checked how it looks :D So, we could merge this and iterated, but I would like we show the governance structure as a way to explain that npmx takes the foundation route seriously. So we should have Stewards first as a title, then Maintainers, then everyone else. Maybe with a short paragraph. And it could give us an option to do bigger cards for maintainers so we can show that they work in different companies and what other projects they participate in. Let's use this as a way to show that we are the result of uniting a lot of communities. |
|
It actually is a PR😄 Yes, this can be imrpoved iteratively. I also think about adding sections similar to https://github.com/npmx-dev/npmx.dev/blob/main/GOVERNANCE.md and we could add links to this docs later. |
|
Also, once npmx's profile page mature, we could link to the profile page |
|
I'm thinking that for the first iteration, until we have a core team, the best is if we only have two sections: TeamGovernanceDaniel Me [ ...maintainers ] <-- all with the same card size, just the role is diff ContributorsAll other contributors, maybe including the above too as a way to show we are all part of the team |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
server/api/contributors.get.ts (1)
1-8:⚠️ Potential issue | 🟡 MinorType mismatch between API response and interface
The
GitHubContributorinterface now requires arolefield, but the GitHub API response at line 49 does not include this property. Casting directly toGitHubContributor[]is type-unsafe since the objects won't haveroleuntil line 72.Consider defining a separate type for the raw API response:
🛡️ Proposed fix for type safety
+type GitHubAPIContributor = Omit<GitHubContributor, 'role'> + export interface GitHubContributor { login: string id: number avatar_url: string html_url: string contributions: number role: Role }Then at line 49:
- const contributors = (await response.json()) as GitHubContributor[] + const contributors = (await response.json()) as GitHubAPIContributor[]And update the
allContributorsarray type accordingly.Also applies to: 49-49
🧹 Nitpick comments (3)
app/pages/about.vue (3)
147-147: Consider extracting the governance filter to a computed propertyThe filter
c => c.role !== 'contributor'is used in multiple places (lines 147, 156–161). Extracting this to a computed property would improve readability and ensure consistency.♻️ Suggested refactor
In
<script setup>:const governanceMembers = computed(() => contributors.value?.filter(c => c.role !== 'contributor') ?? [] )Then in the template:
- <div v-if="contributors?.some(c => c.role !== 'contributor')" class="mb-12"> + <div v-if="governanceMembers.length" class="mb-12">- v-for="person in contributors.filter(c => c.role !== 'contributor')" + v-for="person in governanceMembers"
141-144: Consider using i18n keys for the "Team" headingThe hardcoded "Team" string at line 141 should use an i18n key for consistency with the rest of the page, which uses
$t()for all user-facing text.
148-148: Consider using i18n key for "Governance" headingSimilar to the "Team" heading, "Governance" should use an i18n key for internationalisation consistency.
| TODO: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor | ||
| incididunt ut labore et dolore magna aliqua. | ||
| </p> |
There was a problem hiding this comment.
Remove placeholder TODO text before merging
There are multiple instances of raw placeholder text that will be visible to users:
- Lines 150-152: "TODO: Lorem ipsum..." in the Governance section
- Line 178: "TODO: add other maintainers" rendered directly in the grid
- Lines 192-193: "TODO: Lorem ipsum..." in the Contributors section
These should be replaced with proper i18n keys or removed.
Also applies to: 178-178, 192-193
| v-for="person in contributors | ||
| .filter(c => c.role !== 'contributor') | ||
| .concat(contributors.filter(c => c.role !== 'contributor')) | ||
| .concat(contributors.filter(c => c.role !== 'contributor')) | ||
| .concat(contributors.filter(c => c.role !== 'contributor')) | ||
| .concat(contributors.filter(c => c.role !== 'contributor'))" | ||
| :key="person.id" |
There was a problem hiding this comment.
Remove debug .concat() chain — causes duplicate keys and 5× repeated entries
The repeated .concat() calls duplicate governance members five times, which will:
- Cause Vue key warnings since
:key="person.id"will have duplicates - Render the same people multiple times in the UI
- Degrade performance with unnecessary iterations
This appears to be debug/test code that should be removed before merging.
🐛 Proposed fix
<a
- v-for="person in contributors
- .filter(c => c.role !== 'contributor')
- .concat(contributors.filter(c => c.role !== 'contributor'))
- .concat(contributors.filter(c => c.role !== 'contributor'))
- .concat(contributors.filter(c => c.role !== 'contributor'))
- .concat(contributors.filter(c => c.role !== 'contributor'))"
+ v-for="person in contributors.filter(c => c.role !== 'contributor')"
:key="person.id"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| v-for="person in contributors | |
| .filter(c => c.role !== 'contributor') | |
| .concat(contributors.filter(c => c.role !== 'contributor')) | |
| .concat(contributors.filter(c => c.role !== 'contributor')) | |
| .concat(contributors.filter(c => c.role !== 'contributor')) | |
| .concat(contributors.filter(c => c.role !== 'contributor'))" | |
| :key="person.id" | |
| v-for="person in contributors.filter(c => c.role !== 'contributor')" | |
| :key="person.id" |
There was a problem hiding this comment.
no problem, this is just a stub for this WIP commit
There was a problem hiding this comment.
@shuuji3, understood! Thanks for clarifying — I'll let this pass as WIP stub code. Feel free to clean it up before the final merge. 👍
|
I've created a simple mini cards (icon + name + role) for governance section as a starting point. Should I use this same card format for all contributors, or keep the current contributors cloud? I'll collect the maintainers GitHub handles from Discord and hardcode them (tomorrow). Also, could you provide the short paragraphs for each sections? I'm not sure what the best wordings. 
|
3 participants
An attempt to sort contributors list by the governance role (steward > core > maintainer > contributor).
I cannot find a public member list of the maintainers so kept it empty for now.
One option to avoid hardcoding is to create GitHub Team for each governance role, and create members list in GitHub Actions with command like
gh api /orgs/npmx-dev/teams/steward/members --jq 'map(.login)./cc @patak-dev @userquin
(ref. original chat: https://bsky.app/profile/patak.dev/post/3mek245m7as26)