charter proposal #7
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1,30 @@ | ||
| # Diversity Working Group | ||
|
|
||
| ## Proposed Charter | ||
|
|
||
| (This charter has not yet been ratified by the Node.js TSC.) | ||
|
|
||
| ### Statement of Purpose | ||
|
|
||
| The Diversity Working Group seeks to extend inclusivity for the Node.js project. | ||
|
|
||
| ### List of Responsibilities | ||
|
|
||
| * Foster a welcoming environment that ensures participants are valued and can | ||
| feel confident contributing or joining discussions regardless of their | ||
| background, identity, or level of experience. | ||
| * Proactively seek and propose concrete steps the project can take to increase | ||
|
There was a problem hiding this comment. I could see this being reworded to "increase inclusivity and diversity" if that's the intent and we actually defined the words for the audience. I see increasing inclusivity as making the project a nice place for people from diverse backgrounds to be and want to stay. I see increasing diversity as actually getting those people from diverse backgrounds to participate in the project in the first place. They're two interrelated, but also different goals. There was a problem hiding this comment. +1, although wouldn't it be better, since they're separate goals, to put them into two bullet points, which would also give space to explain what each point is about? There was a problem hiding this comment. Splitting it into two points sounds good to me. |
||
| inclusivity. | ||
| * Acknowledge and celebrate existing diversity accomplishments within the | ||
| project while seeking to build upon them. | ||
| * Identify ways to measure diversity and inclusivity within the project. Collect | ||
| the measurements and report on them at regular intervals. | ||
|
|
||
| ### Initial Membership | ||
|
|
||
| * [@ashleygwilliams](https://github.com/ashleygwilliams) (Ashley Williams, ag_dubs) | ||
| * [@beaugunderson](https://github.com/beaugunderson) (Beau Gunderson) | ||
| * [@nebrius](https://github.com/nebrius) (Bryan Hughes) | ||
| * [@sup](https://github.com/sup) (Jona Hugger) | ||
| * [@Trott](https://github.com/Trott) (Rich Trott) | ||
| * *your name here* | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
include enforcing/writing/updating CoC + other relevant documents?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can take a crack at writing that, although as always, I'd love it if someone else would. The key pitfall from my perspective is that this group doesn't yet have any sort of track record and there will be alarm/resistance if the charter comes off as suggesting that this group can impose a CoC and enforcement mechanism on everyone else. I think it has to be crafted as saying that this WG will propose CoC (and subsequent CoC revisions over time as necessary) and enforcement mechanisms but that the ultimate authority for apporving them remains with the...er, not sure which of the two project oversight committees it would be in this case. @mikeal, would that be CTC or The Other One That Is Not CTC?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Important edit: "authority for applying them to the project" -> "authority for approving them to be implemented". Oversight committee does not have to do the actual implementation. They can give the OK and delegate to this WG.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any kind of enforcement should solely be the responsibility of the @nodejs/tsc and @nodejs/ctc. This WG can make recommendations, bring focus and attention to the issues, and raise complaints. If any issues raised involve a TSC/CTC member, that member can be asked to recuse themselves while the other members discuss.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say that it would be worthwhile to have a representative from this WG sit in as either an observer or full participant of the @nodejs/tsc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From a governance perspective all project responsibilities are in the TSC unless they are delegated to another group.
I'm willing to bet there is something a conflict here between:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The CTC has no reason to be enforcing this stuff, that should be up to the TSC unless delegated.
I suggest holding that thought for now. We should just work towards a TSC that is better at this, rather than shoving off the problem, I think.