TSC Meeting 13-Oct-2016

[nzakas]

Time

UTC Thu 13-Oct-2016 20:00:

• San Francisco: Thu 13-Oct-2016 13:00
• New York: Thu 13-Oct-2016 16:00
• Madrid: Thu 13-Oct-2016 22:00
• Moscow: Thu 13-Oct-2016 23:00
• Sydney: Fri 14-Oct-2016 06:00
• Tokyo: Fri 14-Oct-2016 05:00

Location

https://gitter.im/eslint/tsc-meetings

Agenda

Extracted from "tsc agenda" labelled issues and pull requests from the ESLint org prior to the meeting and comments on this issue.

Invited

• Nicholas Zakas (@nzakas) - TSC
• Ilya Volodin (@ilyavolodin) - TSC
• Brandon Mills (@btmills) - TSC
• Gyandeep Singh (@gyandeeps) - TSC
• Toru Nagashima (@mysticatea) - TSC
• Alberto Rodríguez (@alberto) - TSC
• Kai Cataldo (@kaicataldo) - TSC

Public participation

Anyone is welcome to attend the meeting as observers. We ask that you refrain from interrupting the meeting once it begins and only participate if invited to do so.

[kaicataldo]

Agenda item: Continue/revisit discussion of how accepting pull requests without issues is going.

[nzakas]

Agenda item: I'd like to discuss creating an ESLint fork of escope. We've talked about this for a while behind-the-scenes, and I think it's time for us to make a decision.

The rationale: currently escope is not actively maintained, and it doesn't seem like asks for custom functionality are going to be accepted. Rather than continuing to fight about things we might need to support TypeScript or other functionality, I think it's time to consider forked escope for use within ESLint.

[JamesHenry]

^ Thanks for raising this @nzakas

[nzakas]

Agenda item: I'd like to propose that we allow any team member to merge non-breaking PRs so long as at least one TSC member has approved the PR and the waiting period has passed.

Rationale: If a TSC member has already approved a PR and is just waiting the 2-3 days for others to review, it doesn't really make sense to prevent committers from merging the PR after that point since the TSC member would likely have done it anyway. This could help ensure that PRs are landed faster because it expands the pool of people who can merge. Currently, committers cannot merge PRs other than chores, bug fixes, and documentation changes.