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

Charter this #48

Closed
Fishrock123 opened this issue Oct 20, 2015 · 11 comments
Closed

Charter this #48

Fishrock123 opened this issue Oct 20, 2015 · 11 comments
Assignees

Comments

@Fishrock123
Copy link
Contributor

As stated in nodejs/node#3454 (comment), we should write a charter and get the TSC to ratify this group, it's about time. :)

@Fishrock123 Fishrock123 self-assigned this Oct 20, 2015
@Fishrock123
Copy link
Contributor Author

Hmmm, looks like some WGs only have a bit in core's WORKING_GROUPS.md and don't have their own GOVERNANCE.md file like the website does.

cc @mikeal

@mikeal
Copy link
Contributor

mikeal commented Oct 21, 2015

Governance is pretty loose in WGs prior to them being chartered, but all chartered WGs should document their governance. Also, any repo we contribute code to MUST have a CONTRIBUTING file that includes the DCO.

@jasnell
Copy link
Member

jasnell commented Oct 30, 2015

@nodejs/lts, Here is a draft strawman.. feel free to knock it down:


This WG would have the following responsibilities:

  • Development and Administration of all LTS policies and release schedules.
  • Management of LTS Branches including determination of which commits land and which do not.
  • Determining when a Stable branch is ready to migrate into LTS status and submitting the LTS Proposal to the CTC.
  • Authoring and editing LTS related documentation within the Node.js project.
  • Working with the ecosystem to ensure appropriate stability of LTS releases (smoke-testing); ownership and responsibility for the citgm tool
  • Advising the CTC and TSC on all LTS related issues and discussions
  • Messaging about the future of LTS to give the community advance notice of changes.

@MylesBorins
Copy link
Contributor

are we still planning to charter?

@rvagg
Copy link
Member

rvagg commented Nov 23, 2016

OK, strawman proposal: let's not charter and simply let LTS responsibility be a soft-delegation of the CTC which it can intervene in at any time it likes. In practice this group takes responsibility for versioning and branch management, not just LTS, but it's also not needed to have autonomy or the trappings of a full WG, it's really just a team of interested parties who have the time, energy and interest (mostly because of employer interest) in LTS matters. It's not dissimilar to the V8 team which is effectively given almost complete reign over V8 matters except where there's overlap with other concerns.

Thoughts @nodejs/lts?

@MylesBorins
Copy link
Contributor

+1 to strawman

On Wed, Nov 23, 2016, 6:28 PM Rod Vagg [email protected] wrote:

OK, strawman proposal: let's not charter and simply let LTS responsibility
be a soft-delegation of the CTC which it can intervene in at any time it
likes. In practice this group takes responsibility for versioning and
branch management, not just LTS, but it's also not needed to have autonomy
or the trappings of a full WG, it's really just a team of interested
parties who have the time, energy and interest (mostly because of employer
interest) in LTS matters. It's not dissimilar to the V8 team which is
effectively given almost complete reign over V8 matters except where
there's overlap with other concerns.

Thoughts @nodejs/lts https://github.com/orgs/nodejs/teams/lts?


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#48 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAecVw2QO-3zuOOCCYhRwa3v1qbPq4OAks5rBBVXgaJpZM4GSewh
.

@bnoordhuis
Copy link
Member

Sounds good to me.

@mikeal
Copy link
Contributor

mikeal commented Dec 5, 2016

I'm a little bit conflicted about this.

On the one hand, it's a bit much to delegate something as large as "all LTS releases" to a sub-group.

At the same time, the people who are doing this work really are the only people qualified to be making these decisions. It's a huge amount of work and the impact of changes will get more difficult to understand by those not doing the merges over time.

Right now the division of responsibility for this isn't a problem because the CTC is good about delegating and trusting the people in these teams but one of the things that ensures that this continues in the future is guaranteeing autonomy over decisions like this.

We setup these structures to institutionalize some of the cultural norms and precedents we thought were important: like giving those who do the work ownership and autonomy over the work. The good news is that this is working and the culture around delegation is still strong but that could erode over time if we don't continue to institutionalize the values.

@jasnell
Copy link
Member

jasnell commented Dec 5, 2016

I'm ok with chartering as an actual WG but don't really see the pressing need. Definitely wouldn't object to it tho at this point.

@Fishrock123
Copy link
Contributor Author

I think it should probably be an actual WG

@hutson
Copy link
Contributor

hutson commented Dec 7, 2016

As a member of a team that supports Node developers in a corporate environment, I already assume many of the responsibilities listed by @jasnell are supported by the Node CTC, even if on an ad-hoc basis.

I believe, as perhaps @mikeal hinted at, that formalizing a working group around the individuals, and responsibilities, already inherit in the LTS process, would help to demonstrate Node's long-term commitment to stability for corporate users, and ensure the autonomy to continue that process, even if the CTC's own priorities, and resource allocation, shift.

ChALkeR pushed a commit to ChALkeR/LTS that referenced this issue Jun 30, 2018
part 1 - governance and docs for repo

PR-URL: nodejs#223
Fixes: nodejs#48
Reviewed-By: Sam Roberts <[email protected]>
Reviewed-By: Richard Lau <[email protected]>
Reviewed-By: MichaëZasso <[email protected]>
Reviewed-By: Gibson Fahnestock <[email protected]>
Reviewed-By: Myles Borins <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Jeremiah Senkpiel <[email protected]>
Reviewed-By: Bartosz Sosnowski <[email protected]>
Reviewed-By: Rod Vagg <[email protected]>
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

7 participants