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.

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. 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.

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.

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

https://lists.hyperledger.org/g/tsc/message/2606

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

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...

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.

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.