nodejs/admin

Administrative space for policies of the TSC

admin's Issues

Move `node-ment` repo into the Node.js Org

@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

Ask the Foundation to buy & send a yubikey to any collaborator that wants one

"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.

Initiative for Nodejs Community Chapters

I propose for initiating local Nodejs community chapters around the Globe like - Google Developers Groups, Facebook Developers Circles, etc.
Benefits -

• Involving more developers and techies in the community
• Getting more node modules/packages out of the chapters by motivating developers in the chapters
• Promoting NodeJs technologies and tools

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.

Archiving https://github.com/nodejs/api and perhaps removing the api team?

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.)

Write a document about how to transfer a project into the foundation

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

Node.js core values initiative

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.

Status of GitHub LTS team

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.

Proposing removing the nodejs/Foundation GitHub team

Not sure why the @nodejs/Foundation team was originally created, but I think we can and should remove it.

• It contains four people, of which only one (Mark Hinkle) is actually a Foundation person.
• It has no repositories.
• It has no subteams.
• It has an empty discussion board.
• Membership supplies access to the private moderation repository. 😱

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?

Codifying Standards for issues labeled "Good First Issue"

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?

Travel fund contact email and fund allocation amount out of date

It currently says to cc Tracy, and mentions the 2017 fund allocation.

We should likely update this

/Cc @mrhinkle

Document member onboarding

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.

Expand process around Collaborator CoC Violation reporting

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:

Complaints against collaborators

• Collaborator is notified of complaint
• [How is decision made]
• Collaborator + Complainant are notified of the result
  • This should include timeline for updates if decisions have not been made
• Anonymized information regarding complaint is made publicly available
  • Is this desired or necessary?

Complaints against leadership

• Leader is notified of complaint
• Board is notified that complaint has been made (anonymized?)
• [How is decision made?]
• Collaborator + Complainant + Board are notified of the result
  • This should include timeline for updates if decisions have not been made
• Anonymized information regarding complaint is made publicly available
  • Is this desired or necessary?
  • Seems more relevant for leadership then general collaborators

CoC report information is inaccurate

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

distributors GitHub team?

From a comment from @kapouer:

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

Updating Member Travel Fund Reimbursement Section

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?

Conflict management training for Moderation team and collaborators

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:

1. Self-paced online course in Udemy
   • pros: at your own pace, very text-focused so more likely to translate to other languages than an English-based video training
   • cons: Not as robust, not interactive with other Node.js collaborators to contextualize the learning
2. Distributed, online video training with a conflict management training team. Option for further advisement on specific conflicts(that are sort of a step below requiring arbitration but have been escalated)
   • pros: very robust, team of experts who will actively cater to our context
   • cons: likely much more $$

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.

Using the eslint rules of node core for other projects in the foundation

Hi, I have created these two npm packages that export the eslint rules of node core:

1. eslint-config-node-core: Sharable ESLint configurations following the style guide of Node.js core.
2. eslint-plugin-node-core: Custom ESLint rules from Node.js 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:

1. Move these two projects into the foundation, and move the npm packages to a scope that belongs to us (IIRC the @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
2. Find projects under the Node.js organization that are willing to switch to this coding style, and help them migrate.

What do you think?

New label `membership changes` across the org?

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.

Remove community-events team and repo

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

Adding `Good First Issue` to all public repos in the Node.js Org.

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:

• Consistency: nodejs/node uses it, but (to the best of my knowledge) most other repos in the org use Good First Contribution.
• Ease of use: Having this on public repos will enable maintainers to quickly add it, and those looking to contribute to find issues more easily.
• Buy-in: It seems like GitHub itself has endorsed this specific method of "good for beginners" labeling with a recent update. Not sure if there's actual functionality around this, but it's better overall to use the same systems those new to the project may see elsewhere.
• Getting Started: This is also a VERY good resource for the nodejs/getting-started repo. I've been asked about two dozen times how to get started with contributing, and depending on the individual's interests I can sometimes point them to issues labeled accordingly.

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.

Adding cc-review labels to Node.js org repos

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 👍

We should all talk about expectations of the moderation team

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?

Pulling CommComm's i18n repo into nodejs/

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! 🙌

Move node-review into the foundation

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.

Document process for a Moderation team member to retire

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:

1. administrative steps/places a member should be removed from lists for contact as a moderator
2. process for member to leave, prob just saying "I am planning to step down" through filing an issue.
3. an emeritus list for Moderation team members in good standing who choose to depart.
4. dates for every Moderation team member for when their recertification time is due.
5. Activity/participation log for consideration of inactive Moderation team members. What is 'active'? How long does one need to be absent without noting they were taking a break?

archiving https://github.com/nodejs/node-convergence-archive

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.

Move `make-node-meeting` into Node.js GitHub org.

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.

About the nodejs-foundation npm account and collaborator access

Hi, I am wondering

1. Who has access to the Node.js foundation npm account (https://www.npmjs.com/~nodejs-foundation)?
2. How do we manage the npm collaborator access of the npm modules transferred to the foundation? If someone wants to request being added as a collaborator, what's the process? Should they open an issue in the project's repo and seek consensus, or somewhere like this for better visibility?
3. If a new npm collaborator is going to be added, whose consensus are needed? The project's Github collaborator? TSC? Members of the related Github team/WG?

How to officially request funds for things other than travel?

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?

Use `ncu-team sync` to maintain list of members in WGs/teams' README

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.

Should we remove duplicates of the moderation doc across org?

Seems like we still have a copy in the TSC repo, and the main Nodejs repo is still pointing to it

Adding `nodejs` and `node` Topics to every repository inside the Node.js Org

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.

Decharter the Addon API WG? Remove the nodejs/addon-api team?

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

How to onboard team members?

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.

How to add the Node.js foundation npm account to existing npm modules?

Hi, the following projects have been moved into the foundation recently, following nodejs/TSC#406 :

• branch-diff
• changelog-maker
• commit-stream
• core-validate-commit

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.

Space available at Index 2018 in San Francisco on Feb 20 for Node.js use.

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:

• Introduction to Node.js Initiatives, working groups and teams (including Community Committee and TSC initiatives) and how to get involved
• End user feedback session (as a way to bolster the work in https://github.com/nodejs/user-feedback)
• Community values working session

@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.

A Place To Start

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.

Team Todos

• Recruit representatives from a wide range of Node.js Working Groups and the Technical Steering Committee
• #3 - As members come in, keep track of everyone. Say hi. :)
• Setup times for some initial Kickoff meetings (held across several timezones) to keep the momentum going and make progress on these todos.
• #2 - Determine an initial high-level scope for the team, including clear limits to that scope as well.
• Better define and develop some possible projects that could help benefit multiple WGs. (Many ideas came up at the 2015-August summit.) Note: Collaboration might not always do the building/maintaining within in their scope, but may instead help develop the idea to get the ball rolling.
• Determine other todos?

Note: issues will be linked for breakout discussions versus mixing everything in one thread.

Happy Calendar Maintainers review day!

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!

Permission to enabling Travis temporarily to add string_decoder

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.

Switch to Discord for realtime official communications

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:

• We only have two real irc channels, #node-dev and #node.js, one of which is 'unofficial-ish'.
  • Specific conversations often overlap, adding new channels is difficult without owning the irc server.
• IRC spams join/disconnect messages because IRC.
• Moderation tools require arcane commands that are difficult to remember.
• No notifications, requires a bouncer.
• Horrible web interfaces.

---

Here's a little tools comparison:

IRC:

• Is capable of supporting every feature everyone would ever want except voice
• Those features will never exist because it all basically needs to be built from scratch and will never get done
• Requires a bouncer for chat history
• Mobile clients exist but are not great (in my experience)
• Horrible web interfaces

Gitter:

• Has awful moderation support
• Limited feature set
• Has mobile clients, web interface
• Can be connected to via an irc client

Slack:

• Not technically public
• Has poor tools for being used as a public channel (i.e. moderation tools)
• Great notifications system
• Has mobile clients, web interface
• Can be connected to via an irc client

Discord:

• Literally built for large-scale open communities
• Has public-space moderation and management functionality
  • No built-in temp bans / muting, but can be done through user roles
• Has voice channels for meetings
• Has mobile clients, web interface
• A middleware thing exists to connect via IRC
• Notification system not has good as Slack

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:

Public invite / join links

• Discord has a built-in system for sharing joinable links.
• Permanent links are available.
• The ability to create new links is completely configurable.
• There is support for levels of verification an account must have to be able to join (such as email, 2fa) in order to reduce spam / bots.

Text channels

• Support for markdown-style text input like Slack, emojis, embeds, etc.
• Has pinned message functionality, channel topics.
• Channels have individual full configurability for restrictions, including the ability to limit embeds, links, files, @everyone mentions, and more.
• Channel can be grouped by category.

Voice channels

• Also have individual full configurability for restrictions.
• May be removed altogether.
• Can be restricted to certain users.

Server roles

• Allows multiple administrators .
• Permissions for moderators, including kick, edit nicknames, bans.
• Full configurability of text / linking / attachments / etc permissions.
• Full voice configuration including connect / speak / mute members / move members.
  @mentions for channel role groups.
• Online member lists for roles groups.

Moderation tools

• Configurable server-wide explicit content filter.
• Support for server kicks / bans (account + ip by default) / lower-role editing.
• Ability to do member muting / temp-banning via role changing.
• Bans list.

Other stuff

• Is free for what we want, uses an account-subscription based model for extra, shiny, per-user features: https://discordapp.com/nitro
• Support for webhooks.
• Has support for custom integrations we could potentially make use of.
• Has an audit log.
• Has an embeddable server widget. (We could embed a chat into some Node.js website page if we wanted to.)
• Private messages from server users can be disabled.
• Typical notifications muting / only @mentions / suppress @here & @everyone / mobile notifications settings / overrides.

---

Other projects using Discord:

• React / Flux (~2k online users): https://reactjs.org/community/support.html#reactiflux-chat
• http://package.community/
• Yarn (top right https://yarnpkg.com/en/)
• Vue.js (ecosystem > chat https://vuejs.org/)
• And if you want to see discord at a ~10k online users scale: https://www.vrchat.net/discord (and a widget!)

Joint TSC + CommComm meetings

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?

Delete smoke-test team and archive repo?

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.

create a "how to run a Node.js Working Group meeting" page

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:

• previous API WG Meeting - nodejs/api#9
• future API WG Meeting - nodejs/api#11

Presumably this becomes a wiki page, or md file, in this repo.

A Who's Who of nodejs/collaboration

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.

Request to attend Collaborator Summit Berlin 2018

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

Modules team meeting is on wrong date on calendar

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

Remove roadmap team and archive repo

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.

GitHub Owner permissions

Situation:

• Policy in the TSC repository indicates that only a small number of people should be owners. https://github.com/nodejs/TSC/blob/4d5e08146339c4553143721a2a70bd7e57ed8867/Github-Org-Management-Policy.md#owners
• In reality, Owners consist of TSC members (considerably more people than listed in the policy--additionally, not everyone who should be an Owner according to policy is)
• Moderation Team needs "Owner" privileges. There hasn't been any movement I'm aware of to get a bot to make the Moderation Team effective.

Issue:

• Arguments for expanding Owner role to Moderation Team:
  • Private security repos are moving to their own org.
  • If someone deletes a repo or something destructive like that, GitHub, Inc. can restore issue
    tracker, wiki, and everything else. (Probably want to get confirmation on this and also an idea of process and timeframe.)
  • We can always remove Moderation Team from Owners if we get a bot together at some point in the future.

Questions:

• Should we remove the policy text or replace it with a reflection of what is actually the case? Or should we start narrowing the Owners of the org?
• Should the Moderation Team be given Owner privileges? If not, how do we make it so the Moderation Team can be effective now on a practical level?

/cc @nodejs/moderation @nodejs/community-committee @nodejs/tsc

A Discussion on Scope

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.)

---

Proposed Scope of the Collaboration Team

Act as a "switchboard" for connecting groups.

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.

Acting as a hub for the collection and dissemination of best practices among WGs.

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.

Networking

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

Workflow Tooling

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.

Specific Ideas

• The "schedule a meeting" button to automate all of the steps each WG maintainer has to go through in order to actually organize.

WG Inventory

Maintain a centralized list of all Working Groups, their scopes, main organizers, etc.

Provide a WG Web Presence

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.

Provide a Home for Connecting Related Groups

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.

move `branch-diff` and `changelog-maker` into foundation

These tools are active parts of our release pipeline, perhaps it would make sense for them to live in here.

/cc @rvagg