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

Proposal: Split TSC agenda in to two meetings #1879

Closed
mikeal opened this issue Jun 3, 2015 · 6 comments
Closed

Proposal: Split TSC agenda in to two meetings #1879

mikeal opened this issue Jun 3, 2015 · 6 comments
Labels
discuss Issues opened for discussions and feedbacks. meta Issues and PRs related to the general management of the project.

Comments

@mikeal
Copy link
Contributor

mikeal commented Jun 3, 2015

As it stands, the TSC has two primary roles:

  1. Final arbiter of changes to core.
  2. Project wide governance body (including all Working Groups)

We've done a pretty consistent job of 1 but I don't feel like we're doing enough for 2. For instance, we've never taken on an agenda item for more than simply approving a working group and we have no clear mechanism for working groups to add new agenda items to the meetings.

We're also overdue for placing several Working Group representatives on the TSC (per the new Project Life-cycle several working groups are "Core" which means they are entitled to a TSC rep).

So, here's my proposal.

  1. We hold two meetings each week, one called "TSC Core Meeting" and another called "TSC Project Meeting."
  2. Any agenda item related to code going in to core falls in to the first meeting.
  3. Any agenda item not about code going in to core or the development policy for core falls in the second meeting.
  4. Post agenda for each meeting 24 hours before the meeting.
  5. TSC members are encouraged to skip meetings which do not have agenda items they are concerned with.
  6. All working groups are encouraged to send a representative in a non-voting capacity (assuming they are not yet in a core state) to the second meeting.

As you can imagine, the first meeting solidifies the "core sync up" that happens in the current meeting while the second meeting provides a similar function for the working groups to more accurately sync up and consider other project wide issues.

This should be considered and experiment. If we feel it is deficient we can go back to the old process. If it's successful we may want to consider splitting these responsibilities more formally.

@mikeal mikeal added tsc-agenda discuss Issues opened for discussions and feedbacks. labels Jun 3, 2015
@bnoordhuis
Copy link
Member

Speaking for myself, it's already difficult enough to slot in one weekly meeting, let alone two. -1 from me.

@Fishrock123 Fishrock123 added the meta Issues and PRs related to the general management of the project. label Jun 3, 2015
@bnoordhuis
Copy link
Member

There was tentative agreement in today's TSC meeting and @mikeal is going to work out a proposal. Removing the tsc-agenda label.

@Fishrock123
Copy link
Contributor

Hmmm, re-reading I think this could work.
I'm not sure how exactly this would work with the current governance policy though.

According to the proposal above, @bnoordhuis there's no reason you'd need to attend both most of the time I think.

@bnoordhuis
Copy link
Member

I hope so but it hinges on how the agenda is sliced. Let's see how it works out.

@bnoordhuis
Copy link
Member

Any progress on this? Should I tag it tsc-agenda?

@Fishrock123
Copy link
Contributor

See nodejs/TSC#2, this has been completed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Issues opened for discussions and feedbacks. meta Issues and PRs related to the general management of the project.
Projects
None yet
Development

No branches or pull requests

3 participants