Frankly, it feels like we could move the discussion/information only meetings to a SIG (Hart Montgomery is there a reason why the "gabfest" part of the discussion about working groups couldn't just be subsumed by the SIGs?) and then move the more focused/scoped work to a limited-time task force.
What is the definition of "work"? This is a question that we must answer. Discussion (dismissed as gabfest), thought, architecture reviews etc. qualify as work too. Also best practices from working projects can help others working on the same or similar problems. In Hyperledger the forum for this are the working groups and SIGs.
Coding without reflection and input from multiple sources is the source of much broken and sub-par software challenged with usability issues. Aspects like performance, enterprise legacy integration etc. are discussed best in Working Groups, unless you want an echo-chamber.
There is no design by committee, however choices made in code and accompanying documentation (either as comments or separate docs) should highlight limitations or justifications for choices that were made. This can also be a source of a features road-map. These challenges and questions can arise in Working Groups and projects would benefit from a periodic presentation to a Working Group (of the specifics pertaining to the working group-like Identity, Architecture, PSWG) inviting challenges and putting open issues before them. Almost like a quarterly scrum.
Examples of "aha" moments on some of the IDWG calls include practitioners realizing that storing PII on the chain is deprecated; and looking at the various ways around this. Listening to other practitioners talking about solutions to this.
In PSWG for example, we have had presentations on FastFabric, Accelerator project (by SDS), a project on validator speedup using db caches etc. The beauty of this forum was that sometimes each solution creator was unaware of the other, the questions that we discussed included whether these could be put together to increase the transaction rate (synergies), to make the parameters of the configuration (for the accelerator) adaptable (i.e. inject AI on top of Blockchain). All examples of real "work" that the practitioners found useful.
In Architecture WG we had a presentation on Transact. This was just a one-off to spread the word before the vote on the TSC cameup.
The TSC is busy, even to routinely do the project reviews under their purview. Most of the time, the individual reviews done by TSC members seem to be just a tick the box exercise. This is not due to any fault of the TSC, but a lack of time and expertise in these matters. The Working Groups could take on some of this work, to delve deep into specific technical aspects and provide feedback which then could be taken back to the TSC in a succinct form. There can even be a small number of projects (2 or 3) under individual TSC members who could drive the deeper reviews of the projects in association with the Working groups.
That there is significant amount of voluntary participation in these open source projects seems to be a myth, since most of the people are participating as part of their "day jobs" and are directed by the Enterprises (i.e. the managers) that they work for.
In the Identity space, we have an Implementers section where practitioners from various groups (Aries, Indy, Ursa, the W3C groups) gather; we then have short reports on efforts disseminated through the Identity WG. Hence the term a standing conference or a remote conference where you gather to hear about the latest developments under Identity both in and out of Hyperledger.
There was a suggestion (by Arnaud I think) to compare and contrast the various platforms under Hyperledger. The architecture papers started this under consensus, smart contracts etc. This work on differentiation and fit for purpose and ROI naturally is done in a forum like a Working Group.
There was another suggestion by Shawn that we should work toward an API for pluggable consensus. This could be undertaken by a sub-group under the Architecture WG (for example).
From these examples and suggestions we see that Working Groups provide value and could provide more with a reboot and a repositioning.
IMO, a "work product" could be a well-defined JIRA epic and subordinate stories following spike development by a small group of a prototype. It could be a sample application attempting to leverage some new capability to demonstrate (lack of) usability etc.
Having the ability to share presentations etc should not need a WG, IMO. We had a presentation of the FastFabric work in the Fabric Contributors call (the preso to the PSWG was weeks later IIRC). Frankly, we could also accommodate such presentations ad hoc, or there could be a standing zoom slot on the hyperledger calendar for such.
But the other aspects you described are happening now - in or amongst the projects, and are more suited to a task force as we have been discussing. When the FastFabric paper was published, the Fabric maintainers reached out to the authors. We scheduled time for them to present on one of the Contributors calls and we have had contact (albeit there was a snafu as noted by Hart). I don't know that a WG was needed for this. There have in fact been many papers published and quite often there is outreach.
I think that a SIG for a domain is fine, but we shouldn't expect any work products be produced, because as Hart says, that seems to be a disincentive to participating. A narrowly scoped TF for when there's a specific issue to be worked out, and some specific outcome/output for when there is a desire and willingness to roll up sleeves and get something done.
For the rest, we could even consider periodic virtual conference days sprinkled through the year to augment the Maintainers Summit and Global Forum.
9 Comments
Christopher Ferris
This feels more like a SIG.
Mic Bowman
Or... gabfest.
Frankly, it feels like we could move the discussion/information only meetings to a SIG (Hart Montgomery is there a reason why the "gabfest" part of the discussion about working groups couldn't just be subsumed by the SIGs?) and then move the more focused/scoped work to a limited-time task force.
Hart Montgomery
Mic, this is exactly what I'm proposing.
Christopher Ferris
Right... the thing with a SIG is it is not tied to the TSC. I think that we need to revisit that.
Hart Montgomery
Yep. It makes no sense to have technically-focused SIGs not be under the purview of the TSC.
Vipin Bharathan
What is the definition of "work"? This is a question that we must answer. Discussion (dismissed as gabfest), thought, architecture reviews etc. qualify as work too. Also best practices from working projects can help others working on the same or similar problems. In Hyperledger the forum for this are the working groups and SIGs.
Coding without reflection and input from multiple sources is the source of much broken and sub-par software challenged with usability issues. Aspects like performance, enterprise legacy integration etc. are discussed best in Working Groups, unless you want an echo-chamber.
There is no design by committee, however choices made in code and accompanying documentation (either as comments or separate docs) should highlight limitations or justifications for choices that were made. This can also be a source of a features road-map. These challenges and questions can arise in Working Groups and projects would benefit from a periodic presentation to a Working Group (of the specifics pertaining to the working group-like Identity, Architecture, PSWG) inviting challenges and putting open issues before them. Almost like a quarterly scrum.
Examples of "aha" moments on some of the IDWG calls include practitioners realizing that storing PII on the chain is deprecated; and looking at the various ways around this. Listening to other practitioners talking about solutions to this.
In PSWG for example, we have had presentations on FastFabric, Accelerator project (by SDS), a project on validator speedup using db caches etc. The beauty of this forum was that sometimes each solution creator was unaware of the other, the questions that we discussed included whether these could be put together to increase the transaction rate (synergies), to make the parameters of the configuration (for the accelerator) adaptable (i.e. inject AI on top of Blockchain). All examples of real "work" that the practitioners found useful.
In Architecture WG we had a presentation on Transact. This was just a one-off to spread the word before the vote on the TSC cameup.
The TSC is busy, even to routinely do the project reviews under their purview. Most of the time, the individual reviews done by TSC members seem to be just a tick the box exercise. This is not due to any fault of the TSC, but a lack of time and expertise in these matters. The Working Groups could take on some of this work, to delve deep into specific technical aspects and provide feedback which then could be taken back to the TSC in a succinct form. There can even be a small number of projects (2 or 3) under individual TSC members who could drive the deeper reviews of the projects in association with the Working groups.
That there is significant amount of voluntary participation in these open source projects seems to be a myth, since most of the people are participating as part of their "day jobs" and are directed by the Enterprises (i.e. the managers) that they work for.
In the Identity space, we have an Implementers section where practitioners from various groups (Aries, Indy, Ursa, the W3C groups) gather; we then have short reports on efforts disseminated through the Identity WG. Hence the term a standing conference or a remote conference where you gather to hear about the latest developments under Identity both in and out of Hyperledger.
There was a suggestion (by Arnaud I think) to compare and contrast the various platforms under Hyperledger. The architecture papers started this under consensus, smart contracts etc. This work on differentiation and fit for purpose and ROI naturally is done in a forum like a Working Group.
There was another suggestion by Shawn that we should work toward an API for pluggable consensus. This could be undertaken by a sub-group under the Architecture WG (for example).
From these examples and suggestions we see that Working Groups provide value and could provide more with a reboot and a repositioning.
Christopher Ferris
Vipin,
IMO, a "work product" could be a well-defined JIRA epic and subordinate stories following spike development by a small group of a prototype. It could be a sample application attempting to leverage some new capability to demonstrate (lack of) usability etc.
Having the ability to share presentations etc should not need a WG, IMO. We had a presentation of the FastFabric work in the Fabric Contributors call (the preso to the PSWG was weeks later IIRC). Frankly, we could also accommodate such presentations ad hoc, or there could be a standing zoom slot on the hyperledger calendar for such.
Vipin Bharathan
If what you got from my comment is "share presentations"; I have failed in my communication
Christopher Ferris
But the other aspects you described are happening now - in or amongst the projects, and are more suited to a task force as we have been discussing. When the FastFabric paper was published, the Fabric maintainers reached out to the authors. We scheduled time for them to present on one of the Contributors calls and we have had contact (albeit there was a snafu as noted by Hart). I don't know that a WG was needed for this. There have in fact been many papers published and quite often there is outreach.
I think that a SIG for a domain is fine, but we shouldn't expect any work products be produced, because as Hart says, that seems to be a disincentive to participating. A narrowly scoped TF for when there's a specific issue to be worked out, and some specific outcome/output for when there is a desire and willingness to roll up sleeves and get something done.
For the rest, we could even consider periodic virtual conference days sprinkled through the year to augment the Maintainers Summit and Global Forum.