Proposal to formalize the processes for Working Groups

[benjagm]

Abstract

As our community grows we'll need to establish working groups to collaborate more efficiently and empower everyone to lead initiatives. We are doing references about working groups in our (yet to be completed) Charter and there are no specific rules around them what slow down its adoption.

This is my proposal for defining Working Groups for JSON Schema:

Definition of a working group

A working group is a group of people in our community who share a common interest beyond GitHub repositories.

A working group must have, at least, one of its members appointed as its chairperson.

Anyone can create a working group. The only prerequisites are to have at least 2 founding members and the approval of the TSC.

A working group should have its own set of goals or objectives. This helps everyone in the working group to stay aligned. The goals must be public and easily accessible by anyone on the internet.

It's recommended that a working group has an associated issue where the group outlines their roadmap. In addition it will be highly recommended the usage of a GitHub Project to make it easier for others to collaborate. It's up to the Working Group to decide the structure of the project. E.g., Kanban, Shape Up, TO-DO list, etc.

The name of the group, its members, the goals, and any other relevant information must be listed in the WORKING_GROUPS.yaml file in the community repository.

A working group has no decision power over the roadmap of the projects they may impact. It's up to the maintainers of the repositories involved to approve or reject the resulting pull requests. Therefore, it's highly recommended to either have maintainers of the impacted projects in the working group or make sure everyone is in agreement before deciding about the roadmap of the different repositories/projects.

As soon as the feature is ready, working groups will be listed in the JSON Schema website along with their description, goals, members, an anything the working group wants to include.

Additional benefits

• Working groups become more discoverable.
• Coordinated effort across different projects/repos.
• Bounty program can also target working groups, especially for tedious tasks.
• Increased transparency of the structure of our community.

What do you think about this proposal?

Please share your thoughts so we create together the best proposal for our project!

Thanks @fmvilas for the inspiration.

[jdesrosiers]

Do we really need this? We've never had working groups here, so it seems premature to formalize processes for working groups. If the concept of working groups is something we want to try, I'd suggest trying it first to see how it works out for us. Then if we like it and want to more working groups, we can take what we learned about what works and what doesn't and formalize it.

[gregsdennis]

I agree with @jdesrosiers: this seems premature. What efforts do we have now that need special focus?

• The only real activity is the website.
• We have some test suite activity, but not enough to warrant a special group.
• We're not working on the spec directly right now because... reasons (that we know about internally).

Also, working groups are generally populated by members of the project. Other people are welcome to contribute to the discussion, but ultimately it's the WG that makes decisions. I'm not sure we have enough project members to warrant dividing us amongst multiple WGs. I foresee us (members) all just participating in all of them, just like we do now, making the WGs moot.

[benjagm]

Thanks for your feedback. As discussed in the last Community Meeting #688 we'll try the approach first with a working group to organize the JSON Schema Conference.