Re: working groups


Mic Bowman
 


> 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 toc@lists.hyperledger.org to automatically receive all group messages.