You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Expand CODEOWNERS to each learn section owner/advocate #7292
Note that we can only take action on this when we have clearly defined the learning path/graph and each subsection is associated with one or two teams max.
I'm not quite sure what is being asked of me in this issue? I think using the test_runner team as CODEOWNERS is fine if that's the question. It's worth noting though that none of the subsystem specific teams actually represent expertise in that subsystem. It just means that those people have subscribed to notifications.
It just means that those people have subscribed to notifications.
And have to approve PRs
In Node Core, being part of the team does not grant any particular ownership.
It simply provides an easier way to manage notifications.
As far as I know, a team member's approval doesn't have any specific effect @AugustinMauroy.
Node core actually looked into leveraging CODEOWNERS years ago. That was exactly the problem though. Any collaborator can join any team and approve things... which defeats the whole purpose of CODEOWNERS.
Node core actually looked into leveraging CODEOWNERS years ago. That was exactly the problem though. Any collaborator can join any team and approve things... which defeats the whole purpose of CODEOWNERS.
That another question. IDK if there are a way to disable self joining team. EDIT: we cannot "join as it" we can request to join. IDK who approve that but there are a step before joining any team
But for now we need someone that take care of nodejs learn content and it's why we use CODEOWNERS
In my view, the best approach comes down to one of two options:
Option A:
Add the relevant teams to the CODEOWNERS file without giving them write access. Then, like in the core repo, use a bot to ping those teams for the files they "own." This wouldn't require a CODEOWNER approving review unless the team has write access (i.e. TSC, Web, etc).
Option B (My favorite):
As suggested in #7294, map each Learn article to a core API (e.g., api: fs in the frontmatter). GitHub Actions would then link each API to a specific team (e.g., fs → @nodejs/fs). A bot would ping the appropriate team based on the APIs mentioned in the article.
Option B:
As suggested in #7294, map each Learn article to a core API (e.g., api: fs in the frontmatter). GitHub Actions would then link each API to a specific team (e.g., fs → @nodejs/fs). A bot would ping the appropriate team based on the APIs mentioned in the article.
Not too bad idea. But what should we do for section that didn't have any specific topics/api
But what should we do for section that didn't have any specific topics/api
We'd cross that bridge when we get there. It would be the same situation if we used CODEOWNERS. Currently, the website team becomes the default editorial authority.
I'm strongly opposed with the CODE OWNERS approach and I'm firmly a -1 here. I don't understand why y'all are ignoring my suggestions of using nodes/node bot that pings the right teams without needing to change code owners and give write access to all these teams.
I'm fine removing my -1 if we all believe the code owners is truly the best approach.
I'm strongly opposed with the CODE OWNERS approach and I'm firmly a -1 here. I don't understand why y'all are ignoring my suggestions of using nodes/node bot that pings the right teams without needing to change code owners and give write access to all these teams.
I'm fine removing my -1 if we all believe the code owners is truly the best approach.
That was my suggestion:
Add the relevant teams to the CODEOWNERS file without giving them write access. Then, like in the core repo, use a bot to ping those teams for the files they "own."
A bot would ping the appropriate team based on the APIs mentioned in the article.
I'm also a strong -1 on giving teams write access.
Add the relevant teams to the CODEOWNERS file without giving them write access. Then, like in the core repo, use a bot to ping those teams for the files they "own."
Activity
bmuenzenmeyer commentedon Nov 29, 2024
@AugustinMauroy identified these already
test-runner should be under the test-runner team
typescript should be under typescript team
AugustinMauroy commentedon Nov 30, 2024
Note that we can only take action on this when we have clearly defined the learning path/graph and each subsection is associated with one or two teams max.
AugustinMauroy commentedon Dec 2, 2024
I've added it to the agenda to get their opinion on the matter.
marco-ippolito commentedon Dec 18, 2024
No problem with adding @nodejs/typescript as codeowner of the typescript related content for review
AugustinMauroy commentedon Jan 10, 2025
ping @nodejs/test_runner to move forward on this issue
pmarchini commentedon Jan 11, 2025
Hey @AugustinMauroy, no problem for me regarding @nodejs/test_runner.
I'd suggest collecting some thoughts from @cjihrig, @MoLow, @atlowChemi, and @jakecastelli as well.
JakobJingleheimer commentedon Jan 12, 2025
I'm happy to do, although I'm not as active an implementer as Chemi, Colin, and Moshe.
cjihrig commentedon Jan 12, 2025
I'm not quite sure what is being asked of me in this issue? I think using the test_runner team as CODEOWNERS is fine if that's the question. It's worth noting though that none of the subsystem specific teams actually represent expertise in that subsystem. It just means that those people have subscribed to notifications.
AugustinMauroy commentedon Jan 12, 2025
And have to approve PRs
pmarchini commentedon Jan 12, 2025
In Node Core, being part of the team does not grant any particular ownership.
It simply provides an easier way to manage notifications.
As far as I know, a team member's approval doesn't have any specific effect @AugustinMauroy.
cjihrig commentedon Jan 12, 2025
Node core actually looked into leveraging CODEOWNERS years ago. That was exactly the problem though. Any collaborator can join any team and approve things... which defeats the whole purpose of CODEOWNERS.
AugustinMauroy commentedon Jan 12, 2025
That another question. IDK if there are a way to disable self joining team. EDIT: we cannot "join as it" we can request to join. IDK who approve that but there are a step before joining any team
But for now we need someone that take care of nodejs learn content and it's why we use CODEOWNERS
4 remaining items
avivkeller commentedon Jul 21, 2025
In my view, the best approach comes down to one of two options:
Option A:
Add the relevant teams to the
CODEOWNERSfile without giving them write access. Then, like in the core repo, use a bot to ping those teams for the files they "own." This wouldn't require a CODEOWNER approving review unless the team haswriteaccess (i.e. TSC, Web, etc).Option B (My favorite):
As suggested in #7294, map each Learn article to a core API (e.g.,
api: fsin the frontmatter). GitHub Actions would then link each API to a specific team (e.g.,fs→@nodejs/fs). A bot would ping the appropriate team based on the APIs mentioned in the article.WDYT?
AugustinMauroy commentedon Jul 21, 2025
Not too bad idea. But what should we do for section that didn't have any specific topics/api
avivkeller commentedon Jul 21, 2025
We'd cross that bridge when we get there. It would be the same situation if we used CODEOWNERS. Currently, the website team becomes the default editorial authority.
AugustinMauroy commentedon Jul 21, 2025
what about a
@nodejs/website-content?ovflowd commentedon Jul 21, 2025
I'm strongly opposed with the CODE OWNERS approach and I'm firmly a -1 here. I don't understand why y'all are ignoring my suggestions of using nodes/node bot that pings the right teams without needing to change code owners and give write access to all these teams.
I'm fine removing my -1 if we all believe the code owners is truly the best approach.
AugustinMauroy commentedon Jul 21, 2025
I agreed with you for the bot but it's didn't change the question about who we need to ping
avivkeller commentedon Jul 22, 2025
That was my suggestion:
I'm also a strong -1 on giving teams write access.
ovflowd commentedon Jul 23, 2025
Oh I misread lol 😅