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

Node.js Technical Steering Committee (TSC) Meeting 2020-08-13 #907

Closed
mhdawson opened this issue Aug 10, 2020 · 13 comments
Closed

Node.js Technical Steering Committee (TSC) Meeting 2020-08-13 #907

mhdawson opened this issue Aug 10, 2020 · 13 comments
Assignees

Comments

@mhdawson
Copy link
Member

mhdawson commented Aug 10, 2020

Time

UTC Thu 13-Aug-2020 21:00 (09:00 PM):

Timezone Date/Time
US / Pacific Thu 13-Aug-2020 14:00 (02:00 PM)
US / Mountain Thu 13-Aug-2020 15:00 (03:00 PM)
US / Central Thu 13-Aug-2020 16:00 (04:00 PM)
US / Eastern Thu 13-Aug-2020 17:00 (05:00 PM)
London Thu 13-Aug-2020 22:00 (10:00 PM)
Amsterdam Thu 13-Aug-2020 23:00 (11:00 PM)
Moscow Fri 14-Aug-2020 00:00 (12:00 AM)
Chennai Fri 14-Aug-2020 02:30 (02:30 AM)
Hangzhou Fri 14-Aug-2020 05:00 (05:00 AM)
Tokyo Fri 14-Aug-2020 06:00 (06:00 AM)
Sydney Fri 14-Aug-2020 07:00 (07:00 AM)

Or in your local time:

Links

Agenda

Extracted from tsc-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/node

  • Land #34035 on v14 (stream: simpler Readable async iterator) #34680
  • Rename default branch from "master" to "main" or something similar #33864

nodejs/admin

  • Audit Google account access #389

Invited

Observers/Guests

Notes

The agenda comes from issues labelled with tsc-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

Zoom link: https://zoom.us/j/611357642
Regular password

Public participation

We stream our conference call straight to YouTube so anyone can listen to it live, it should start playing at https://www.youtube.com/c/nodejs+foundation/live when we turn it on. There's usually a short cat-herding time at the start of the meeting and then occasionally we have some quick private business to attend to before we can start recording & streaming. So be patient and it should show up.

Many of us will be on IRC in #node-dev on Freenode if you'd like to interact, we have a Q/A session scheduled at the end of the meeting if you'd like us to discuss anything in particular. @nodejs/collaborators in particular if there's anything you need from the TSC that's not worth putting on as a separate agenda item, this is a good place for that.


Invitees

Please use the following emoji reactions in this post to indicate your
availability.

  • 👍 - Attending
  • 👎 - Not attending
  • 😕 - Not sure yet
@mhdawson mhdawson self-assigned this Aug 10, 2020
@mmarchini
Copy link
Contributor

The unhandled rejections survey is available at: https://www.surveymonkey.com/r/FTJM7YD

We also wrote an accompanying blog post for extra context: https://medium.com/@nodejs/node-js-promise-reject-use-case-survey-98e3328340c9

The survey will run for at least two weeks, at which point we'll evaluate if the number of replies is enough for us to move forward, otherwise we might extend it for a week or two. Please fill out the survey as it will help us decide the future of unhandled promise rejections on Node.js!

@mmarchini
Copy link
Contributor

mmarchini commented Aug 11, 2020

The Commit Queue PR is ready to land. I was going to land it today but @devsnek pointed out that it will allow non-collaborators to start CI (more specifically, it will allow the new Triage team to start CI as well) land pull requests (if the pull request passes all checks, including wait time, number of reviews by collaborators, and CI). I don't think we have a process to give an extra team access to CI partial landing permissions to nodejs/node, so I'll just leave the question here: should the Triage team be able to start CI land pull requests using the Commit Queue on nodejs/node?

If someone objects we can discuss in the meeting, but so far folks were fine with it in the PR.

Ref: nodejs/node#34112

@mhdawson
Copy link
Member Author

I think having them start CI is ok, and possibly desirable.

@mhdawson
Copy link
Member Author

@ronag is going to come to the meeting for the discussion on Land #34035 on v14 (stream: simpler Readable async iterator) #34680

@mmarchini
Copy link
Contributor

I made a mistake on my comment above: Triage team will be able to start Commit Queue, not CI (they already can start CI today :) ). So let me rephrase my question: should the triage team be allowed to start Commit Queue, which means they will be able to land pull requests? As @addaleax mentioned in the PR, triage team will still not count towards reviews, and the Commit Queue runs all the necessary checks before landing (wait time, reviews, CI, etc). This might help offload some landing work from collaborators, which is good. OTOH it gives partial commit permission to a team separate from collaborators. So what do folks think?

@Trott
Copy link
Member

Trott commented Aug 12, 2020

Moderation Team report:

Blocked 2 users for junk/spam PRs: https://github.com/nodejs/moderation/issues/373, https://github.com/nodejs/moderation/issues/372

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

@mcollina
Copy link
Member

I'm +1 @mmarchini

@mhdawson
Copy link
Member Author

No update on the build resources strategic initiative.

@mhdawson
Copy link
Member Author

I'm +1 @mmarchini as well.

@MylesBorins
Copy link
Contributor

MylesBorins commented Aug 13, 2020

@mmarchini I think it is a great idea! We may want to document and encourage usage of the "author ready" label or some other mechanism to signal "this can land'.

edit: or alternatively encourage / normalize the use of changes requested to ensure there are not misunderstandings (my understanding is work on this is already being done)

@mmarchini
Copy link
Contributor

mmarchini commented Aug 13, 2020

alternatively encourage / normalize the use of changes requested to ensure there are not misunderstandings (my understanding is work on this is already being done)

We changed the collaborator guide recently to explicitly require Request Changes when objecting to a PR (nodejs/node#34639 and nodejs/node#34702). Might be worth a PSA?

@mmarchini
Copy link
Contributor

@mhdawson
Copy link
Member Author

PR for minutes: #909

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

5 participants