Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transform the Website Team into a "Web Team" #806

Closed
ovflowd opened this issue Jun 15, 2023 · 22 comments
Closed

Transform the Website Team into a "Web Team" #806

ovflowd opened this issue Jun 15, 2023 · 22 comments

Comments

@ovflowd
Copy link
Member

ovflowd commented Jun 15, 2023

It's been a long while since I've thought that the Website Team would be better leveraged as instead "a group of people that make contributions to the website repository" into "a group of people with knowledge of web standards and that leverage the web infrastructure and technology of Node.js".

The main difference is that I believe we can better serve other WGs, Teams, Strategic Initiatives and the TSC by becoming a WG that is responsible for maintaining high-quality web standards for anything Web-related on Node.js.

The key differences are that:

  • Instead of being a "Website Team" and coupled to the "website" repository, the Web Team would be there to support Node.js Core with Web-facing infrastructure and Development (for example, the tooling needed for API Docs, Microsites).
  • The Web Team would be responsible only for the technology used for Web-facing infra, services and tooling used and/or owned by the Node.js org.
  • One of my personal goals is that the Team can be highly useful for the TSC when it comes to deferring questions related to Web Development.
  • By transforming the Website Team into the Web Team we can welcome people more contributors, from Design/UX champions to people with a high-level understanding of the EcmaScript living spec.
    • In other words, the Web Team can be a centralised point of reference when Node.js needs to deal with questions that are faced with the current state of the Web.

It's also implied that the responsibilities of the Web Team switch from being mainly focused on maintaining and developing the Node.js Website and its content/layout, to ensuring that the Node.js Website (and any other Web technology used within any other team) upholds to best practices and modern/commonly used standards.

This effort would probably allow the team to grow and be able to better serve the project, as certain things within other teams (and the core itself) are in a grey area of who owns/maintains or is the key DRI for solving issues (infamously the API docs Web Infra on the nodejs/node).

This could also defer some of the current responsibilities of the Build WG (which are many) (like maintaining CloudFlare and NGINX configurations) to the Web Team (as they fall more on a Web technology realm, rather than "Build"). It would also allow the Web Team to be responsible for the Web-relate infra that we host a Vercel, for example.

The Web Team would also have sub-teams responsible for a specific key area-of-expertisé

  • web/nodejs-website (people that are most active in website development)
    • This would allow us to decrease the entry barrier, as the contributors in this sub-team are specifically tasked with working on the website, without necessarily having deep knowledge of web development
  • web/ux-and-design (people that champion UX and design and have deep knowledge of it)
  • web/web-standards (people with deep knowledge of Web Standards that can help with web standards when needed)
  • web/web-infra (people maintaining web infra such as Crowdin, Vercel, GitHub Pages, etc)
  • web (the parent team containing the maintainers and stakeholders of the web team, such as key people from the TSC that are delegates for web development)

I hope that this idea makes sense and I apologise for (pretty much) my poor explanation. I'd be more than happy to explain and dive deep into this idea if anyone needs more info, not to mention make alterations to this proposal if needed.

It's also an open question if with this set of responsibilities the Web Team would need to be re-charted into a Web WG. (Not sure if needed, but open to the possibility).

cc @nodejs/tsc
cc @nodejs/website
cc @nodejs/build

@Trott
Copy link
Member

Trott commented Jun 15, 2023

I like this idea. The one thing I'm not sure about is the utility of the subteams. I think GitHub calls them "child teams". If you're on a child team, you are basically on the parent team. You have the privileges of the parent team. I could be wrong, but I don't think there's a way to limit the child teams. Usually, it works the other way around. The child teams might be given more privileges. So I don't think we can put narrowly-scoped people with fewer privileges on a website-specific child team, for example. (Happy to find out I'm wrong about this, though!)

But I think that's OK. One possible solution is that the website team and the web team can just be separate things. (Maybe call it the web technologies team or something like that, to better distinguish from the website team?) It's not necessary for "people maintaining the website, making sure banners are up-to-date and correctly worded, etc." and "people who understand web standards, etc." to be the same team. Those can be two different teams.

Another possible solution is that I'm making an incorrect assumption and the people on the web team do not have broader privileges than anyone else--they just have broader expertise. But I do think that mixing the two teams and giving them both write privileges to the same repos is probably not the way to go.

Or at least that's my thinking right now.

As for everything else in the post, I think I'm 💯 on all of it.

@Trott
Copy link
Member

Trott commented Jun 15, 2023

(Maybe we can start with just creating a web technologies team that is separate form website team, leave out all the subteams for now, and revisit at a later daete?)

@mhdawson
Copy link
Member

I'd definitely be +1 on the formation of a web technologies team separate from the website team.

@ovflowd
Copy link
Member Author

ovflowd commented Jun 23, 2023

Can wee add this to the TSC agenda?

@aduh95
Copy link
Contributor

aduh95 commented Jun 23, 2023

Can wee add this to the TSC agenda?

You (or anyone) can add the tsc-agenda label and add a comment explaining what you expect from TSC discussion on this issue.

@ovflowd
Copy link
Member Author

ovflowd commented Jul 11, 2023

You (or anyone) can add the tsc-agenda label and add a comment explaining what you expect from TSC discussion on this issue.

