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

Result of Request to migrate Inclusivity Working Group responsibilities to the Node.js Foundation and TSC #179

Closed
hackygolucky opened this issue Dec 15, 2016 · 6 comments

Comments

@hackygolucky
Copy link
Contributor

hackygolucky commented Dec 15, 2016

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.

  • Welcome folks to the table.
  • Make folks feel included.
  • Make folks feel supported once they are included.

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?

  • It’s about creating opportunities for everyone.
  • Diversity and inclusion bring us all opportunities to learn from others and grow. We all become better with more diverse views around when we are able to listen and learn.
  • It’s good for the health of the project--diversity of thought improves project outcomes.
  • A strategy towards a more inclusive Node.js ensures that people from the wider community can collaborate on the issues that they have an interest in because the lack of focus has affected their ability to contribute.
  • We’ll get left behind. Other organizations are doing a good job with this, and we shouldn’t lose contributors to our project only because they don’t feel welcome. That’s the silliest.

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:

  • (1) Revitalizing and cleaning up the IRC community.
    • Publish list of channels with webchat link to them on nodejs.org under ‘Get involved’
    • All published channels would be those who have agreed to adhere to the Node.js CoC and will list it as a topic in the channel
    • Require logging for reporting of issues to moderation
    • Outreach effort to encourage positive community and conversational energy to IRC, as many of these conversations have fled to siloed Slack organizations.
    • For this option to work, the moderation policies in current existence for IRC would need to be refactored and pull requested into the nodejs organization as part of a guide for the Code of Conduct. The current policy does not handle online, year-round communities comprehensively.

OR

  • (2) Creating a new, central Node.js Foundation Slack organization
    • Open by default--We will set up an open sign-up to allow for anyone who would like to participate in the Slack to do so. This sign-up also allows us to gate participation in the community ONLY by requiring participants to agree to adhering to the Code of Conduct.
    • General, random, and working group-ish channels(could have private ones for discussions needing to be protected with a policy of keeping convos pointed to public channels as much as possible)
    • Allows for the ability to moderate with admins easily--all channels can be seen and in instances of reporting for violations, there is a log.
    • Since sign-up is required, it can be more difficult for abusers to cloak themselves under another name and continue to be toxic in a community that is gated.

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.

@jasnell
Copy link
Member

jasnell commented Dec 16, 2016

@hackygolucky ... +1 to this several times over. I definitely like the direction this is going. Thank you for working on this.

@nebrius
Copy link
Contributor

nebrius commented Dec 19, 2016

Echoing what @jasnell said, this looks really solid, and I'm also +1 to this many times over.

@Fishrock123
Copy link
Member

Sounds good. I am definitely willing to help with anything pertaining to IRC channels or other chat options. (I am +F in #node-dev and +S in #Node.js, meaning, I more or less already have ownership there.) (Although otherwise talking to freenode to repossess a channel is always a viable option.)

@MylesBorins
Copy link
Member

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

@jasnell
Copy link
Member

jasnell commented Feb 25, 2017

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?

@jasnell
Copy link
Member

jasnell commented Apr 17, 2017

Closing this issue. Further discussion in the @nodejs/community-committee repository. Thanks all.

@jasnell jasnell closed this as completed Apr 17, 2017
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

5 participants