Alternative Charter Proposal #27
Conversation
| ### Responsibilities | ||
|
|
||
| * Foster an environment that ensures that any and all individuals feel equally welcomed and empowered to openly participate in all aspects of the Node.js project. | ||
| * Leverage only open and inclusive channels of communication to discuss inclusivity and diversity matters that impact all participants in the Node.js project. |
There was a problem hiding this comment.
I don't like anything that forces discussions to happen in the open. final proposals being public and presented by a volunteer is one thing...
There was a problem hiding this comment.
I can strike the word only and replace with as much as possible. The point is to encourage open and accountable discussion and decision making when those decisions affect everyone.
* `s/only/, as much as possible, in second bullet point under `Responsibilities` * strike `established` in fourth bullet point under `Responsibilities`
|
I guess I'm hoping for clarification about why you made this alternative charter proposal, and how you're hoping it would contrast with #21 and #22. Correct me if I'm wrong, but the main gist I read from this is a hesitation to actually set down enforcement methods -- is that the case? If so, is there anything else you really want to highlight with this? |
|
I simply believe that this proposal is more representative of node's open "Hesitation" implies indecision. I am not hesitant of anything here. The
|
|
@jasnell we will be discussing this charter during the meeting we are having today. you are not currently scheduled to participate. could you summarize your specific concerns that you hope to communicate with this alternative proposal? we are going to be publishing a 1.0 of the charter today. this was communicated a while ago. the last minute alternative will be difficult to include- so anything you can do to help surface specific concerns would be helpful. ideally as comments on the current proposal, as well as some reason you have for dropping the CoC proposal. thanks. |
|
I believe the existing proposal on the table is not representative of I believe the proposed code of conduct is unnecessary and overreaching. I believe that this posted alternative is an improvement to both. It is not I recommend that the outcome of the meeting today be a proposed 1.0 charter @nodejs/collaborators
|
| This working group is still in the early stages of getting up and running. Check back soon for more info! | ||
| ## Proposed Charter | ||
|
|
||
| (this charter has not yet been ratified by the TSC and has no official standing) |
There was a problem hiding this comment.
Could this be reworded to indicate the group is starting the process of getting ratified by the TSC? Is there some common language other WGs have used to indicate this?
|
Seems very reasonable to me. I like the tone and the contents. |
|
We talked about this charter in the meeting and did our best effort into noting the things that this is trying to achieve and doing our best to incorporate this into #21 and #22. The biggest issue at hand seems to be a matter of scope, and we figured the scope of this committee's expected influence/power and nuance as far as self-enforcement vs larger-community-enforcement was lost somehow in those two. Specifically, some level of self-enforcement is important for this WG because of the evidently controversial nature of the topic at hand, which is something most groups would honestly never have to deal with. I think the consensus in the meeting was definitely to continue this discussion in the main one, with appreciation for the contribution, because this is important stuff to talk about. Please direct your attention to those two PRs for now, as they'll be getting fixed up and merged today -- and also note that they will likely not be the final version, we'll have a proper process for feedback before ratification, etc etc. For the time being, I'm going to close this PR, with sincere thanks for the effort you put into submitting it. I really really hope you find that we've captured the essence of what you wanted to communicate once the other changes land, and we will 100% be open to discussion if that was not the case. Cheers! <3 |
|
p.s. I really really really appreciate you taking the time and effort to address my comments as I made them, in this PR. :) |
|
p.p.s #30 has the notes for the meeting with bullet points of the intended changes, as a preview of what we'll be seeing |
|
Depending on my review of the draft that ultimately emerges, I may update and reopen this PR if I feel that the concerns are not appropriately addressed by the other draft. If I reopen, I will label it Quick note: the dev-policy recommends that potentially controversial Pull Requests be given a longer period of time for full review (48-72 hours) before action is taken. I would note that this closed less than 10 hours after it was posted. It is my opinion that closing this PR so soon is premature and not reflective of a truly open decision making process. Update: I would note also that in the meeting minutes posted (#30) I see no indication that this PR was discussed, any indication of feedback or consideration. |
|
My genuine hope is that the changes made to the other one will address all your concerns. Thanks for the links, as that's stuff I didn't know about, and you're more than welcome to reopen this (and push it to the tc) if you feel that didn't happen. As you've probably seen in the repo, there's a lot of noise going on and I think it's a good thing in this particular case to try and keep refocusing the conversation and avoid multiple PRs and threads discussing the same basic issue. I hope you'll understand my closing this one in that light, and not as a silencing tactic of some sort <3 |
|
( https://github.com/nodejs/inclusivity/pull/30/files#diff-ef50fed1e25e0c33f7a1aac3321ed9f7R29 is the relevant bits that resulted from talking about that -- we're expecting more detailed meetings notes later iirc ) |
|
Closing a pull request inherently silences it. In my experience, open processes that deal with controversial topics often benefit most from having multiple options on the table for discussion; and it's often best to err on the side of an overabundance of patience before taking action on any one of those options. The 48/72 hour review period I mentioned was written into the dev-policy specifically to allow appropriately reasoned review by as many collaborators as possible so that decisions that affect everyone are not rushed unnecessarily. Closing a PR early, without allowing for that opportunity for broader review naturally stifles the conversation. As I said, however, I will wait to see the updated draft that emerges out of today's conversation before deciding what further steps I will take with this PR. (Btw, please don't take any of this as a personal thing ;-) I appreciate your feedback and your taking the time to comment here.) |
|
After reviewing the meeting recording, I appreciate that the discussion was far more moderated than what I have seen on the github repo. I will say, however, that that's likely the first time I've ever heard anyone voice the sentiment that opening a PR was "anti-collaborative". I'm a firm believer in offering concrete alternatives as opposed to simply saying something does not work for me. |
|
Out of curiosity – was the meeting recorded on youtube or similar (similar to other groups does it)? Edit: never mind, found it: https://www.youtube.com/watch?v=oBkMYONPYp8 |
|
@jbergstroem yes it was: http://youtu.be/oBkMYONPYp8 |
|
Yes. There's a few comments up but I can't grab it directly.
|
An alternative proposed charter.
(Would replace #21 and #22)