Starting a team for the package examples initiative

Start by reviewing the proposal and its references to nodejs/package-maintenance, nodejs/node-addon-examples, and e18e.dev. Clarify whether this repository should form a new team or a subteam, then define the team name, membership rules, and temporary write-access arrangement. Done means the organizational scope and setup plan have been agreed.

Proposed goals of this initiative:

1. Identify and document package shipping patterns in the ecosystem (e.g. how people write their package.json). This is primarily about patterns in generic Node.js packages. For specific patterns of packages developed for various frameworks, or plugin packages etc. this repository can point readers to credible sources, but the source of truth for them should be hosted elsewhere (ideally in respective projects themselves).
2. Write and maintain guides/tutorials/examples in this repository on how to ship various kind of packages e.g. how to write package.json for different consumers, how to perform certain package migrations e.g. from shipping CJS to shipping ESM. Personally I am a fan of the mini tutorial book + folders full of working examples approach in https://github.com/nodejs/node-addon-examples and I hope we can do something similar here.
3. Providing a venue for folks to discuss about the patterns and ask questions about package shipping, and aid ecosystem cleanup efforts such as https://e18e.dev/

This is largely inspired by the NAPI effort, I think the NAPI team did a great job in putting out practical guides and resources for the NAPI migration, which was indispensable for the success of NAPI, and I hope we can learn from their success to help with the CJS -> ESM migration :)

Previously there was the @nodejs/package-maintenance team but the goals in https://github.com/nodejs/package-maintenance look very different and have a different audience. So I propose that we start a new team, which could be either a subteam under @nodejs/package-maintenance or just a different one, ideally involving maintainers of package tooling/package managers into the discussions to make sure that we are on the same page. Maybe it can be called @nodejs/package-examples , or @nodejs/package-patterns or a better name? (personally, it feels weird to me to have "examples" in the name of a team, so @nodejs/package-patterns sounds better).

About the joining this team: from previous experience (e.g. starting the automation team), I learned that if we just create a team and just add anyone who sign up to the team (i.e. including those who were not participating in anything in the organization), it's easy to end up with a team where most people were only active during the signup phase and after that >80% of the people don't respond to pings, and we ended up disbanding the largely inactive team and formed a smaller team with those who were active instead. To prevent that from happening again, I propose that we set up some simple rules:

1. Anyone already in @nodejs/package-maintenance @nodejs/loaders @nodejs/tsc (and other related teams that I am forgetting, feel free to nominate) can be added directly
2. Anyone who's not already part of 1 can be nominated by existing members with a simple explanation issue about why they should join.

While we are setting up this team, I propose that we grant write access to @nodejs/package-maintenance @nodejs/loaders and @nodejs/tsc to this repository, and the reviews etc. are delegated to existing teams. After the new team has gone through the initial setup phase and we have something up and going, we can switch the write access to that team.