Docs: Add working groups to maintainer guide

[nzakas]

What is the purpose of this pull request? (put an "X" next to item)

[x] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

What changes did you make? (Give an overview)

Per the TSC meeting, this fleshes out how I envision working groups work. As best I can tell, this is how we've been doing things already and I'm just trying to document it. The only real change would be specifically listing out the working groups.

Is there anything you'd like reviewers to focus on?

Does this make sense?

[platinumazure]

Minor issues, but the proposal seems reasonable to be.

[not-an-aardvark]

In practice, is there a significant difference between:

• an official working group
• a group of team members collaborating on something without an official working group

...aside from the former having more clarity of structure?

I'm not sure I understand the advantage of requiring a TSC motion to create a working group and imposing limits on the size of working groups, in comparison with just letting team members create ad-hoc working groups through GitHub teams.

It seems like if some people want to collaborate but don't meet the requirements here, they would probably just decide to collaborate anyway without creating an official working group, which wouldn't be ideal from a documentation perspective.

[nzakas]

As I mentioned in the meeting, the goal here is to make things explicit that up until this point have been implicit. For instance, if Kai and I had just disappeared and put together a website redesign on our own, then dropped it into an issue somewhere, that would be a bit jarring for the team. Maybe someone else was also working on a site redesign, or maybe someone else wanted to be involved.

Requiring a TSC motion means that there is a record of when a working group was formed and what for what purpose, so it's always easy to go back and figure out where it came from. It's also an opportunity for the team to weigh in and suggest who else might be good for the working group.

As I think we have a bunch of functional areas that some people are interested in, but not others (ops, finance, security, etc.), it seems like knowing who is actively working on these areas would be beneficial to the whole team.

[ilyavolodin]

Sorry, but I'm still not seeing the point of making this official policy. Whenever people want to start doing something, it my opinion, it's perfectly fine to announce it on gitter (or mailing list) and see if anyone else wants to participate. I'm not a fan of having policies for the sake of having policies.

[not-an-aardvark]

I agree with @ilyavolodin. At the moment, our working groups are ad-hoc and undocumented. If the goal is to make things explicit that were previously implicit, then it seems like the natural step should be to make working groups ad-hoc and documented, and I think that change would be worthwhile (we could document the groups through something like GitHub teams). Requiring TSC approval for working groups seems like it would have the unrelated effect of making working groups not ad-hoc. It's not clear to me that such an approval process would be valuable over gitter/mailing list announcements, and it doesn't seem like it relates to the stated goal of making our existing process more explicit.

[nzakas]

I'm fine with going the ad-hoc and documented route as a compromise. Would you both be open to the requirement that someone starting a working group should send an email to the team mailing list and create a GitHub team?

[not-an-aardvark]

Sure, that works for me.

[ilyavolodin]

I guess I'm fine with that, I'm still not sure I see the point of having a GitHub team for, let's say server management, or website design. But I guess it's not a very large overhead to create one.

[nzakas]

The point is just to keep track of who is doing what. We could use another system, but since we're already modifying teams in GitHub for other things, it seems like the path of least resistance rather than introducing something new.

…

On Fri, Mar 8, 2019 at 9:45 AM Ilya Volodin ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In docs/maintainer-guide/working-groups.md <#11400 (comment)>: > @@ -0,0 +1,22 @@ +# Working Groups + +The ESLint TSC may form working groups to focus on a specific area of the project. + +## Creating a Working Group + +Working groups are created by a standard TSC motion. Each working group: I guess I'm fine with that, I'm still not sure I see the point of having a GitHub team for, let's say server management, or website design. But I guess it's not a very large overhead to create one. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#11400 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACWkhSHcuD02tqIXql5pT9ruRlWGMFYks5vUqGygaJpZM4a92Fa> .

--

______________________________ Nicholas C. Zakas @SlickNet Author, Principles of Object-Oriented JavaScript <http://amzn.to/29Pmfrm> Author, Understanding ECMAScript 6 <http://amzn.to/29K1mIy>

[nzakas]

TSC Summary: This is the proposal for the formation of working groups, a loose way to organize and keep track of who is working on what on the project. WGs can be created by sending an email to the team mailing list to ask for interested team members, and then creating a GitHub team to signal who those members are.

TSC Action: Shall we accept this proposal?

[not-an-aardvark]

This proposal was accepted in yesterday's TSC meeting.

[not-an-aardvark]

LGTM, thanks!

All of the comments have been addressed.