1. Messages
  2. working groups

Re: working groups

Hart Montgomery
 

Hi Everyone,

 

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. 

 

Thanks,

Hart

 

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

> implicit teeth.  

 

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.

 

--mic

 

 

On Thu, Sep 12, 2019 at 11:21 PM Brian Behlendorf <bbehlendorf@...> wrote:

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.

 

Brian

 

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.

--mic

 

 

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf
Join tsc@lists.hyperledger.org to automatically receive all group messages.