-
Notifications
You must be signed in to change notification settings - Fork 1
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
Starting a team for the package examples initiative #3
Comments
I'm happy to join and I have https://github.com/JakobJingleheimer/nodejs-module-config-examples to add 🙂 |
Following this development along to support in https://github.com/yuzhva/react-leaflet-markercluster |
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Proposed goals of this initiative:
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:
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.
The text was updated successfully, but these errors were encountered: