toggle quoted messageShow quoted text
Some points on this:
I don’t think it matters what we name these groups. If we want to keep the name of “working group,” that’s fine.
The main point we have noticed is that long-term, work-product focused groups haven’t really worked. So we want to subdivide into two things: non-work product-focused
groups that are long-term, and short-term work product-focused groups that have clear deliverables and a clear timeframe. We would call the first “working groups” and the second “task forces.” This is more or less what is written in the proposal.
Active maintainers and contributors are going to be more likely to put work into short efforts with clear timeframes and outcomes, even if there is a distinct
possibility of failure. So I think task forces are our best shot at getting cross-project collaboration and integration. We can set bite-sized goals and tackle things little by little.
In an ideal world, the non-work product-focused groups can function as “motherships” that “spin off” task forces.
If you’ve made it this far, thanks for reading my rambling email.
From: tsc@... [mailto:tsc@...]
On Behalf Of Mic Bowman
Sent: Friday, September 13, 2019 9:48 AM
To: Brian Behlendorf <bbehlendorf@...>
Cc: Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] working groups
> I believe if we set the expectation that the working groups be
> driven by the projects themselves - that is, the rationale for
> their formation, the bulk of activity, the work products created -
> come from active maintainers and developers on the existing
> projects, and not from people who are not writing code, that will
> self-regulate the number well and I believe give them more
Given where we're at for project participation in working groups... i think this effectively kills working groups (which at this point is a good thing IMO). cross project collaboration doesn't require a working group; in places where it
is appropriate it is already happening. the work being done in working groups right now has little impact on the projects themselves.
And I don't really care if we call the "discussive" form a working group or a SIG (its just a label). But... drop expectations of work products from them (move all work product focused activity to a task force that can complete a focused,
time-bounded effort.. these have been very successful). Hart suggested quarterly (too frequent) or yearly (probably not frequent enough) reports on who's been participating & what's been discussed is sufficient.
On Thu, Sep 12, 2019 at 11:21 PM Brian Behlendorf <bbehlendorf@...
Please please please let's not call them SIGs! For the sake of avoiding confusion with the existing SIGs and their reporting structure. I realize that we use WG in a slightly non-standard way compared to other orgs, but if we have ongoing
persistent cross-project thematically-organized groups, let's keep calling them Working Groups, OK? Adding time-bound tightly scoped Task Forces is fine (and what we're already doing, essentially). Too much semantic thrash makes it difficult to keep everyone
on board, is my main point.
I am for considering cutting down on the number of Working Groups by rebooting from zero and re-chartering. I believe if we set the expectation that the working groups be driven by the projects themselves - that is, the rationale for their
formation, the bulk of activity, the work products created - come from active maintainers and developers on the existing projects, and not from people who are not writing code, that will self-regulate the number well and I believe give them more implicit teeth.
Imagine restarting from zero WGs, and saying to add a new one, there must be not just interest but commitment from a majority of projects to have at least a representative attend and use it to coordinate their related efforts. E.g., if the projects don't
care enough about coordinating cross-project around the topic of Architecture or Identity to ensure they are involved and attending the calls and participating in conversations and aligning their dev roadmaps, then don't create it. We need some form of cross-project
info sharing outside the context of TSC calls, thematically scoped and ongoing, but not so many that efforts are diffused or fail to hit critical mass. I think that would address criticisms of the WG model to date.
On 9/12/19 9:22 AM, Mic Bowman wrote:
per the brief discussion in the TSC this morning, the core proposal from the WG task force is that we replace working groups with technology focused SIGs (where discussions happen) and task forces focused on a short term deliverable (where
the deliverable must be completed in less than 6 months, for example).
the list of proposals is here:
please comment (and, while we have withdrawn proposals 1 and 2, please read the discussion on them for context).
specifically... here's where we're at:
Proposal 3: Working groups should be dropped.
Proposal 4: Formalize "task force" as a task-specific group with limited scope and fixed time to complete.
Proposal 5: A task-force will be required to create a "proposal" and the TSC must approve the proposal.
Proposal 6: The task-force leader will be required to report on completion of deliverables.
Proposal 7: A task-force that requires additional time, must request an extension from the TSC.
Proposal 8: Existing working groups will be converted into a technology focused SIG.
Executive Director, Hyperledger