[svgcg-2019] Promoting Diversity

[SgiobairOg]

Happy to see that W3C, and our working group by extension, include a Code of Conduct.

I propose that after the inclusion of the Code of Conduct we add language pledging to consider our work with an eye to include diverse input. Seeing as we have a 30:2 ratio of male to female and the majority of us appear to be Caucasian we would do well to strongly consider our potential for unconscious bias shaping our decisions. By recognizing this and pledging to consider and seek out diversity in our interactions with the community I believe we can improve our end product. It's not a true substitute for real diversity, but we don't have that yet and I feel the next best thing is to make an honest and transparent effort to address it.

Here's a rough take on some sort of statement:

In all activities the Community Group will strive to account for the diversity of the SVG community and the differences in our experience and interaction with the specification and associated tools, and will actively work to counter internal biases arising from the make-up, experience, or privilege of its members.

[AmeliaBR]

I definitely agree with your priorities. I too have been looking at the CG participant list & wondering how to connect with more diverse groups of SVG users.

But at the same time, I don't want to include vague statements about what the group will do without describing what that actually looks like and assigning clear responsibility for meeting the objective.

What specifically do you think this would look like?

[zed-vector]

I understand the sentiment, but I think this sort of language is of wider applicability and properly belongs in the Code of Conduct. Not least, for the avoidance of duplication. I imagine there is some means by which the CG might recommend such ideas.

[AmeliaBR]

Ok, some ideas after pondering a little longer:

For diversity within the group, I agree with @zed-vector that we should keep the focus on the W3C Code of Conduct & not confuse the issue with any other statements.

But, you're right, @SgiobairOg, that there is a larger SVG community to consider & when specifying new technologies or recommending best practices, we need to consider the impacts on many different people.

For W3C specifications, this is in part handled through the horizontal review process. Specs are reviewed by other working groups for privacy & security impacts, for accessibility impacts, and for potential internationalization issues. Specification editors are required to self-review their work before submitting it for publication, and specs need an explicit impact statement for privacy & security considerations.

Now, if all three of these reviews are done well, they should cover the points Jon brought up. Or turning it around, the concrete actionable way in which the group could account for differences in the way people use our tools and the technologies we propose is by reviewing all projects for privacy, security, and accessibility impacts, and for their ability to be fully internationalized. Although it can't replace having diverse perspectives in the group itself, having a structured process to think about these impacts can make it less likely that issues will be overlooked.

Specification self-reviews are already required as part of the WICG Intent to Migrate request that we reference in the charter. And @frivoal has already suggested in #201 that we should more explicitly call out the dependency on the horizontal review groups at the W3C.

But we could go one step further, and require all SVG CG projects — specifications, other reports, and software projects — to include a “human impacts” statement summarizing how privacy, security, accessibility, and internationalization issues are being taken into consideration.

For the charter, that could look like the following extra requirements in the section on “Projects and Project Leads”:

1. Add an extra condition for a project proposal, that it includes at least an initial impact statement, summarizing how these four topics could be affected by the project.

2. Add an extra obligation on project leads, to keep this statement up-to-date as the project progresses.

I'll try to come up with exact wording for tomorrow.