Should we modify the guiding principals? #132
Comments
|
Probably a good idea, there were some things along this line I wanted to discuss adding somewhere but I didn't know there was a place for them. |
|
This too, please: https://github.com/nodejs/node/blob/master/ROADMAP.md#long-term-support:
|
|
I've really seen no reason to modify those guiding principles. We have a healthy thriving project with a growing and passionate community. Some growing pains are too be expected and welcomed. Node now has a rigorous CI process that is steadily improving, we've established a solid LTS program that ensures stable targets for the enterprise, we are improving communication and planning around expected major changes, we have a deprecation process that still needs a bit of work but is getting better, we have an active community of reviewers, we proactively smoke test changes against popular modules, we've demonstrated repeatedly that we have no problem reverting changes when breaks occur, we have healthy debate over major changes, we have an enhancement proposal process that is starting to get put through its paces... These are all signs of a project that is healthy and vibrant and I have seen absolutely nothing in what we've done over there past year that runs counter to those guiding principles. Have there been breaks? Yes. Have we dealt with them? Yes. Note that none of these have affected LTS, which is why we have LTS. Note that we changed from calling things Stable to calling them Current because we didn't want to send the wrong message about Stability. Node that we established the six month current branch before things go LTS specifically so that we give ourselves time to make sure things are ready. As far as I'm concerned we stay the course we're on and keep iterating to improve; but nothing we've done as yet is counter to those guiding principles. |
|
+1 to changing the part @Trott linked to, as it doesn't reflect how our LTS actually works. Once something reaches EOL, that's it. |
|
+1 to updating the LTS portion of that roadmap doc but that's an entirely different thing than what @thealphanerd was mentioning in the origin post... Update: I would say that the document at https://nodejs.org/en/get-involved/development appears to have been derived from the original dev-policy repo (which is certainly out of date). That document in general likely needs to be updated to reflect our actual current process. The guiding principles section, however, I would leave entirely the same. |
|
Maybe consider changing the part that talks about the project needing to establish an LTS policy and instead indicating that the policy is established and linking to it? Also maybe review the TSC mention and make sure it shouldn't be CTC too or instead? Most other changes I'd want to see are more cosmetic. In particular, it seems unnecessarily wordy. But that can be addressed without altering the actual principles themselves. Might be good to enumerate the principles as bullet points since principles seem like something that ought to be enumerable. But again, that's not about changing content. |
|
@Trott I agree that enumerating a short bulleted list would be extremely helpful. That's typically how values statements are most effectively managed within companies and projects, in my experience. @jasnell I could be misreading your response here, but it seems like you may be defending against me (or someone) saying that node isn't living up to those values. I actually think you're absolutely right, that mostly the node project has been extremely successful at delivering on the promise of that guiding principles doc. There's an LTS process, Node users get to take advantage of the latest and greatest V8, major bugs have been caught prior to release more often than not, communication with the community has improved. You and the rest of the folks on the TSC and CTC have every right to feel proud of the progress that has been made. Great job. But one doesn't typically post GitHub issues for the working bits, right? As you say, it can be improved, growing pains are to be expected, etc. So paying attention to the not-so-working bits is how things are improved. The confusion that led to this request was over a specific (and relatively niche) technical issue, where it's very clear that the CTC is agreed on the direction to take the project, but it's not clear (at least, to me) how that squares with the stated values. So maybe the values could be more clearly stated. Not that they're 100% wrong, or even that anyone's suggesting the project's goals need to change, it's just something where the communication could probably be improved. That being said, from my own experience, I'd be surprised if simply writing down Node's values in a more clear fashion didn't lead to some values and/or process changes. Communities are defined by shared values, and clear values enable individuals with disparate interests to work together effectively. Such an exercise is bound to start a conversation, and I think it's an important conversation that will help the participants of this project work in concert with one another on behalf of the Community of users who build their applications and businesses on top of the Node.js platform. Working in the open towards greater clarity about values demonstrates an ongoing commitment, not only to the Project, but to the stability and vitality of the Community as a whole. |
|
Does anyone have info on the provenance of this text? I'm drawing a blank but I'm not exactly known for my great memory. Revisiting vision statements, goals, etc. is something that we should be doing regularly so I'm +1 on having discussion about this. In-person is generally the best way to get a meeting of minds of these kinds of things so perhaps folks who are organising the meeups during Node Interative(s?) could build in a session about this topic? I'd bet we could come up with a much better statement that reflects that actual state of play now that we've been doing this together for a while; not that I find anything objectionable in that text, it just doesn't really have the resounding yes for me that these kinds of statements should have for people who are involved. |
|
Yep, I wrote this text as part of the original dev-policy draft when we On Wednesday, August 24, 2016, Rod Vagg notifications@github.com wrote:
|
|
I agree with Rod that revisiting regularly is a good thing. In person discussion would also be good but since not everybody will be there I think it would be good if we had a good amount of prior input with respect to where people thought changes were needed. This would allow the discussion to be about how to find the right words to express the principles as opposed to the in-person group trying decide what they should be. |
|
@rvagg I think that's a great idea, and I agree that doing this in person is almost certainly going to be a good way to get started, even if ongoing discussion is mostly remote. I don't suspect that this is your intent, but just to put it out there: I'd be a little bit concerned about that seeming like a closed-door cabal type of thing (at least, if "reflect the community" remains on the list!) How would folks feel about having a moderator with some experience helping a group drive towards lists of core values? Node is definitely not the first group to have to go through such an exercise, and it's probably unreasonable to expect it to go well just because of good intentions. That'd probably help make sure that trade-offs and such are captured, and an ongoing review in the open portions of TSC meetings could help keep them relevant and public. The more the community sees y'all tying decisions back to explicitly stated values, the more trust that can be built, even if they don't agree with a decision or with the values themselves. It reduces a lot of uncertainty and posturing by just telling people what the rules of the game are. |
|
I'm +1 on discussing this too. I think it would be best to start this as a discussion during a regular TSC meeting, and based on that discussion we could then decide to have a separate discussion with a moderator to help guide us, or whatever next step we deem appropriate. |
|
This has not progressed. Going to recommend closing the issue unless there's a way we can make progress on it. |
|
Closing due to lack of forward progress on this. We can reopen if necessary |
The document on our guiding principals can be found at https://nodejs.org/en/get-involved/development/#guiding-principles
In nodejs/node#8149 @isaacs has questioned if these published principals are still in line with the current values of the project
I am not going to introduce any conjecture in this issue, but I think it may be useful for the TSC to have a discussion about this for the public record
The text was updated successfully, but these errors were encountered: