Kulkarni, Amol <amol.kulkarni@...>
toggle quoted messageShow quoted text
One of the issues with the WGs as they’re currently set up is that interested folks from Asia cannot call into them.
The PSWG, for example, currently meets from 6:30 – 7:30 pm India time. While I’m working on performance and benchmarking specifically, my colleagues and I cannot
call into any of these meetings. Perhaps rescheduling meetings to encourage participants from different geos might be one way to increase participation in WGs.
From: tsc@... [mailto:tsc@...]
On Behalf Of Silona Bonewald
Sent: Tuesday, March 19, 2019 7:49 AM
To: Christopher Ferris <chris.ferris@...>
Cc: Todd Little <todd.little@...>; Montgomery, Hart <hmontgomery@...>; mark wagner <mwagner@...>; perf-and-scale-wg@...; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger Performance and Scale WG] [Hyperledger TSC] some thoughts on the future of the PSWG
The Technical Working Group China participated in the HKBootcamp and was highly visible. I think it is a good idea for other working groups to think about how to recruit and engage more with the community thru events like Bootcamps etc.
For example, my team has been discussing with the Learning Materials Working Group about how they will recruit. First from the projects themselves, and then how do we help them market themselves to get more volunteers? Of course, having
a good landing page on the wiki helps!
Also, Hyperledger has been starting up a bunch of SIGs. I believe some people are moving to those SIGs. And Ecosystem team is actively recruiting new members to participate there first. Should we look at how we cross "advertise" internally?
Or look at how we "advertise" to new members and externally.
What other paths to recruitment should we explore?
Todd, the Fabric maintainers would welcome additional help in documenting Fabric or providing and curating samples. They don’t write themselves.
I tend to agree with Hart’s analysis, and while I have a regular call that conflicts, I join occasionally and am definitely interested in the subject matter.
I’d agree with Todd that working with a traditional benchmarking org would be good, as would input into Caliper and other performance testing efforts.
We aren’t yet at a point where we can effectively provide guidance on comparative performance characteristics, which is ultimately what people will be seeking.
I tend to agree, but I also think another factor is that as we've moved from initial versions of the various platforms to production ready platforms, people are probably getting tied up working on those production deployments. I know for me it's mostly a matter
of I participate when I don't have conflicts or not traveling.
Personally I'd like to see us move in the direction of helping some standards organizations define blockchain benchmarks that can be used to evaluate blockchain platforms, as I'm not sure we're in the business of setting those kinds of standards. Someone please
correct me if I'm wrong. I may have asked this before, but has anyone reached out to TPC to see if they're interested in creating some blockchain benchmarks?
With respect to the documentation, agreed it's fairly weak, and in particular design documentation is sorely lacking, at least for Fabric. I can't speak to the other platforms. Samples/examples is another area that is pretty weak. Our platforms are so feature
rich that it's hard to pick them up without a set of rich samples/examples.
PS FWIW I'll be on the call tomorrow.
On 3/18/2019 5:28 PM, Montgomery, Hart wrote:
I think this is probably true for most working groups. At least from what I’ve seen and heard (and
to be fair, this is not a huge sample size), fewer people are participating in the working groups, and those who are generally are participating less.
I’m not sure this is a bad thing, in many cases. I think some people have replaced spending time on
working groups with time spent on regular projects. Personally, I’ve spent less time on working group stuff since Ursa has begun (and, obviously, more time on Ursa), which is probably a kind of progression we want to encourage in Hyperledger. Having people
that come into the working groups looking to learn become regular contributors surely is a positive thing.
On the other hand, as the working groups seem to focus more and more on work products—which is typically
documentation--fewer people seem to be interested since there is often substantial outside work involved, and not necessarily of the fun kind. In particular, I think every SWOT analysis we have done on Hyperledger involves documentation being listed as a
weakness. While documentation has gotten better, it’s still something that I think most people would agree needs a lot of work on most aspects of Hyperledger.
So, for a TL;DR: from my viewpoint, people are leaving working groups to contribute (great!) or avoid
documentation work (not so great).
Do these experiences jibe with yours (or others’)?
Sorry for another long email.
On Behalf Of mark wagner
Sent: Monday, March 18, 2019 12:33 PM
Cc: Hyperledger List
Subject: [Hyperledger TSC] some thoughts on the future of the PSWG
I would like to carry this discussion mostly in the mailing lists in order to be as inclusive as possible.
Over the last few months attendance and participation on the Performance and Scale WG (PSWG) calls has been declining. I am wondering if we need to shift focus a bit to get more
people involved and make progress.
There are many possible directions we can head in and I have included some thoughts here, but if others have additional ideas please feel encouraged to add them.
First is stay the course. We are currently struggling to get our thoughts on describing metrics for provenance captured to paper.
Do we want to focus more on actual performance work vs just defining metrics / use case papers. This does not need to be "just running tests".
We can do things like examine trade offs between different design decisions, examine different crypto solutions / technologies from a perf and scale perspective, help understand
cost performance tradeoffs.
Perhaps we help spin up testnets and drive testing of different DLT frameworks ?
Do we provide a performance analysis service to the different projects that is based on architecture decisions. Perhaps something similar to what several research students have
done (Harish and his team, FastFabric, etc).
I am trying to cut a wide swath here to avoid limiting peoples thoughts, so any and all comments are encouraged. If you have not been involved in the PSWG and would be interested
in participating if we did "X" then speak up!
Chair, Performance and Scale Working Group