-
Notifications
You must be signed in to change notification settings - Fork 134
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
Result of Request to migrate Inclusivity Working Group responsibilities to the Node.js Foundation and TSC #179
Comments
@hackygolucky ... +1 to this several times over. I definitely like the direction this is going. Thank you for working on this. |
Echoing what @jasnell said, this looks really solid, and I'm also +1 to this many times over. |
Sounds good. I am definitely willing to help with anything pertaining to IRC channels or other chat options. (I am |
Thanks for putting the hard work into this @hackygolucky. This looks like a great start. I'm super +1 on the idea of a top level community group. I for one am a big fan of IRC and sticking to open technologies, at the same time I cannot argue with the success that slack has had with onboarding people + ease of use. Even if we move in the direction of slack I think it is important to have the main irc channel #node.js adhere to our CoC and moderation policy |
Given that the Community Committee is underway and the repository has been set up, is it ok to go ahead and close this issue out? |
Closing this issue. Further discussion in the @nodejs/community-committee repository. Thanks all. |
Proposal for change in responsibilities to Inclusivity WG currently under the TSC as requested here
This was posted here and not cross-posted to the Inclusivity WG because it was determined at an Inclusivity WG session in Collaboration Summit that the Inclusivity WG repo is going to be archived and I didn't want it to go into a vaccuum. When a new repo is created, this document can land there. My talk diving into details for the research behind this can be found here. This serves as a very high-level approach to laying the groundwork of future efforts. Implementation details will be discussed further when the Inclusivity WG is rebooted and many more folks can give feedback(including the TSC, CTC, and community at large).
Author: Tracy Hinds, Node.js Foundation Education Community Manager
It is my recommendation upon the audit/history that has been provided that the Node.js Foundation and various parties owning responsibilities within it consider the following:
Recommended improvements
Table of contents to detailed explanations below
Node.js Foundation Inclusivity Strategy
This document serves to carve a path forward for the health of the Node.js project through growing it into an ever more inclusive, supportive project. Include more perspectives, diversity of thought. Don’t take for granted how challenging this will be, but do lean on each other for an ear recognizing what we’re doing is helping when it does get difficult. Moving the needle in a global community takes patience, persistence, education, and time.
What is inclusivity? Take a global look.
An intention or policy of including people who might otherwise be excluded or marginalized to create a productive work climate of trust and respect.
Why do we value this?
We ask of total strangers to collaborate on a project that we all benefit from. In order for them to feel welcomed and stick around, they should feel like they belong.
To create that sense of welcome, barriers to access and biases must be surfaced. People must trust the community is moderating itself enough to contribute. An inclusive, open-source community will result in better code from a more diverse range of developers. We are making up for a lot of lost time due to systemic failures and biases.
Support for actions:
Addition of a top-level community organization alongside TSC
Community must be a top-level ownership org alongside the TSC. There are are number of organizations that have absolutely contributed to the growth of Node.js--NodeSchool, NodeBots, and thousands of individual meetups. This is not an exhaustive list. It is clear that the community activities, such as events, fall outside of the realm of code that the TSC oversees. These are vital to the life and energy that we feel as we grow the project. It is my belief that creating a top-level group alongside the TSC with a similar open governance structure and representing such groups will make way for the Inclusivity working group to exist within it. The champions of these organizations have very different skillsets and talents, and contribute to the growth of Node.js in a way that we should not continue a blind eye toward. As the TSC itself grows and considers its relationship with the CTC, there are discussions how these groups can improve and pave way for more agency to be felt by groups and not being burdened by process(perceived or real). The Inclusivity Working Group would live within the Community Organization.
Furthermore, Inclusivity as an effort must be actively supported by the project’s governing bodies and have the necessary decision-making power to help grow a better project. The members of the TSC, along within the other organizations of the Node.js Foundation, must feel themselves responsible for these efforts or we are forcing an idea on an ecosystem that doesn’t want it.
Diversity training
Diversity training via a consultant(3 have been vetted) to the Board of the Node.js Foundation and other leaders of the Node.js Foundation to set the bar for leadership. Two other consultants were reached out to for assistance and gave recommendations for others to speak to, but did not want to take on the challenge themselves. Consulting with the organization to look for gaps in our efforts that we can improve outreach and initiatives on will also help give perspective on the Node.js Foundation being a leader in the open source community for tackling these incredible challenges.
Peer mediation
Many conflicts in the community are members faced with a lack of perspective as much as it is folks who are not educated in managing or resolving conflict. Peer mediation documents provided as resources to encourage healthier communication for collaboration can help alleviate much of the stress we see in our GitHub and chat channels. The power of peers resolving conflict cannot be underestimated. Providing workshops alongside other community events has been requested and would be a great model to set forth in open source(and most workplaces, to be honest) as well.
Refactor the online community
We must ensure we have a trusted, moderated space we can send new folks to(we do not send someone to a space that isn't covered by the Node.js Code of Conduct or a similar CoC), and to alleviate discoverability issues finding helpful online channels for community collaboration in a synchronous, chat setting. This can be achieved through:
OR
Similarly, our GitHub communications have improved over the years. As we grow, it is helpful to communicate our values in a way that folks can understand the baseline to which we operate. Many of our legacy contributors know this as tribal knowledge. Our newer contributors shouldn’t have to learn through implicit observation and unfortunate interactions. Similar to GitHub’s own community policy, I believe Node.js should set forth a community guideline to share.
Prioritize seeking a diverse range of candidates for hiring and vendors.
We must lead in prioritizing inclusivity and diversity in every facet of our organization. Many of our corporate members have been doing this for years. There are countless papers that support how beneficial to our internal and external organization it would be to raise our bar for hiring and contracting efforts by striving for a diverse candidate/vendor pool.
Measure and set reasonable goals for diversity
Measure and set reasonable goals for diversity-- increasing representation in demographics and backgrounds that are underrepresented globally. We cannot know where we stand without knowing where we’re at. We need data! Moving forward, our surveys will be extremely comprehensive in order to gauge what needs to be improved. We’re making a lot of assumptions right now based on anecdotal observances. In future years, we’ll be able to tackle much more specific challenges based off of these results.
We will publish our findings when appropriate to share our potential successes and failures.
The text was updated successfully, but these errors were encountered: