Proposed: A Working Group to help define Working Groups No, I’m not suggesting a top-down governance of working groups. What I’m suggesting is a group to discuss what a working group looks like and what kind of tools and processes we want to put in place to make sure that each WG isn’t inventing everything from scratch every time. This also makes it easier for folks to get involved in WGs, if they all look similar, and you don’t have to relearn everything every time.
Topics would include: * Where to we want to track WG status? I would propose that we create GitHub.com/apache/community for stuff like this, to mirror GitHub.com/kubernetes/community, at least in spirit, but would like to discuss this with more people * Define an actual data file (See https://github.com/kubernetes/community/blob/master/sigs.yaml for a possible template) that tracks what WGs exist, who’s involved, what they’re working on. Or perhaps this is too heavyweight. Dunno. I just want to make these things more discoverable * Responsibilities. For example, I think a WG should report to the ComDev PMC, for visibility, accountability, and to show the board that we’re actually doing stuff. * Membership. Who can be a member of a WG? What’s the connection between WG membership and comdev committer status? Do we need a formal WG chair, or is that too heavyweight? I imagine that the WG WG would be short-lived, although anything decided can obviously be revisited, and evolve over time. And nothing here should be construed as “you can only do stuff if you stay within these guard rails.” It’s just intended to give more structure to people that need more structure. Clearly defining roles and hats can really help people get involved when they see a huge tasks and no obvious way that they fit into it. What do y’all think? — Rich Bowen rbo...@rcbowen.com
