nodejs / admin Goto Github PK
View Code? Open in Web Editor NEWAdministrative space for policies of the TSC
Administrative space for policies of the TSC
As a part of helping include and onboard CommComm members, the CommComm has created the "observer" group.
As per the normal workflow of GitHub, the @nodejs/community-committee group has been mentioned when opinions and review from members of the CommComm are needed. Something I've been frustrated about is how this reduces visibility for CommComm observers, effectively only enabling them to have eyes on things that happen in the CommComm repo and those that it oversees.
I recently brought up the idea of creating a broader team (ref: nodejs/community-committee#166), but there are a few issues with this. The way the CommComm membership flow is set up, it would effectively give Org membership (regardless of to anyone who came into the CommComm repo and requested to be an observer. This would also effectively provide a way to get around paying for Individual Membership with no contribution to the project - not that there's a reason people would want to at this point, but it does provide such a loophole.
We discussed this in yesterday's CommComm meeting, and the option we landed on was creating a way for such discussions to be monitored by observers. I know the TSC repo has the cc-review label, so it was suggested that we use that as a method for CommComm Observers to be able to have a bit more insight into the work we're doing in repos that aren't necessarily obvious.
I believe the only places that it would currently need to be added is nodejs/admin, nodejs/node, nodejs/code-and-learn (maybe?), nodejs/summit, and nodejs/nodejs.org. I can add it to nodejs/admin and nodejs/nodejs.org, but I also wanted to be sure we created this issue to get feedback and get approval if necessary 👍
the coc states that the [email protected] alias redirects to members of the TSC, which isn't accurate anymore, as it now redirects to the moderation team. this should be changed
I'd like to use GitHub's archive feature to archive https://github.com/nodejs/node-convergence-archive.
I'd also like to remove outside collaborators for that repo since there won't be any need for outside collaborators on a read-only repo.
Archiving can be undone so I don't think there's much need to tread with care here.
If no one on @nodjes/tsc or @nodejs/community-committee objects in the next 72 hours, I'll do it after that. Or someone else can do it if I forget about this entirely. :-D
Archiving is not explicitly addressed in our GitHub policy so I'm winging it here, but the 72-hours-with-no-objections rules makes sense to me. Happy to PR that in if others agree.
There's a tool created by @rvagg that is used by some top-level committees and some WGs to create meeting issues. I'd like to propose that we move this into the Node.js org. I know that Rod and Bryan had previously discussed Bryan moving it in (nodejs/make-node-meeting#19 (comment)), and I'd like to push this through to completion.
I've created this issue in nodejs/admin because the tool is used by the TSC and CommComm, and I assume there will need to be some governance discussion.
Situation:
Issue:
Questions:
/cc @nodejs/moderation @nodejs/community-committee @nodejs/tsc
Continuation of nodejs/node-review#2
This is used pretty heavily by collaborators, and it'd be great to get it published on the Chrome/Firefox/Edge stores.
Moderation team members must recertify every year. They also should have a process for leaving, if they are no longer able or want to continue to participate.
Document:
Hi, I have created these two npm packages that export the eslint rules of node core:
Most of their sources are automatically generated from the source of the node core. I want to see how we can use these rules for other projects in the foundation. I believe with a unified coding style it would be easier for people to start contributing to them. AFAIK node-core-utils uses something that mimics the node core styles (but not quite), so I can start from there.
Action items:
@nodejs
scope belongs to us? But I don't know who is the admin). We could also just use eslint-config-node-core
or eslint-plugin-node-core
(I've placed placeholders in both. My packages are currently published under @joyeecheung
though), that way the config name would be shorter, just node-core
, compared to @nodejs/eslint-config
What do you think?
Seems like we still have a copy in the TSC repo, and the main Nodejs repo is still pointing to it
I propose we use a label across the organization to track membership changes: e.g. Node.js core collaborator nominations, TSC nominations, membership changes in other working groups/teams, so it's easier to find those issues and review them at the end of a year.
Hi, I am wondering
I propose for initiating local Nodejs community chapters around the Globe like - Google Developers Groups, Facebook Developers Circles, etc.
Benefits -
I don't know whether Nodejs foundation has any already plans regarding this, but we can officially/or unofficially start a Nodejs Open Community like NodeSchool and meanwhile reach more audience and developers.
Per the defined process:
This list should be reviewed and pruned annually (at minimum). The calendar has a yearly recurring event on Jan 31st for this. An issue should be opened asking the calendar maintainers for their continued volunteering efforts (directly @-mention all members). After 1 week, this list should be PRed removing members that did not respond.
... it's time! So...
@gibfahn - Gibson Fahnestock
@hackygolucky - Tracy Hinds
@jasnell - James Snell
@joshgav - Josh Gavant
@mcollina - Matteo Collina
@mhdawson - Michael Dawson
@nebrius - Bryan Hughes
@ryanmurakami - Ryan Lewis
@sam-github - Sam Roberts
@Trott - Rich Trott
@williamkapke - William Kapke
@bnb - Tierney Cyren
Please reply to this thread with a +1
... or 👍 reaction... or whatever you want to give a positive indication that you're still available to help maintain the Calendar. It's that simple.
If you were recently added and it seems silly that you'd want to be removed - please just play along anyway 😆- this only happens annually
I'll be back in 7 days to tally up the replies and adjust the list.
On vacation? Missed this issue? Don't worry- it's super easy to get added back! (just open a PR)
Thanks for helping out!
The roadmap
team and repo are both inactive. The Roadmap WG was decommissioned some time ago. The team has one member, @fhemberger.
Any objection to deleting the team and archving the repo?
@nodejs/tsc @nodejs/community-committee
Team: https://github.com/orgs/nodejs/teams/roadmap
Repo: https://github.com/nodejs/roadmap
I'll wait at least 72 hours for objections from TSC and/or CommComm before acting on this.
Hi everyone! I thought it might be nice to know who's joined and find out what Groups and regions are represented. Here's a list I'll keep evolving until it is worth making in to markdown. Please feel free to edit directly (or comment in a reply any corrections.)
Want to join the efforts? Just request membership and then say hello in the comments below. Try to include what you've seen listed for other members.
@jasnell, James M Snell (IBM), USA - TSC, Collaborators, Internationalization, Convergence, LTS
@snostorm, Sean Ouimet, Canada/France - Website, French i18n, Documentation
@srl295, Steven R. Loomis (IBM), USA - TSC, LTS, Internationalization
@thefourtheye, anonymous?, India - Collaborators, Smoke Test
The best structure and possible team/repo cross-linking of this list is TBD. Alphabetical list by GitHub handle.
I wish to attend The Collaborator Summit Berlin 2018, I am a member of the @nodejs/modules team. I want to use the opportunity to give a talk on the benefit of participation of Africans collaborators to NodeJs Development and how the NodeJs Foundation can effectively support that.
Coming from Nigeria I will be glad if there will be any available support the NodeJs Foundation can provide for me to achieve this.
Thank You
Welcome to nodejs/collaboration.
The idea for this new "Working Group of Working Groups" developed recently as part of the August 2015 Node Summit. During the sessions many contributors shared what had worked well, and not so well, within their respective Technical Committee and Working Group structures. As topics such as intergroup collaboration and automation of processes were discussed, the group at large began to identify common sources of success and frustration. No existing group seemed best equipped to help solve some of the common communication, tooling and workflow needs shared among several (if not all) groups. Not did best practices have a good way to be discovered and shared. Thus, the idea of forming a new team interested in these shared issues.
Note: issues will be linked for breakout discussions versus mixing everything in one thread.
Not sure why the @nodejs/Foundation team was originally created, but I think we can and should remove it.
For whatever purpose it was set up, it does not appear to be serving that purpose as far as I can tell. Which is fine. No judgment or anything. I just think we should remove it. Thoughts @nodejs/tsc and @nodejs/community-committee?
We should have a step-by-step guide on how to transfer a project into the foundation along with all of its external integrations
cc @mhdawson
Some related links:
https://github.com/nodejs/build/blob/master/doc/process/npm_management.md
https://github.com/nodejs/TSC/blob/master/GitHub-Org-Management-Policy.md#repositories
https://github.com/nodejs/automation/blob/master/enable-travis-under-nodejs.md
I pinged the TSC and CommComm mailing lists with a suggestion that we add the nodejs
and node
Topics to every repository inside the Node.js GitHub Organization.
From the responses, it seemed there was general consensus. I wanted to give a heads up that I'll probably start going through and doing this sometime today or tomorrow, but also wanted to let everyone know in a more public forum.
I'd like to suggest that, as the TSC and CommComm, we add the Good First Issue
label to public repos in the GitHub organization.
I'd like to suggest this for a few reasons:
Good First Contribution
.One barrier here may be, as mentioned, that most repos that have something like this in place use Good First Contribution
. Changing the label is a possibility, though we'd of course want to respect the wishes of WG members if they were -1 on this change.
@Bamieh has done a TON of work on a repo around Mentorship as a part of the discussion around mentorship in the CommComm (ref: nodejs/community-committee#172).
As per our last CommComm meeting (ref: nodejs/community-committee#199) we've agreed to begin the process of pulling the repo that @Bamieh has worked on into the Node.js Org - and begin co-ordinating work around it as necessary.
Here's the repo: Bamieh/node-ment
cc @nodejs/community-committee @nodejs/tsc
As discussed in #1 and openjs-foundation/summit#12 , this team's scope should be clarified by the wider community to ensure it will actually fill a need. Many people will be bringing many ideas on what the possible scopes could be.
Let's collect them for future discussion and debate. Instead of too much yes/no debate in this thread, let's stick to idea collection and cover that later with our first round of Kickoff discussions. That said, if there are points or examples able to expand or clarify an existing idea, or concise con's worth including in an agenda, please add them.
The section below will summarize any ideas added later in the thread, linking to specific comments if the idea isn't concise (for space purposes.)
Helping to connecting individuals and/or groups together within Node.js. Somebody might not know the right repo/WG to turn to for what could be a build or website issue.
This could both be proactive research on how various WGs are operating and also a general dumping ground for ideas when members see things are working well within their groups. Brief case studies, best practice documents, a WG "getting started" guide, etc.
Meetings and forums to allow members of otherwise disconnected projects under the Node.js umbrella to have a reason to say "hi." The idea is reps from any interested WGs (ideally all WGs) would occasionally met and/or async. discuss what has been working well (or not so well) for them
To help identify shared needs among groups to try and reduce overlapping efforts. Relevant successful tooling could be shared; new tooling could be built in coordination with other groups like Website, Build, etc.
Maintain a centralized list of all Working Groups, their scopes, main organizers, etc.
Helping to provide a one-stop-shop on the Node.js Website for groups to easily publish information on their scope, activities, meeting minutes, meeting times, core membership, channels of communication, etc. Ideally much of this information could get vacuumed up from the individual WG repos to keep it all automated and decentralized.
The Evangelism, Documentation, Website and Internationalization Working Groups all have overlapping responsibilities with the 30+ language-based groups inside the project. This initiative acts as a hub for them to organize around common issues without also having to spin up a "Pan-Internationalization of Marketing and Online Content" group.
i did not find any team of "distributors": debian, fedora, etc... maybe it would be a good idea to create one. (and i did not find where to open an issue about that fact).
Is there already one? If not, should there be one? I believe @nodejs/build has talked about this at least once but I don't know what the outcome was.
@nodejs/tsc @nodejs/community-committee
So... switching off of IRC has been discussed in like a 20 threads over probably like 5 or 6 repos.
I think it might finally be time to make a move, and I strongly suggest that we use Discord.
Some reasons we might want to switch:
Here's a little tools comparison:
IRC:
Gitter:
Slack:
Discord:
All of these require an account because we also require freenode registration on IRC.
Here's a more detailed run-down of what Discord supports, relevant to us:
@everyone
mentions, and more.@mentions
for channel role groups.@mentions
/ suppress @here
& @everyone
/ mobile notifications settings / overrides.Other projects using Discord:
Is the @nodejs/LTS team now supplanted by and/or absorbed by the @nodejs/Release team, similar to the way @nodejs/CTC is now supplanted by and/or absorbed by @nodejs/TSC?
Trying to figure out if LTS should be made a subteam of members or not.
May I do it? Are there a set of things I need to worry about when doing so?
Repo: https://github.com/nodejs/string_decoder
Issue: nodejs/string_decoder#5
Projects we are testing on travis: https://travis-ci.org/nodejs
I know @Fishrock123 has done this in the past, and we are running several builds on travis.
Ref #68
cc @joyeecheung.
I've cat-herded a few Node.js working group meetings, figured I should write down how I do this, for other folks, and to fine-tune how we do these.
Not intended to be "the one and only way", more of a starter kit if you don't have another process that already works for your WG.
Examples here:
Presumably this becomes a wiki page, or md file, in this repo.
I recently shared a link to all the issues labeled with "Good First Issue" on twitter, encouraging individuals to see it as a path to start contributing to the project if they're interested in doing so.
One individual stood out–they said they would love to tackle some of the issues with a class they were teaching with about 50 students.
They reached out to me again pointing out some barriers presented in issues labeled "Good First Issue". These are legitimate barriers–and seem like they could be extremely off-putting to newcomers trying to engage in issues we've explicitly labeled "Good First Issue".
I'd like to propose that we codify a standard that issues labeled "Good First Issue" are held to.
While I definitely think this could be a good effort for the CommComm, I think that the TSC will probably be more invested in the outcome of doing this.
Thoughts?
At it’s core, Node.js is a collection of people working towards a shared goal. Improving people’s lives. This can be done through making software faster, it can be done by making empathetic APIs. This can be done by making a reliable platform, it can be done by being kind to each other. We work to improve the lives of the many individuals on this planet who rely on Node.js. We work to improve the lives of the many individuals on this planet who help make Node.js possible. — Myles Borins, TSC Director
We've kicked off the Core Values Initiative via the October 2017 Collaborators' summit. You can read my wrap-up and instructions for running a session here.
Q: Would it be appropriate to track the raw data from each event as a file in this repo or in CommComm? I'm happy to upload that so we have a folder of them as we get more turned in from future sessions. I'm sure someone could have fun with that data.
For this initiative, we want as many perspectives from a representative group of the Node.js global community as we can muster. At Collaborators’ Summit October 2017, most of the participants were existing collaborators, Board Directors, project leadership, and excited-to-contribute community members.
If you have a large meetup or are helping at a Node.js event internationally, please use the slides and the practice guide to perform the value exercise. Share it with the Community Committee by filing an issue with your report, so we can build our core values and create a plan for progress that is truly representative of the global Node.js community.
We'll be project tracking this initiative over the next six months here.
The Reimbursement section of the Member Travel Fund currently says to CC @hackygolucky's Linux Foundation email address - which, as far I know, will likely go nowhere.
@williamkapke @ashleygwilliams @mrhinkle we likely need to update these instructions, can you help advise on what the proper way to update them would be?
"collaborator" in the sense of anyone with org access. We're trying to lock down 2fa for the org but have some troubles with people in countries where that's difficult for whatever reason. This could also be a nice bonus for folks becoming active contributors.
I don't know how this would work exactly or who would administer it so that would need to be sorted out before we could go ahead with this.
Space is available at the Index 2018 conference in San Francisco on Feb 20 for use by the Node.js community. This would include a room for up to ~200 people for either a morning or afternoon session. Space, chairs/tables, power strips, WiFi, AV, and catering will be provided.
While this is in the same venue as the Index 2018 conference it is open to all (ie you do NOT have to be registered at the conference) and there is no charge to attend this part of the event.
I talked with Mark Hinkle (@mrhinkle) and we came up with this as a suggested agenda:
@nodejs/tsc, @nodejs/community-committee, @nodejs/user-feedback how does that sound and would you be able to participate ?
Updated Agenda:
The Node.js community day session is a good opportunity to connect with the Node.js community, learn what is coming up on the technical and organizational side of things, as well as contributing back by providing feedback based on your experience with Node.js. The session will be structured in four parts:
Introduction to Node.js and the Node.js foundation - led by Mark Hinkle executive director of the Node.js foundation. A great way to be introduced to Node.js and the foundation.
Introduction to Node.js initiatives, working groups and teams (including Community Committee and TSC initiatives) and how to get involved - led by Michael Dawson (TSC Chair ) and Tierney Cyren (Community Committee Co-Chair). A great way to learn what's coming in the future for Node.js.
End-user feedback session. In person feedback session between Node.js end users and the Node.js end-user feedback team - led by Dan Shaw (user feedback team lead). A great way to get involved and contribute back by sharing your experience to make Node.js better.
Community values working session - led by Tierney Cyren (Community Committee Chair) and Joe Sepi (Community Committee member). A great way to learn and share the values that make Node.js successful.
Whether you are a Java developer who wants to learn more about Node.js, a developer just starting with Node.js or a long time user, this is a good opportunity to talk and connect with community members.
The current Node.js i18n initiative owned by CommComm is seeking to officially establish our working group. Our MVP repo can be found here, and we'd like to pull it into nodejs/ to keep things moving. 🎉
I'm not sure what tasks are required in order to transfer this, your help is greatly appreciated! 🙌
I'd thought that the document added to this repo was for things in addition to travel, but I see now that it's not. I know that it's possible to request funds for things other than travel, but not actually sure what the process is other than "Open an Issue in node/admin".
Do we have a process documented anywhere?
Hey All,
it seems like there are likely agenda items that involve discussion and sign off from both groups. Would it make sense for us to create a monthly joint meeting of the two committees?
It currently says to cc Tracy, and mentions the 2017 fund allocation.
We should likely update this
/Cc @mrhinkle
The addon-api team (https://github.com/orgs/nodejs/teams/addon-api/members) would seem to be superseded by the n-api team (https://github.com/orgs/nodejs/teams/n-api/members). Should it be removed? Or should it remain for issues with the legacy API?
Whether or not the team should remain, is it active as a working group? As far as I know, it is not. If it is not active, the TSC should probably de-charter it.
@nodejs/addon-api @nodejs/tsc @nodejs/community-committee
I've done quite a bit of research and I've whittled it down to two types of options to account for our global collaborator base:
The plan would be to see which program feels effective but also reasonable for Moderation team members and collaborators to learn, and then build the proposal/budget request for the Node.js board to allocate funding.
Hi, the following projects have been moved into the foundation recently, following nodejs/TSC#406 :
IIRC, npm packages transferred into the foundation should add the foundation account to the npm collaborator list as a safety net, but I can't find a document for this. This repo seems to be the right place to ask, anyone knows what needs to be done to make it happen? Thanks.
edit: accidentally submitted with 0 content, sorry
I think the @nodejs/tsc @nodejs/community-committee and @nodejs/moderation should get together and discuss what the expectations of the team are and update the copy in the moderation policy
I'd like to suggest making a working session open to all members of each team, use that session to produce updated copy, and then get all groups to sign off on it
Thoughts?
The former API working group appears to be defunct.
Any objections to archiving https://github.com/nodejs/api?
Any objections to removing the @nodejs/api team? Seems like there are other teams (for things like N-API and maybe async-hooks?) that have replaced its function, so its existence might be little more than a source of confusion?
/cc @nodejs/api @nodejs/tsc @nodejs/community-committee
(I'll wait at least 72 hours before doing anything.)
Should be bi-weekly on wednesdays, it is currently on Friday. The meeting scheduled for this friday on the calendar should be moved to next wednesday
time does not change
The community-events
team and repo both seem to be inactive and superseded by the community-committee
team and repo. The team has one member, @PatrickHeneise.
Any objection to deleting the team and archving the repo?
@nodejs/tsc @nodejs/community-committee
Team: https://github.com/orgs/nodejs/teams/community-events
Repo: https://github.com/nodejs/community-events
Currently our process dictates that there is a different process when moderating Collaborator's posts. It also outlines a process for following up when actions have been made
Explanations of Moderation actions on Collaborator Posts must be provided in:
- A new post within the original thread, or
- A new issue within the private nodejs/moderation repository.
It does not appear that the current process is sufficient in outlining how the process should be handled when a complaint moves to multiple bodies (TSC / CommComm / Board). It also could use some more defined language on how we handle notification of the involved parties. Further, the process does not seem sufficient when we are dealing with members of leadership teams such as the TSC, CommComm, and the board.
I'd like to request @nodejs/moderation to put together some suggestions on this. Specifically I would like to see something that outlines the lifecycle of a complaint against a collaborator and a different lifecycle of a complaint against leadership.
For example:
The @nodejs/smoke-test team is inactive and seems to have been superseded by @nodejs/citgm.
Additionally the smoke-test repo at https://github.com/nodejs/smoke-test seems to be archivable.
Any objections to deleting the team and archiving the repo? @nodejs/tsc @nodejs/community-committee
I'll wait 72 hours before taking any actions.
Hi all, node-core-utils @ v1.10.0 just released with a new tool ncu-team
that automatically updates the list of members in a document with members of a Github team. See the documentation for details.
I have already opened nodejs/diagnostics#147 to use this since the original idea came from @mhdawson in nodejs/diagnostics#127 (comment) . I propose we start using it for other teams and WGs so we can better keep these membership stuff in sync.
BTW: the bot idea in nodejs/diagnostics#127 (comment) is going to be harder to implement because that requires an organizational webhook, which we currently do not allow.
Any training, logs, and documents that need to be supplied to Moderation team members should be in an easy to find place, and likely with a Real Human ™️ hosting a short meeting to make sure they are set up for success.
I renamed the team for the Intl
WG to Intl. I'd like to onboard more team members as seen in nodejs/Intl#5 - but they aren't current "nodejs collaborators". Is this a problem? What's the right process? I don't seem to have access to make changes, who would make them?
Posting here for purposes of shared memory.
These tools are active parts of our release pipeline, perhaps it would make sense for them to live in here.
/cc @rvagg
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.