I didn't have permissions to add it, now I have apparently.

@targos
Copy link
Member

targos commented Jul 11, 2023

@aduh95 Only TSC members (+ moderation team as they are org owners) can add labels here.

@tniessen
Copy link
Member

Would the web-standards team also be for, e.g., the ECMAScript specification and standards developed by WinterCG? Or is there some specific set of web standards (such as CSS or so that are less relevant for non-website folks) that you had in mind?

On a side note, would it make sense to have separate teams for the website content and the website frontend stuff? I originally joined the website team to review and keep track of content, but I have repeatedly considered leaving the team because it's become incredibly noisy, and most notifications are about frontend stuff and not content.

@ovflowd
Copy link
Member Author

ovflowd commented Jul 11, 2023

Would the web-standards team also be for, e.g., the ECMAScript specification and standards developed by WinterCG? Or is there some specific set of web standards (such as CSS or so that are less relevant for non-website folks) that you had in mind?

The first one. That would pretty much be composed by people we know we can request advise on current ES standards. Such as @ljharb

On a side note, would it make sense to have separate teams for the website content and the website frontend stuff?

Afaik content is not handled by the Website Team, as per https://github.com/nodejs/nodejs.org/blob/main/CONTENT_VS_CODE.md. If you believe we should have a dedicated team for that, that's fine.

but I have repeatedly considered leaving the team because it's become incredibly noisy, and most notifications are about frontend stuff and not content.

I bet! We're being super noisy right now!

@ovflowd ovflowd closed this as completed Jul 11, 2023
@ovflowd ovflowd reopened this Jul 11, 2023
@ovflowd
Copy link
Member Author

ovflowd commented Jul 11, 2023

accidentally hit a combo of keyboard keys that closed the issue??

@tniessen
Copy link
Member

Thanks for clarifying @ovflowd, that makes a lot of sense :)

I bet! We're being super noisy right now!

Lots of improvements 🥳

@mcollina
Copy link
Member

approved in the TSC meeting

@mcollina mcollina reopened this Jul 26, 2023
@ovflowd
Copy link
Member Author

ovflowd commented Jul 27, 2023

@mcollina let me do the team arrangement then 👀

Edit: I also probably need to find the right documents that need to be updated.

@Trott
Copy link
Member

Trott commented Sep 9, 2023

Website team renamed to Web and the four proposed child teams created.

image

I strongly recommend having no one in the parent team. It's not necessary. By having membership in the parent team come from child teams only, it makes the parent team easier to manage. People in the child teams are members of the parent teams as far as GitHub is concerned. So this way, when someone is removed from all child teams, they are automatically removed from the parent team.

If you do have people in the parent team, make it just the one person responsible for the team (Claudio).

That's my suggestion, anyway. It's fine if you do it differently.

I'll make sure Claudio is a maintainer of the child teams so he can manage memberships. (He already can do so because of Moderation Team privileges, but I want to make it official and also make sure that if he decides to step off the Moderation Team, he still has the privileges he needs for Web team stewardship.)

At this point, I think Claudio (and/or other people) need to PR in some doc changes to reflect the name and maybe some of the child team roles, but other than that, this can be closed. If so, Claudio, feel free to close it. If not, let us know what else needs to happen. Thanks so much for all you do!

@ovflowd
Copy link
Member Author

ovflowd commented Sep 9, 2023

At this point, I think Claudio (and other people) need to PR in some doc changes to reflect the name and maybe some of the child team roles, but other than that, this can be closed. If so, Claudio, feel free to complete it. If not, let us know what else needs to happen. Thanks so much for all you do!

Thanks, Rich! I'll close this once all changes introducing the roles of each team mean and update all relevant docs and mentions to the website team!

@tniessen
Copy link
Member

tniessen commented Sep 27, 2023

@ovflowd To clarify, should we invite people to @nodejs/web-standards who are experts on any web-related standard that might be relevant to the Node.js project? For example, @panva is an awesome resource for all things WebCrypto.

@ovflowd
Copy link
Member Author

ovflowd commented Sep 27, 2023

@ovflowd To clarify, should we invite people to @nodejs/web-standards who are experts on any web-related standard that might be relevant to the Node.js project? For example, @panva is an awesome resource for all things WebCrypto.

Yes! I invited already a few folks, but feel free to invite more trusted people at your discretion :)

@tniessen
Copy link
Member

Thank you for clarifying @ovflowd! When I try to invite existing collaborators to @nodejs/web-standards, GitHub warns me that this action will grant write access to the https://github.com/nodejs/nodejs.org repository. However, my understanding is that this team is not directly related to the website. It looks like this might be inherited from the Web team. Is this intended?

@ovflowd
Copy link
Member Author

ovflowd commented Sep 27, 2023

Let me check that!

@ovflowd
Copy link
Member Author

ovflowd commented Sep 27, 2023

Done, permissions updated! Seems like I forgot to remove that from there.

@tniessen
Copy link
Member

Thank you @ovflowd :)

@ovflowd
Copy link
Member Author

ovflowd commented Nov 27, 2023

I think this can be closed now!

@ovflowd ovflowd closed this as completed Nov 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants