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:

https://wiki.hyperledger.org/display/TF/Working+Group+Task+Force 

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

Hi Todd,

First, let me express congratulations to the newly elected TSC, particularly the new members who will bring fresh energy and perspectives to our conversations.  You are the heart of the technical credibility of this project, and I could not be happier to see it in such good hands.  (apologies for the delay, I've been traveling)

Todd: thank you for expression of concerns that no doubt are latent on other people's minds.  I am sure they are also on the minds of each of the TSC members, too.

We have been very careful at Hyperledger to separate out the sponsoring-member-consortium layer from the developer-driven product and technical layer.  The former is intended to run very much like any ordinary consortium would; the latter, like any well functioning open source project.  I may be projecting from my experience with Apache, and perhaps over-assuming that the following is obvious, but I always felt it's been clear that developers are expected to participate and contribute as individuals first, and as employees second.  For example:

* If a maintainer on a project, or a member of the TSC, changes employers, they do not lose their status; their "seat" is not conferred to someone else from the same employer, they keep it wherever they go. 

* If a developer is asked by their employer to submit code that the developer does not believe is the right thing to do, the developer should not submit that code.  In no case is "we were asked to do it this way" acceptable as a rationale for submitting or accepting a pull request or other technical decision, and they can ask us (HL staff) to delicately intervene if necessary.

* While we (Hyperledger staff) encourage companies to commit their developers to projects, and argue that they'll realize benefit from doing so, we constantly warn them that the public processes must rule the day; that project proposals, pull requests, even discussions will go whatever way the developer community decides it should, no matter how unfair or subject that may feel.  We also make it clear that a company's sponsoring membership in Hyperledger has no bearing on their technical contributions; and that conversely, non-member companies can realize the full benefit of using and contributing to Hyperledger projects.  We have several companies who contribute major amounts of code, and it's running code that usually dictates what happens (the do-ocracy).  Of course this swings both ways - it would be inappropriate for us to change the TSC election outcome because it didn't look the way we think it should.

Obviously, developers may feel pressure from their employers, and some will be able to push back but others won't feel so empowered.  The market for talent in this space is so hot, and the profile accrued to TSC members and project maintainers so high, that job security is likely not the overwhelming issue.  Others will act out of loyalty to their employers.  However, this community is capable of watching for, and calling out, behavior they feel might cross that line.  And we as HL staff have given feedback privately when we've seen that too.

By any metric, to date, IBM's technical contributions to Hyperledger have been substantial, and more than any other company.  They deserve credit for that.  Early on, that contribution level was so high that it led to public perception issues of "control", and a sense that technical decisions were being made on white boards and phone calls offline rather than online.  I won't speak for them, but it was made clear to us that IBM did not want that outcome - they brought Fabric to Hyperledger to get developer leverage, so that their headcount would be complemented by the efforts of many others.  And, they knew it was essential that Fabric not be a single-vendor product, but an industry movement.  So we worked with them on both the technical process issues, and the public perception issues, and I believe these are in the past.  They no longer are more than half the contributions into Fabric, as per Chris Ferris's numbers.  There are many other projects beyond Fabric in Hyperledger, and IBM has supported those, boosting Indy and Sawtooth and now even welcoming Besu.  Perhaps this is one reason the other electors felt comfortable voting for the IBM-employed candidates.

Now that every major public cloud provider offers a managed Fabric as a service, and those companies are now getting commercial traction, we expect those other companies to increase their investments into Fabric, entirely out of self-interest.  That will, no doubt, also increase the representation from those companies in the maintainer community in Fabric, into other Hyperledger projects, and in the next TSC election.

But all that said, there was talk about increasing the size of the TSC, to increase the prospect that more projects at Hyperledger will see one of their maintainers onboard, and to account for the growing developer community.  I think that would address both the perception of an issue here, and any actual attempt by a single vendor to exert "control" over their employees who become TSC members.  The new TSC can discuss this.  They could decide to ask the Governing Board to adjust the Hyperledger bylaws to increase the size of the TSC for the next election.  They could also ask the Governing Board to approve a one-time add of a set of new TSC members, so that this greater representation can happen in the current TSC term.  I think there are a lot of great reasons for either approach.

Again, I'm excited by the new TSC.  There's a lot of new hard work to do together!

Hope this helps,

Brian

On 9/6/19 3:04 PM, Todd Little wrote:

Hi TSC and Hyperledger in general,

While I don't doubt the results of the election, I do have to question whether this is the sort of outcome Hyperledger desires.  For projects to exit incubation they must exhibit diversity of contributions such that a project is not "controlled" by a single organization.  Why would the TSC find that TSC membership adheres to a lesser standard?  It is very clear that IBM now controls the TSC and is that the direction Hyperledger wants to take?

-tl

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf