W3C

– DRAFT –
PWE/IDCG weekly meeting

06 July 2021

Attendees

Present
Annette, annette_g, Barbara, hober, Jeff, Judy, Mallory, Ralph, Sheila, Tobie, tzviya, wendyreid
Regrets
Jemma, WendySeltzer
Chair
Tzviya
Scribe
wendyreid

Meeting minutes

<tzviya> Agenda

Revised ombuds job description + selection criteria and interview techniques

sheila: Working on the job description for the ombuds role

<sheila> https://github.com/w3c/PWETF/pull/180

sheila: I just incorporated the edits into the actual job description
… main changes were about the relationship between the ombuds role and formal procedures
… also a few questions around how folks are prepared for this role
… training would be part of this role
… and we need to still figure out the nature of the training
… hopefully these edits are relatively straightforward and clarify
… just to reiterate, this is meant to complement a formal grievance process
… it is not intended to replace it
… the idea is that the ombud is a neutral third party, someone to talk to, or to assist with the grievance process
… the research indicates that people are more likely to report when there are options
… the ombuds are meant to help the process run quickly and smoothly

<Ralph> https://github.com/w3c/PWETF/pull/180

Ralph: Thanks, maybe you could expand briefly on the implication of dropping the word peer

sheila: There were a couple of comments where people found that confusing, uncertainty about the role
… the person may not actually be a peer
… the people who are engaging as ombuds should not be leadership in the W3C, and I made that language more clear

Ralph: Thanks

tzviya: I'm guessing people have not had a chance to review this
… so we'll vote on this later
… thank you for the edits

sheila: One of the things we talked about was how to select ombuds
… what the process would be for vetting them
… one of the things we thought was the idea of treating as a proper interview process
… treat it like an actual position
… it might be good to have a representative from all of the regions
… open to other ideas
… people could nominate others or self-nominate
… and then there'd be a committee to select
… there would be requirements in the job description
… and an interview guide
… outstanding question is how many people do we want on the committee, and how do we choose the ombuds
… we want it to be intentional
… it's an important and sensitive role
… any thoughts and questions?
… I'll put together an interview guide

tzviya: Any comments?
… I guess everyone needs some time to digest
… thanks so much Sheila

Early draft of Disciplinary Procedures

<tzviya> https://github.com/w3c/PWETF/blob/main/CEPCdisciplinary-process.md

tzviya: This is based on a disciplinary process from Tetralogical, based on UK standards, some of this doesn't apply to us, like salary
… there's a list of open questions based on the questions from Wendy S
… I would appreciate feedback here
… the current process is really vague
… doesn't define what merits discipline and is very tied to the director
… has a strikes system, but I'd love some suggestions

<Zakim> tobie, you wanted to point to Contributor Covenant for this: https://www.contributor-covenant.org/version/2/0/code_of_conduct/

tobie: I just wanted to say this looks like a good start
… reminds me of the contributor covenant
… this is used a lot in open source so is releveant

tzviya: Thanks
… does anyone have any feedback on who should be enforcing this
… we had this discussion with CEPC
… I hesitate putting it in the hands of the director

<Barb_H> Comment - Level of aggrievance?

tzviya: since we're moving to director-free, we're moving to a board of directors
… is this something we ask chairs to do?
… but chairs sometimes are violators as well

Barb_H: With the grievance, I like the overall strategy, but sometimes the offense is small/medium/large, I worry about using a heavy process for all of them
… I wonder if there is a way to score a grievance
… minor vs major
… I don't have an easy answer

hober: On the question of who enforces
… like you mentioned, chairs are also potential violators, but are also responsible for running meetings, where violations can occur
… I think there's a real value in swift action
… making it clear immediately that something is inappropriate
… if someone violates CEPC during a meeting
… and I as a chair corrects it to keep the meeting running, it's not exactly confidential
… it's best if you can to pull them aside
… but an hourlong phone call
… the important thing there is to correct in a way that says "this is wrong" to everyone
… chairs should be part of the solution

<wendyreid> +1

<Zakim> tobie, you wanted to talk about how Node.js does this (in terms of prevention / upfront work) and OpenJSF (in terms of escalation strategy)

tobie: I just wanted to mention about light vs more grave ones
… node.js has process on this
… removing offensive comments/approaching people before a grievance process
… to understand people who are being problematic
… work that happens before you enter an enforcement situation
… educating people instead of defaulting to punishment
… openjsf has an escalation process
… every project can handle CoC violations on their own
… using whatever resources they have
… but there's an escalation strategy to a structure that's owned by the foundation
… in case you're not happy with the project-level management or the leader in that project is the one being problematic

Judy: To comment on the severity issue
… I agree it's important
… it's very common that most issues fall into a grey zone
… it depends on the people in the meeting
… I'm interested in the early-stage education approach
… I just re-reviewed the CEPC
… I was trying to recall if we tried to tackle severity, and I think we dodged it
… I think there's work to do in gauging that

<tobie> OpenJSF code of conduct and escalation approach: http://code-of-conduct.openjsf.org/

Judy: it's a thornier one

hober: Something that just occurred to me
… if we do make a distinction between minor and major
… I think it should be explicitly called out
… instead of left to enforcement
… we often see rules clearly written, but not enforced for the dominant group, and weaponized against those on the margins

<tzviya> https://www.w3.org/Consortium/cepc/#safety-versus-comfort

<tobie> +1 to hober's point.

hober: people who have been around for awhile may get more lenient treatment

