• What is the role of working groups given the ongoing maturation of projects in HL?
    • Prescriptive: the working groups prescribe direction for projects
    • Descriptive: working groups generalize what is already being done in the projects
    • Gap analysis: identify "what's missing" from the current projects
    • Integration analysis: identify "common components" that could be extracted
    • Emerging trends-vision: Provide a platform for "vision" of what is out there in the field. New ideas from members. Reports from influential conferences/meetings
    • Platform for launch: we had Indy/Aries launched from ID WG, Caliper from PSWG 
  • How can working groups provide appropriate "recompense" for participation? Influence, notoriety, creativity, business value?
  • How else can we motivate (or at least reduce the barrier) to participation?
  • What is the process for report outs? Historically, the white paper, architecture, and performance working groups completed documents that were brought to the TSC for final review and approval. This seems like a reasonable model and should be standardized.


  1. (deprecated) Proposal 1: Working groups should be scoped to a specific task or problem rather than a general area.
  2. (deprecated) Proposal 2: Working groups should not be required to produce specific work-products.
  3. Proposal 3: Working groups should be dropped.
  4. Proposal 4: Formalize "task force" as a task-specific group with limited scope and fixed time to complete.
  5. Proposal 5: A task-force will be required to create a "proposal" and the TSC must approve the proposal.
  6. Proposal 6: The task-force leader will be required to report on completion of deliverables.
  7. Proposal 7: A task-force that requires additional time, must request an extension from the TSC.
  8. Proposal 8: Existing working groups will be converted into a technology focused SIG.

Note that the issue of formalizing structure of the SIG is outside the scope of this task force. We do, however, recommend that technology focused SIGs go through a similar proposal process that is ratified by the TSC. 


Learning materials working group provides a very good example of the challenges with the current working group structure. Those participating in the working group often sit "outside" of the projects themselves. As a result, participation (specifically participation from the projects) is very difficult. 

There is a fairly strong sense that the working groups should be focused on the "glue" between projects.

See discussion here:

  • No labels


  1. Hello,

    Please contact me with any question pertaining to the LMDWG.  We have undergone several changes and have a new direction.

    Bobbi Muscara, Chair, LMDWG

    • What is the role of working groups given the ongoing maturation of projects in HL?

    My answer will be all of the above (maybe not the prescriptive stuff as we cannot make this stick) and should be expressed in the blog post I mention below.

    another suggestion will be as a standing conference and a collection of high quality and curated reference material on the WG topic: easily reachable and searchable. We are making progress in this area for PSWG (as a repository for reproducible metrics for HL DLTs and others) 

    • How else can we motivate (or at least reduce the barrier) to participation?

    a. Write a general justification for the existence of WGs and SIGs. This can be in terms of a blog post prominently displayed and reachable.

    b. The landing page has to have a list of WG graphics (the logos as they stand for WGs are colorless and insipid compared to the vibrant logos for projects) and links to the wiki pages.

  2. Here’s my thought process on the working groups and what we should do to help them.  I’m sorry for the incredibly long wall of text. If you read this all the way through, then, bless your heart, you are a saint.

    Working groups in Hyperledger are currently not in great shape.  Just going through them, one by one, reveals the problem:

    • The architecture working group, once considered the flagship and example of how all working groups should work, is down to about 5 core participants.  Most meetings usually have 3-4 people participating.
    • The performance and scale WG has also been bleeding participants and has had its participation rates decline.  Mark Wagner has talked about this at length, so I won’t continue here.
    • The smart contracts WG seems to have had 3 and 2 people in its last 2 meetings, respectively.  While I’m not familiar with the WG and I don’t know the participants too well, it seems that this group is struggling too.
    • The learning materials and development WG has struggled for traction its entire existence (it’s tough to get people to do this kind of work).  Bobbi Muscara, the chair, has recently commented that the group has undergone changes and is headed in a new direction.
    • The diversity civility and inclusion working group is brand new, so I won’t consider it much here.  It’s also a little different in scope from some of the purely technical groups.
    • The Technical Working Group China is unlike any of the other working groups.  It has a different format and goal then all of the rest.  It seems to work very well, and, if possible, I’d like to see other similar groups (i.e. a TWG Japan).
    • The Identity WG has had a renaissance lately due to the fantastic efforts of its chair Vipin Bharathan.  However, this has partially been the result of mostly ignoring the TSC directive for working groups to focus on work products (of which I personally approve, by the way, and I will argue later that we should change the structure of WGs to mimic this).

    So there you have it.  People, by and large, aren’t participating in working groups.  But that wasn’t always the case. Why did this happen, and what can we do about it?

    As an anecdote, let’s talk about what has happened with the architecture working group.  I’ll use this as our working example since it’s the group I have participated in the most.  In the beginning, lots of people joined the architecture WG meetings. We had various insiders and outsiders give talks about blockchain architecture, and we used these to fuel discussions on what an ideal blockchain architecture should look like.  In my opinion, some of the really good ideas in Hyperledger came out of these discussions: why componentization would be an optimal long-term strategy, a focus on interoperability, and an emphasis on cross-project collaboration. From a personal perspective, the idea for Ursa came out of some of these discussions with people like Ram, Nathan, Mike, Dave, Mic, Dan, Arnaud, Binh, and more.

    Eventually the TSC decided that working groups should be focused on work products. So the architecture group decided to tackle some blockchain architectural problems and write a report on them.  The first paper was on design philosophy and consensus. It took a considerable amount of work to get done. Attendance at meetings started to decline a little bit, because people didn’t want to spend time working on a paper--they’d rather listen to a talk on architecture or have a discussion on how to design blockchains.  In addition, the focus on paper work made it hard for newcomers to join in and get started.

    The real death knell was after the paper got published.  When the paper was published, it seemed to be generally ignored by most of the community.  Unlike the discussions, we couldn’t find any area where the paper output had affected actual Hyperledger production systems.  So most of the group thought that the paper hadn’t accomplished much.

    Fast forward to (roughly) a year later.  The focus on papers that aren’t getting read has caused the group to grow smaller.  People have become discouraged and really aren’t doing much at all to make progress on the working progress.  Attendance at meetings is down to about 5 core people, with maybe a person or two outside that list joining for a meeting (and never returning).  Progress has stalled. I doubt any more substantial work will be done, because the core contributors think that the work isn’t having any effect on Hyperledger as a whole.

    So what do we do about this?  I don’t think the architecture WG is unique here.  Most of the working groups seem to be caught in some kind of death spiral, and something clearly needs to be done.  I think there are two ways forward that have been discussed in the community, which I will outline below.

    The SIG Route: 

    SIGs have become enormously popular recently at Hyperledger.  As presented at the member summit, the Medical SIG has over 1000 members!  That’s just insane, and (probably) more code contributors than in all of Hyperledger.  Why do people join SIGs? I suspect because, as Vipin put it, they are good “remote conferences” where people can learn about topics and meet other people interested in the same subject.

    Right now, there really isn’t a practical distinction between SIGs and WGs.  The only difference is that SIGs are easier to start, have fewer reporting requirements, and don’t have to deliver work outputs to TSC.  It would be one thing if the work outputs actually mattered, but, so far, they really haven’t. So there are few practical advantages to having a WG over a SIG.

    As another personal example, I’ve been thinking about putting together a group related to academic involvement in Hyperledger.  The goal would be to help get academics to add their work to Hyperledger (in code) and for maintainers/developers to give research problems to academics.  I’ve written up a (very rough) draft of a SIG proposal for this. Despite the technicality involved, I chose to write a SIG draft proposal instead of a working group proposal for the very reasons I mentioned above.  While I can’t say for certain, I suspect that some of the SIGs that are popular today made the same calculation.

    I also suspect that the architecture WG would have much more participation if we rebranded it as a SIG and dropped the focus on work products.  Moving back to the original agendas which consisted of talks and discussions rather than paper-writing would almost certainly increase participation.  In fact, if we don’t make progress on these WG issues with this task force, I might suggest to the few remaining regular architecture WG participants that we close down the WG and start a SIG instead.  Since approval for SIGs is easy (at least seemingly), we could certainly do this if we chose to do so, despite the fact that the optics wouldn’t be fantastic for the community (and the deep irony of a group laden with TSC and governing board members making a change to escape TSC regulations!).  

    The identity WG has essentially been doing this recently, and it has worked well.  While not every group will have a leader as enthusiastic as Vipin, it certainly is a model that others could emulate.

    So, to summarize this section, one possible route forward for working groups is to eliminate mandatory work products and allow the groups to focus on talks and discussions.  Anything that absolutely needs an output could be added as a task force.

    Give Working Groups Teeth

    The other (probably less popular) option is to make the work outputs of working groups actually meaningful.  This would mean allowing them to issue mandates to projects based on their findings. Projects would have to satisfy the WG mandates or face consequences in some form. 

    The biggest issue with this is that projects would be deeply uncomfortable with being told what to do by a WG, and I suspect this is a total dealbreaker for many in the Hyperledger community.  But, as an exercise, let’s see what it looks like.

    In practice, giving working groups teeth would definitely spur more project participation in working groups. Projects would be afraid of a haywire WG issuing a bad mandate, and thus would have people participate.  Utilizing fear to get what you want is essentially terrorism, but if the TSC wants to become terrorists to make WGs popular again, it would be an effective strategy.

    Consequences for projects that don’t follow WG mandates would be tricky, but definitely doable.  These could be in the form of marketing budget (or lack thereof), or the TSC refusal of major releases, for instance.  Getting this right might be difficult.

    While giving WGs some teeth might be an effective strategy in some cases, it seems a bit too much in general.  It will most likely add in more rules for projects in an open development to follow, which will not make developers happy.  This might be useful in very specific scenarios (i.e. a security team mandates that a project using an insecure crypto primitive upgrade to something secure as a condition of approval of a new release) but seems to be overkill for generic working groups.

    Perhaps a compromise here is to give certain task forces some teeth.  This way we could ensure that the scope is sufficiently narrow to not antagonize the projects. 

    My (Probably Bad) Opinion, in Summary:

    1. Take away the work output requirement from working groups and encourage them to focus on talks, discussion, and cross-project collaboration.  If this means getting rid of working groups entirely and just having SIGs, well, they’re mostly dying anyway.
    2. Create a task force for anything that needs a work product.  Keep these task forces narrow in scope and give them teeth.

    Brian’s Comments:

    Brian, in a recent email describes his vision of WGs and SIGs (his words, not mine):

    “Working Groups should be thought of as our connective tissue between projects - the cross-project place where discussions about identity, performance/scalability, architectural concerns, learning materials, and even diversity & civility issues can be discussed and iterated upon without that discussion being owned by one project or another.  In particular for anyone who holds architectural or product convergence as a priority, certain Working Groups like identity and architecture should be the place to articulate what that means, and then create specific technical plans that projects can follow. They only can serve that role well to the degree they are primarily driven by active maintainers and contributors on the projects themselves, but given critical mass there can be other participants on those working groups.  Creation of any new working group should partially be gated by whether it's reasonable to expect most of the projects to be able to have people actively following and participating in that new WG.

    Special Interest Groups are intended to be more of a bridge to the outside world - to people deploying our technologies for particular categories of use cases.  Those might be grouped by industrial segment, e.g. "trade finance". Or they may be grouped by a broad set of functionality, e.g. "supply chain", that is more of a recurring theme across all industries than a specific industry.  But the point is that a SIG should be composed of both insiders and outsiders - of both technologists close to what one or more Hyperledger projects are doing, and of those who may simply be "users" of the technology, perhaps even one or two steps downstream, but who is willing to share their domain expertise and involvement in active projects at a business level to drive adoption.”

    I agree with Brian’s point on a natural distinction between SIGs and WGs being that SIGs should be externally focused, and WGs should be internally focused.  But this doesn’t change the fact that no one wants to “create specific technical plans that projects can follow” if projects just ignore them, which is what is currently happening.  As long as this is the focus of the WGs and projects continue to ignore them, the WGs will continue to die.

    Update on SIG Process
    This was written under the assumption that getting a SIG approved required 15 names and approval from one LF staff member, which documentation said was the case in July (it may not have actually been the case, apparently, but it was on the wiki, and unfortunately I do not have a screencap).  Now the link to proposing a SIG is dead, and apparently the rules have changed (but documentation hasn’t been updated). So it’s probably not the case anymore that a SIG is easier to make than a WG.

    1. Hart, thank you for thinking this through so thoroughly, and thank you for noting my comments in reply on the TSC list itself.

      My sense is that you're closest to the right answer in wondering whether a focus on "work product" from working groups has been a part of the problem.  But I would counter that the Identity WG is working on a paper, and that a hubbub of activity from being an ongoing "remote conference" as Vipin put it would be that we'd see various artifacts emerge.  And, some SIGs have started to create content - the telecom SIG is working on a paper detailing how one would use HL Fabric to support roaming agreements, for instance. 

      I suspect the main challenge is more about leadership and less about structure or process.  If one agrees with my premise above that working groups are supposed to be the connective tissue between projects, then it should be a priority from the leading maintainers and developers on the projects to participate, to whatever degree they wish to be connected to other projects.  This isn't something we should have to mandate with rules or procedure.  This should be of obvious intrinsic value to any competent engineering leader (code-slinger, architect, or product-manager) to always be interested in what your peers (and competitors) are doing, and to look for areas of mutual overlap for collaboration, or where others have tried things and lessons learned.  If you're working on the identity part of Hyperledger Foobar, why on earth are you not taking advantage of the wisdom and expertise gathered in the Identity WG?  If you're working on the next-gen architecture for Hyperledger Foobar 2.0, why on earth are you not circulating that around to your peers on other projects, or asking them what they've done and trying to steal copy improve on their design?  It's software engineering malpractice not to take advantage of these community devices, to assume you have nothing to learn from others, or no reasons to explore joint work with others.  It's clear this cross-project collaboration doesn't happen spontaneously; and even when good ideas are shared at a face-to-face, it needs a home for ongoing conversation and planning.  WGs are that place.  I think it's reasonable for the TSC to require projects to monitor and be involved (as measured by async tools, not phone calls, which ask a lot) in each WG on the premise that each WG has something for each project to worry about.  That might even be the limiter on adding new WG's - is this an appropriate thing to ask ALL projects to monitor and participate in? 

      That's the "teeth" would argue for - not a commitment to implementing the decisions of the WGs, but a commitment to participating, even before it's known what the end results will be.

      If I can have a pony too, let's move away from phone calls as either the typical mode for WG participation or the measure of their activity and worth.


    1. SIGs vs WGs- Brian's framing is right. One is focused more on an Industry vertical (Supply chain/CM/TF etc.) and the other on technical horizontals (WG). Both SIGs and WGs are important at this stage in DLT and HLs evolution. Having been involved in both types as a chair; I can assure Hart that SIGs are no easier to launch and run. Opening up some of the administrative tasks (like changing the calendar) should ease the pressure on the HL staff. The SIGs, since they launched after WGs have figured out the need for vice-chairs and volunteers for recording and minuting meetings and are asking for this, let us spread this practice to the WGs.
    2. Project participation: This is not a zero sum game, SIGs and WGs attract new participants. That is what I remember from Hart's Academic SIG discussion.
      However, we (SIG and WG participants) need to enhance our outreach and marketing efforts to projects to demonstrate our usefulness to the projects with concrete examples, there are also use cases (the Requirements WG rises again) that SIGs can provide, especially challenges, obstacles, regulations, standards in the respective business areas that projects would benefit from, so that they can think of solutions. All these ways of systems thinking and the removal of "narrow framing" would help bring the projects into deployable production systems in the Enterprise.
      To this end let us work on some blogs: general as well as specific. SIGs as part of the launch process, are required to write a blog. Let us do the same for existing working groups. This should be a mix of technical and behavioral/soft pitches for the working groups. I am already doing one for CMSIG, will try to get one going for IDWG and I volunteer to help with Architecture and PSWG blogs as well as the general one.
    3. Review the concept of a "standing conference"; this could escape the bounds of a bi-weekly call as collaboration could be achieved through wiki (much like here on this task force), emails, chats etc. Add to this intelligent (and sparse) tagging for improving the discoverability of material and suggested roadmaps for readings on the WG /SIG curated materials.
  3. Brian wrote: " It's clear this cross-project collaboration doesn't happen spontaneously; and even when good ideas are shared at a face-to-face, it needs a home for ongoing conversation and planning."

    I'll have to disagree with that. We have at least three concrete cases where this has occurred: Seth, Fabric EVM chaincode and Transact. I've also had discussions with Shawn and Kelly, and frankly the Raft consensus could also have been handled this way had we connected at the right time. Now, this does point to what you were advocating, that projects be paying some attention to one another, and sharing more broadly when they are embarking on new initiatives, as it gives the community a chance to think about, and act accordingly, possible areas of collaboration.

    Giving a WG teeth is not the approach we should be pursuing. Giving the TSC teeth to force the projects to collaborate isn't the approach we should be pursuing, either.

    IMO, a "Working Group" should be about <checks notes> working. If people want to have a gabfest, then maybe a SIG is indeed the right forum. Frankly, maybe we need to move away from long-running WGs and Task Forces (unless the Task Force is intended as a short term initiative) and be operating more as a collection of loosely aligned (initially) projects where we take advantage of opportunities to actively collaborate across projects and become more highly aligned as those opportunities present themselves, and as resources are available to drive them to fruition.

    1. Thanks for your comments!

      What I've found over the past few years is that it's unbelievably hard to get people to do working group work, and that focusing on it causes people to leave the working group.  I have also found that gabfests actually do serve a purpose:  they encourage people from different projects to talk about their ideas and collaborate.  I don't think Ursa would have been possible without many of these gabfests.  I think I am not the only one that has gotten much more out of the gabbing at the working groups than the work products.  How many people have actually read the architecture WG papers?

      What I'm proposing seems very similar to what you have in mind, even if we have different nomenclature in mind:  first, turn the working groups into SIG-like things that don't have required work products (we can call them whatever you want).  For things that require work outputs, we can create short-term task forces.

      Am I making sense here?

      1. I'm worried that unstructured gab-fests would not be particularly helpful. I do like the idea that we get people together who care about a problem, evaluate technical options & co-design a solution (that may enter into the project lifecycle as a lab or something else). Just thinking about the AWG... the discussions that I want to continue are more on the lines of building some sample usages that demonstrate the privacy/confidentiality capabilities & limitations of platforms (e.g. samples that are built for each platform) and maybe some tools to help with the evaluation. That is... code products rather than paper products. I think some of the discussions about protocols & requirements for interoperability have been helpful as well... but i'm more interested in figuring out how to prototype the requirements than in writing a specification paper. 

        Another observation is that our working groups are scoped at a very high level. Instead of an architecture working group, we should be talking about groups like "provable externalized data" working group (which is part of what we say we need for interoperability). Many of the current groups are scoped around "areas of interest" rather than specific problems to be solved. And maybe the specific problems focus is more "task force"... but does it really matter?

        1. I don't think anyone is suggesting unstructured gabfests, and I agree with you that we should scope our working groups more finely.  This seems to be a pretty unanimous point–I don't want to put words in Chris's mouth, but it seems like he agrees with this idea.

          I worry that asking working groups to produce code will be even more difficult than getting them to produce papers.  Do you know of any current examples where working groups have produced code?  Perhaps I'm being pessimistic, but it seems like this will make it even less likely that medium or large groups of people work together on common things.  We would need strong commitments from projects to pull something like this off, which we currently do not have.

          1. I'm not suggesting that we require code as a work product. I am suggesting that I personally would be far more motivated to participate in a working group who's output was something usable rather than the papers we are producing right now. I can see how well scoped working groups could (as one possible result), create useful artifacts (like code) that would make existing projects better or lead to new projects.

            1. This makes total sense.  But how could we ensure that the code we produced was useful?  I'd be worried that it would just get ignored like the papers.

              By the way, can we separate the "work product" discussion from the "finer scope for WGs"?  I think these are two different discussions, and the latter most people seem to agree with.  

              1. Just added two subpages with proposals for 1) limiting the scope of working groups and 2) removing the need for work products. Hack away on the wording.

                And... i'm not suggesting we specify anything as a required work product. Just suggesting that one  outcome of a working group might be "useful code" that could be pushed through the project lifecycle and become a lab project or a real project or a subproject.

                I'm perfectly happy with a working group where there are no products other than high quality information exchange. Though that starts to feel like a SIG.

                1. Thanks!  I think we're pretty much in agreement.

              2. Hart, I'm not sure we need to ensure that the code produced is useful. In fact, I would fully expect that some percentage fail in their endeavor, not through lack of trying (though some may suffer that fate) but because attempting to put the idea into practice was impractical. In the end, we learned something. In those cases where something useful IS produced, kudos!

                1. Yep, this makes sense.

                  We just need to make sure that when working groups produce things like code, it has a chance at "being successful" or being used in some way by the projects.  No one likes spending the time to produce good code that then doesn't get used.  This would seem to require closer connections between the projects and the working groups than we currently have. 

        2. Mic, I agree with your characterization. I too would prefer to see code rather than prose. Samples are one such outcome, another could be effectively a prototyping of a new capability, or a refactor, and collaboration around that specific task. Call them what you like, but as Mic suggests, these should be narrowly scoped.

          I don't have an issue with gabfests, per se. However, as with my day job, those that do land on my calendar are the first to be ignored for more pressing matters unless they are REALLY compelling. That would mean publishing an agenda well enough in advance that I could rearrange my schedule.

          1. I believe we already require that working groups publish an agenda in advance, so I think that's not an issue.  I don't think anyone disagrees with the fact that code is the best output of working groups, either–it's just the hardest to achieve!

            And yes, that's the beauty of gabfests:  show up when someone interesting is talking, and don't when that's not the case.  As long as the organizer does a good job, then there will always be critical mass needed for discussion.

            I think we are all in agreement on the narrow scoping, though–this is something we can take to the TSC.

  4. Linking this email thread for posterity as there is much of the discussion about the role of WGs inlined.

  5. As a member of both Working Groups and Special Interest Group's I have to agree that the effectiveness of these groups depends on cross collaboration.  The success depends on support and information we receive from the Hyperledger community , SIG's and other Working Groups. Participation and continuity seem to be issues haunting all volunteer groups ( not a Hyperledger issue).

    The SIG participation remains high because the quality presentations during the calls. Each call is a learning experience and if you miss a call, no need to catch up. When the SIG's decide on a work product , they form sub groups and meet on additional calls to accomplish a goal. The Working Groups on the other hand are producing output for each call.  This can be a challenge when so few people attend consistently.  Most folks haven't interacted with Wiki pages and need to pick up that skill prior to creating work product.  So what do Working Groups do? The LMDWG spends a portion of our weekly call dedicated to recruitment ideas.

    As the chair of the LMDWG, the time commitment is extensive. The role of the working group is to SUPPORT the learning needs of the community.  Members of WG's  willing participate out of desire to be a part of something great.  We believe in the Hyperledger solutions.  Member turn over occurs when the commitment out weighs the rewards.  The answer lies in creating work product of value, something member can be proud of.

    So back to the question "What is the role of the Working Groups and Special Interest Groups"?  The WG and SIGs are only as effective as the support and guidance we receive from Hyperledger / Linux Foundation.  For example, when a forum is coming up a call goes out for submission, a new energy is infused into the conversation. The need for a dedicated Hyperledger resource for these groups to turn to, to consistently mange the efforts, would give the WG and SIG the ability to focus on creating meaningful work product.

    The opportunity exists for a WG and SIG community manager, whose role is to create an environment that fosters cross collaboration, where participant can focus more on what they want to produce and less on how.  This is a unique moment where we can create a strong and effective volunteer Hyperledger community by fostering  an environment where creative mind can collaborate.

    Bobbi Muscara

    Chair Learning Materials Development Working Group

  6. Proposal 3-8

    Aren't these just two proposals

    1. Working Groups should be dropped and existing WGs will be converted to technology focused SIGs.
    2. Task forces are a new structure under the TSC, limited in scope, with a firm deliverable, a deadline and a leader. They will report progress (or lack of it) to the TSC.

    That is how I read it...

    1. That's a correct interpretation, yes.

      You could lump proposals 3 and 8 together, and 4, 5, 6, and 7 together as well if you want, which is what I believe you are suggesting.

      1. Yes indeed Hart. Just trying to reduce our collective cognitive burden. 

        1. it doesn't hurt to keep them separate for the moment. but i don't see any need to vote on them separately unless there are concerns.

  7. Bobbi Muscara's comments this morning kind of reinforced for me that having a task force with targeted deliverables makes the most sense going forward. She highlighted some specific tasks (eg. develop a community survey, create a resource to help people find docs and samples etc, create a template for discoverability that can be shared across projects). I could see that as three separate task forces, each developing proposals to bring before the TSC for approval and then have the projects execute.

    1. So instead of having 7 WGs you will have 21 task forces to track with no cohesion

      1. i think the point is that with short lived task forces you won't have that many in flight at any time.

        1. You will be surprised at how many task forces can be spun up. I agree that "develop a community survey" maybe a task with a limited timeline, but "create a resource to help people find docs and samples", "create a template for discoverability" maybe more long running and may need constant iteration. Even a survey may need to be done multiple times (once a year for example); my contention is these tasks require more cohesion than initial analysis may reveal. Working Groups could house these open ended task forces with periodic outputs, that keep getting refined. There are no other fora for creating an open-ended vision across DLTs. The TSC does not have the bandwidth to address so many different initiatives; but should be able to intervene in a crisis. A periodic report with links to these activities (Mic Bowmanhas already proposed this as half-yearly reports) will keep the TSC in the loop with the option of digging further into the outputs of these WG→task forces which should be available in the wiki which evolves in value as a technical resource with the passage of time. 

  8. Difference between WGs and SIGs is deliverables and governance.

    Some WGs are tailing off because their original deliverables were met or the world has shifted.

    Rechartering all of the original WGs would help reset onto deliverables that felt addressable and meaningful. This process would follow the existing proposal practice where the community and a chair define that charter and propose it to the TSC.