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.

Sign up for GitHub

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

Jump to bottom

Docs: Add working groups to maintainer guide #11400

Merged
merged 3 commits into from Mar 15, 2019
Merged

Docs: Add working groups to maintainer guide #11400

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
fc44d6c
Docs; Add working groups to maintainer guide
nzakas Feb 15, 2019
fa8ecb0
Fix wording and URL
nzakas Feb 18, 2019
721209e
Update working groups docs
nzakas Mar 13, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
4 changes: 4 additions & 0 deletions docs/maintainer-guide/README.md
View file
Open in desktop
Expand Up @@ -17,3 +17,7 @@ Describes how to do an ESLint project release.
## [Governance](governance.md)

Describes the governance policy for ESLint, including the rights and privileges of individuals inside the project.

## [Working Groups](working-groups.md)

Describes how working groups are created and how they function within the ESLint project.
22 changes: 22 additions & 0 deletions docs/maintainer-guide/working-groups.md
View file
Open in desktop
@@ -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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, that works for me.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


1. Must have a GitHub team under the "Working Groups" top-level GitHub team.
1. Must have at least one TSC member.
1. May have any number of Committers and Reviewers.
1. Must have at least two members.

Active working groups are listed on the [team page](https://eslint.org/team).

## How Working Groups Work

Each working group is responsible for its own inner working. Working groups can decide how large or small they should be (so long as there is at least two members), when and who to add or remove from the working group, and how to accomplish their objectives.

Working groups may be temporary or permanent.

If working groups intend to make a significant change to the ESLint project, the proposal must still be approved by the TSC.