<sheila> +1

hober: newcomers may be squashed for being unfamiliar to our process or groups
… less room for interpretation

tzviya: I think that's an excellent point, and I think maybe should go into the safety vs comfort section

sheila: One way to address that point, being explicit about priorities
… in the safety vs comfort section
… whose safety is prioritized, why, and when
… this isn't meant to be a blanket and vague policy
… that inevitably will be inequitebly applied

tzviya: There's enforcement powers and a grievance process
… can't be weaponized
… there's a difference between annoying and violating CEPC
… some of the other questions are what are the relationships to the membership agreement, can this be doctored, what about rapid response
… rapid response might be something we're best equipped to respond to
… I think that needs to be documented
… we have contact emergency services, but what about the fallout

<Zakim> tobie, you wanted to share: https://github.com/mozilla/inclusion

tobie: I just wanted to share the mozilla resource which is their work on this

Grants for the Web

jeff: There's an organization called Grants for the Web, a non-profit that gives grants for proposers who would like to experiment on new approaches for web monetization
… with privacy in mind
… closely affiliated with Coil

<Ralph> Grant for the Web

jeff: about a year ago they approached W3C
… when folks are working on better web monetization

<Ralph> [Founding Collaborators: Coil, Mozilla, Creative Commons]

jeff: they would really like their grantees to do it in a way that allows the protocols to become open standards
… as unpropriatary as possible
… and adhere to our principles of security, accessibility etc
… because of vendor neutrality, we can't advocate a position on monetizing the web
… we constructed the proposal that allows us to give advice, we would be available to consult
… through the lifecycle of the ecosystem, from proposal applications, judging, and that the work is developed with accessibility, i18n in mind
… we published our intention to participate
… it's going along pretty well
… one of the aspects of the proposal
… the web monetization approach is focused on diverse content creators who may not be able to monetize their content under the current model
… focus on diversity, especially geographic diversity
… which aligns with our goals
… one of the components of the agreement
… if we notice that some of their grantees are working on things that impact standardization
… if these grantees are small orgs from underrepresented regions, Grant for the Web would pay for their membership
… that's been going pretty well
… Grant for the Web set aside 25k for memberships
… membership from lower-income regions is under 1k
… important thing is having more diverse members joining W3C

tzviya: That leaves us time for survey updates

Survey updates

tobie: So the initial idea was to have a survey to better understand the composition of our membership
… across leadership, chairs, staff, editors
… OpenJS foundation is looking at the same
… advised to look at 2 options
… essentially because W3C has a direct relationship with everyone involved in standards, OpenJS doesn't, there's GDPR challenges
… the answer seems to be that on the OpenJS side, we can't do it and abide by GDPR
… so sharing the upfront cost of sharing questions and things fall through
… we'd have to do a completely different system on their side to get the same data
… the overall cost of one of the solutions would not be split in two
… one solution is 25k/year
… it's a lot
… the fact that if we pursued something like that, we'd not have to pursue GDPR issues
… the cheaper option, 3-4k
… I want to go back to that option and explore it more

tzviya: Can you clarify?

tobie: W3C has a direct relationship with all members and staff
… it's ok for us to send a pointer to our mailing list
… OpenJS doesn't have this at all
… the project maintainers have this kind of relationship
… and OpenJS has relationships with the projects
… people don't have email relationships over email, mainly github
… I couldn't get a clear idea of if extracting emails from Github would be GDPR compliant
… wanting to do things ethically made this tricky

tzviya: If the main method of communication is GitHub, could posting the survey there be a method?

tobie: Maybe, but hard to know, might be biased
… maintainers not all on board
… might be biased depending on the project

tzviya: Sounds like the next steps would be to look into the cheaper option

tobie: The original set of questions are from the OpenJS
… from the StackOverflow survey
… and now I have to inquire on the IP status and if we can use them
… in short, more complicated

<Barb_H> Question - Did we want to ask a question to Stackoverflow or Slashdata? Slashdata is survey now.

tzviya: Could we get an update in 2 weeks?

tobie: Yes

Barb_H: Slashdata is now just executing their survey to be available in the fall
… is there any way we can influence the type of questions that get asked
… that meet our needs around standards
… is there any way we can ask a question to be answered in that survey

tobie: I haven't thought about it
… the idea was more to use the same questions they're using
… because they were good and had been worked on and thoughtful
… and also they implicitly had a way to compare our community to the broader community
… point out things that are better/worse than the general community

Barb_H: The way we look at it, primary vs secondary
… primary, alignment with the SO questions, but I think there are secondary surveys out there where we might find some insights
… the other day, the game group found a survey for game developers, asking what APIs they use
… we want to know what different communities are doing
… could we view or influence the secondary level of surveys

tzviya: The only thing that might be similar is the WebAIM user data survey

Barb_H: The gaming one was interesting, asking for APIs, what environments

<Zakim> tobie, you wanted to mention MDN survey

tobie: There's the MDN survey too
… there's options there as well
… the scope is similar

<tzviya> https://hacks.mozilla.org/2019/07/mdn-web-developer-designer-survey/

tzviya: I think the MDN survey has only come out once?
… we can look at different surveys and see whats out there, and Tobie's proposla

tobie: Will look and report back

<Barb_H> Comment - Game Survey - Interesting reading - https://gamedevjs.com/survey/2021/

tzviya: AOB?
… thanks everyone!

Minutes manually created (not a transcript), formatted by scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).