Initial draft of roles and responsibilities.

[juliepagano]

This is a very rough initial draft of roles and responsibilities based on discussions in #65. I have a bunch of open questions that I've thrown in here in bold and need feedback on in addition to general feedback on what's here.

[beaugunderson]

re: the time commitment of 10 hours a month; there will be two meetings which have usually been about an hour including setup/post-meeting conversation, leaving 8 additional hours of commitment, or roughly 15 minutes a day--my feeling then is that we shouldn't expect less than 10 hours of commitment form members

[beaugunderson]

re: responsibilities around the CoC, it's probably important to list enforcement of the CoC as one of those responsibilities

[juliepagano]

It sounds like we may want a different label for this role as the term "collaborator" has some different meanings outside the WG and could lead to confusion.

[juliepagano]

Thinking "contributor" might be a better term here. I'll check it to reflect that unless I hear any objections.

[varjmes]

What does collaborator mean elsewhere? Contributor sounds good to me :)

[nebrius]

I think this depends on how we define "contributor." The other working groups don't identify a "contributor" role, they just have "members" and "everyone else." Will this role be something that's in between "member" and "everyone else"?

[juliepagano]

It seems like it's the "everyone else working in good faith" role (i.e. everyone else minus trolls).

[nebrius]

So a broad question about contributor: Do we want to introduce a third role with them (on top of members and non-members/"everyone else"), or is contributor the term we use for "everyone else"? If it's the former, do we want to construct the role as "we vet candidates first via an application process"? Or do we want to do a "everyone who asks gets it, and we can ban later if they violate the CoC"? If it's the later, this can be automated.

[varjmes]

I see no harm in mentioning the members-only (private) part of the Slack channel, so someone can know their full responsibilities when they apply to join :)

[varjmes]

This is really great and clear to understand ✨

[carlosrymer]

@beaugunderson brought up a good point about potentially having an SLA around responsibilities for members. It's pretty vague right now how "a significant amount of time" will be determined.

While I think it's perfectly fine to start off enforcing responsibilities based on WG members' personal considerations, it might be more fair to have something like an SLA to point at when WG members raise concerns or suggest transitioning to a contributor role.

This might be unnecessary at the moment, but as new members become part of the WG over time, it might be useful to ensure that folks are held accountable to some level of participation and contribution.

[nebrius]

So I've been thinking about this a lot recently. I think there are two basic approaches we can take.

1. we strive for a low number of members and high level of participation, which is more or less what we have now. This would necessitate an SLA or something like it, and would effectively need an arbitration/moderation process to manage members not meeting expectations. This approach has the advantage of keeping it obvious who the "go to" people are, and should also make the decision making process easier. This approach has the disadvantage of being more work to implement and sustain, especially if an arbitration process gets messy, and puts the group at greater risk of burnout.

2. we strive for a higher number of members with lower participation. Maybe in the neighborhood of 20 members, say. This method has the advantage of simpler administration (no SLA) and greater robustness to burnout. This has the disadvantage of making it harder to make decisions, and may place a greater burden on the most active members in terms of management (not sure about this)

I used to be strongly in favor of 1), but these days I'm starting to think 2) may have its benefits.

[carlosrymer]

I can see how 2) can be beneficial. Even if there are some members that consistently are more active than others, it's still a win-win having more members being able to contribute, even if it's not as much as the current level of contribution of existing WG members.

At the same time, I do think that the side effect -- greater difficulty in make decisions -- can be pretty huge and potentially divisive if there are a lot of members. It would be ideal of voting could be flexible such that the most active members carry more weight, but then that's not going to be quite easy to figure out in a fair way.

It would be great to strive for 2) while minimizing its side effects. Might be something worth researching to see if there are case studies of groups that allow for greater membership while remaining effective in its decision-making process.

[juliepagano]

Sorry it's been taking me so long to make updates to this. I've been swamped at work. I've made a few updates. Could folks take a look some time this week, so we can hopefully land this soon?

[juliepagano]

@Charlotteis Good catch! Added that for both members and non-members.

[juliepagano]

@carlosrymer Good question. I think that's potentially out of scope for this document, but something the WG needs to figure out, so that we have a good process ahead of time instead of trying to come up with something ad hoc if something bad happens.

At a minimum, it probably includes removing someone from slack and not allowing them to attend as a participant in WG meetings.

[nebrius]

Maybe we can add a blurb such as

Members are expected to follow the our [Code of Conduct](link). Members
who violate the Code of Conduct may face temporary or permanent suspension
of their membership.

[carlosrymer]

@juliepagano I agree. It does sound more like something that doesn't need to be specified in this document, but can instead be agreed upon by the WG. Right now the document already implies that non-member permissions (with the exception of Github permissions since that can't really be controlled) would be lost.

[nebrius]

Reflecting back to the meeting last week, what do you think about dropping the first sentence, at least for now?

[juliepagano]

Is there any chance another member has time to put the final touches on this and respond to some of the comments? I've been overloaded at work this week and will be out at an offsite next week, and I'm worried about leaving it untouched for that long.

[nebrius]

@hg, do you think you can help out @juliepagano with this PR? If not, I can help.

[ghost]

@nebrius aye

[ghost]

@juliepagano should i fix some of the nits here?

[nebrius]

@hg I'd say yes, go ahead and fix the nits.

[ghost]

@nebrius if this works as i think it does, i'd have to push a separate pull request to julie's fork, wouldn't i?

[nebrius]

@hg, there's a couple of options. You can set @juliepagano's fork as a remote on your local copy git remote add... and pull in her changes. Once you've done that, you can PR back to Julie's fork, or you can create a new PR to this repo and have it supercede this PR, which might be better since Julie's still swamped (right?)

[ghost]

#106 exists now, will close this when the other PR is merged