Date   

Defining Performance metrics for Provenance

mark wagner <mwagner@...>
 


Hi

The Performance and Scale Working Group (PSWG) is looking to define performance metrics for supply chain provenance. Vipin has written up a quick overview for us to start the work.


We are hoping to collaborate with other groups and projects looking at supply chain and smart contracts in order to ensure that we get things right. So my ask is that folks from the different HL groups can aid us in our efforts. The payoff is that at the end of this process there will be something that can be used to benchmark Provenance use cases.

Thanks

-mark
--
Mark Wagner
Chair - Performance and Scale Working Group
Hyperledger


Re: Hyperledger taxonomy and revised greenhouse graphic for review

Shawn Amundson
 

Potential members, end-users, and developers are all going to be very different audiences. For the moment, it is probably pretty critical to keep planting more library projects and not make them invisible before they get longer roots. Maybe at the garden shows you don't necessarily show off the fertilizer unless your business is selling fertilizer to the gardeners. Maybe you cut off the stem and just hope the roots survive.

On Wed, Jun 12, 2019 at 12:41 PM Dave Cecchi <david_cecchi@...> wrote:
I won't speak for others, but I wasn't advocating for explicitly showing dependencies.  Moreso just that it's a logical stack in some senses.  

My point is just like "Functional Capability" driven frameworks (Aries, Grid, Indy) sit on top of "Ledger Implementations", which in turn use "Common Libraries".  "Developer Tools" can be used to build/test other "Functional Capabilities".  Maybe Quilt sits above it all??)  Even if this stuff doesn't [yet] interoperate very well, a coherent visual / mental model on "how it all maybe kinda could" or even just "this thing is lower level than these other things" seems worthy of consideration.  

Also - and I get I probably don't understand the audience this is really intending to reach/educate/inform - but NASCAR'ing up the greenhouse feels like it runs the risk of overwhelming the casual Enterprise info-seeker.  I'm a huge fan of Transact, but at some point it may make sense not to include low level library components on primary diagrams?

Still at 2-cents.

-dc


Re: Proposal for TSC RFCs?

Shawn Amundson
 

On Tue, Jun 11, 2019 at 11:47 PM Brian Behlendorf <bbehlendorf@...> wrote:
...
Requiring a formal proposal template for all topics for TSC conversations, or those that would result in decisions, feels a bit process-heavy, as often small suggestions during a conversation become decisions made.  But for the larger concepts, such as new graphical takes on the greenhouse, I've been encouraging people to make these suggestions in longer form ahead of time, giving TSC members a chance to read & consider before discussing on the calls.  I'm also completely happy (as anyone who knows my antipathy for calls knows) to see issues opened, discussed, and decided completely outside of the calls.  Getting people to at least use the mailing list and Wiki for these proposals rather than Google Docs would be an improvement; seeing a page in the TSC space of outstanding issues (much like the "backlog" queue maintained in the current agenda) would as well.  But the calls are at least a place where the TSC can reach and formally record a consensus on an issue, even if that only takes 5 minutes to reflect the consensus arrived at over an email conversation.  So the minutes to those meetings should still be the canonical source of what was decided, even if the why and rationales are a bit more spread out.


I don't think a fairly light-weight process like the Rust RFC model is too much to ask for proposals that impact the projects, and in particular policies. It does set the bar substantially higher than it is currently, but that's kind of the point -- the bar is so low now that what we have are seemingly random wiki pages which don't make any effort to describe the "why" behind their content (and most, as far as I can tell, are not TSC approved).

Take for example project proposals. The project proposals are vastly better than most other content presented to the TSC. This is because there is a fairly great template for it and the teams take it seriously and spend a lot of effort and time trying to explain themselves. We should expand this to other decisions as well.

The TSC could determine when the RFC process needs to be used or not - I think what we would want to do in the task force is provide some guidance on it but ultimately leave it to individual TSC decisions.
 
While using Git to manage RFCs makes sense for code-level decisions, using Git/Github for TSC proposals and discussions feels like it might exclude quite a few people.  Needing to do a git clone to change text is a fair uplift from going to a wiki page and clicking edit - totally justified when you're all maintainers and already have git copies of your core projects' repos locally, but harder outside that context.  In both systems you get visibility into who's changed what.  In a wiki you get search for free (yes, one could grep locally...).  In either scenario you need gardeners, which feels like the most precious resource we have. 

This should certainly be part of what the task force answers. The collaborative peer review process is important, as is the ability to track changes and capture feedback. I think the best approach is to talk to a wide number of maintainers and other collaborators and get a feel for what is the most likely process to get us higher quality RFCs. Ideally the new process would enable more maintainer input than we have today.

-Shawn


Re: Hyperledger taxonomy and revised greenhouse graphic for review

Dave Cecchi
 

I won't speak for others, but I wasn't advocating for explicitly showing dependencies.  Moreso just that it's a logical stack in some senses.  

My point is just like "Functional Capability" driven frameworks (Aries, Grid, Indy) sit on top of "Ledger Implementations", which in turn use "Common Libraries".  "Developer Tools" can be used to build/test other "Functional Capabilities".  Maybe Quilt sits above it all??)  Even if this stuff doesn't [yet] interoperate very well, a coherent visual / mental model on "how it all maybe kinda could" or even just "this thing is lower level than these other things" seems worthy of consideration.  

Also - and I get I probably don't understand the audience this is really intending to reach/educate/inform - but NASCAR'ing up the greenhouse feels like it runs the risk of overwhelming the casual Enterprise info-seeker.  I'm a huge fan of Transact, but at some point it may make sense not to include low level library components on primary diagrams?

Still at 2-cents.

-dc


Re: Hyperledger taxonomy and revised greenhouse graphic for review

Brian Behlendorf
 

Based on a bunch of conversations, we intentionally avoided structuring this like an architecture diagram, or drawing dependencies between projects.  We have no global architecture across all projects (yet); there are a lot of ways that incorrect assumptions could be arrived at if the graphic were attempting to infer architecture; it could inadvertently conceptually lock in things that are intended to be temporary situations, such as Grid only running on Sawtooth; and drawing lines to make such things more accurate could make it very busy.

One thing we looked at was the Cloud Native Trail Map:


It's obviously very different, and larger than what could easily be fit into a single slide or top fold of a web site (perhaps we ditch those requirements), and more "wordy", but by being more wordy it acts as a really good guide to someone diving into the full CNCF community. 

Separately a map of dependencies and the like across all HL projects could be very interesting as a separate exercise.  It would have to be something the projects and TSC, or one of its WG's, perhaps architecture, committed to keeping up to date. 

Brian

On 6/12/19 8:58 AM, hmontgomery@... wrote:

Personally, I would love to see a graph-like structure with edges between layers indicating compatibilities or dependencies.  But then again, I’m not a marketing expert.  Can anyone from the marketing committee comment on some of the ideas here?  Would that be too “busy?”

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Middleton, Dan
Sent: Wednesday, June 12, 2019 7:05 AM
To: Dave Cecchi <david_cecchi@...>; tsc@...
Subject: Re: [Hyperledger TSC] Hyperledger taxonomy and revised greenhouse graphic for review

 

I had a similar reaction. Frameworks are the underlying fabric ;)  responsible for data replication policies.

Thinking about future projects what would this look like if we got a consensus library project?

What other forward looking considerations come to mind?

 

Ok, now we’re up to nearly a nickel.

 

--dan

 

From: <tsc@...> on behalf of Dave Cecchi <david_cecchi@...>
Date: Wednesday, June 12, 2019 at 8:17 AM
To: "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] Hyperledger taxonomy and revised greenhouse graphic for review

 

My two cents is only that - especially with Transact starting to drive more "unification" - it may be worth reconsidering the visual to be more representative of the "stack".  This is really a catalog, but even a mildly technical audience wants to know "how do these things work together (if at all)".  With blockchain platforms / frameworks at the top and everything else smallboxed as siblings underneath, the mental model the picture presents doesn't necessarily drive to solutions/capabilities.  Maybe that's deliberate, though?  Again, just my 2 cents.

-dc


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


Re: Hyperledger taxonomy and revised greenhouse graphic for review

hmontgomery@us.fujitsu.com <hmontgomery@...>
 

Personally, I would love to see a graph-like structure with edges between layers indicating compatibilities or dependencies.  But then again, I’m not a marketing expert.  Can anyone from the marketing committee comment on some of the ideas here?  Would that be too “busy?”

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Middleton, Dan
Sent: Wednesday, June 12, 2019 7:05 AM
To: Dave Cecchi <david_cecchi@...>; tsc@...
Subject: Re: [Hyperledger TSC] Hyperledger taxonomy and revised greenhouse graphic for review

 

I had a similar reaction. Frameworks are the underlying fabric ;)  responsible for data replication policies.

Thinking about future projects what would this look like if we got a consensus library project?

What other forward looking considerations come to mind?

 

Ok, now we’re up to nearly a nickel.

 

--dan

 

From: <tsc@...> on behalf of Dave Cecchi <david_cecchi@...>
Date: Wednesday, June 12, 2019 at 8:17 AM
To: "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] Hyperledger taxonomy and revised greenhouse graphic for review

 

My two cents is only that - especially with Transact starting to drive more "unification" - it may be worth reconsidering the visual to be more representative of the "stack".  This is really a catalog, but even a mildly technical audience wants to know "how do these things work together (if at all)".  With blockchain platforms / frameworks at the top and everything else smallboxed as siblings underneath, the mental model the picture presents doesn't necessarily drive to solutions/capabilities.  Maybe that's deliberate, though?  Again, just my 2 cents.

-dc


Re: Proposal for TSC RFCs?

hmontgomery@us.fujitsu.com <hmontgomery@...>
 

Hi Brian,

 

You bring up good points.  I don’t think it’s necessary that such a decision/workflow tracker use git, or other heavyweight systems.  I obviously cannot speak for Shawn but I am pretty sure he didn’t mean that we needed to use git for this, either—just the essence of the rust RFC system.  But, as you point out, it would be nice if we had a single, searchable place for TSC-implemented policies and rules.  As Shawn points out, it would also be nice if we had a formal way to capture some of the decisions the TSC has made over the years.

 

Several times the TSC has had to remake decisions, or go back and think “did we formally say this?  Does rule X extend to Y?”  We have even “forgotten” about entire projects, as I alluded to in the subproject discussion.  So I think that a little bit of (very lightweight) formalism around this might go a long way into saving the TSC time in the long run and making it easier for people to know what rules and procedures they need to follow.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Brian Behlendorf
Sent: Tuesday, June 11, 2019 9:48 PM
To: tsc@...
Subject: Re: [Hyperledger TSC] Proposal for TSC RFCs?

 

The minutes and recordings of the TSC meetings are the formal recording of decisions made and should be considered canonical.  Since Jan 24th of this year, those notes are taken & stored on the Wiki:

 

 

Previously, minutes were taken either as emails to the TSC list or as pages on Google Docs, and then posted along with recordings on a similar page, but on our older wiki:

 

 

It would be Really Cool if volunteers emerged to do two things:

 

1) Faithfully copy over the hypertext from the old Wiki's archive page to the current one

2) Migrate all the minutes stored on Google Docs to wiki pages.

 

Doing both will make it easier to search across the minutes, ensure they don't get modified without visibility, etc.  Any takers?  This is on the long long backlog for HL's small staffed community architecture team, but seems like an easy thing we could ask for help with.

 

 

 

New project proposals are formally tracked:

 

 

However, it's clearly not kept up to date well enough, and that's another example of history that has not been ported over to the new Wiki.  Any volunteers to help clean that up?  It's annoying enough to me in its current state and the air temperature is still too warm to fall asleep so I may get to it myself tonight.  But if someone feels up for it, feel free to tag in.

 

Requiring a formal proposal template for all topics for TSC conversations, or those that would result in decisions, feels a bit process-heavy, as often small suggestions during a conversation become decisions made.  But for the larger concepts, such as new graphical takes on the greenhouse, I've been encouraging people to make these suggestions in longer form ahead of time, giving TSC members a chance to read & consider before discussing on the calls.  I'm also completely happy (as anyone who knows my antipathy for calls knows) to see issues opened, discussed, and decided completely outside of the calls.  Getting people to at least use the mailing list and Wiki for these proposals rather than Google Docs would be an improvement; seeing a page in the TSC space of outstanding issues (much like the "backlog" queue maintained in the current agenda) would as well.  But the calls are at least a place where the TSC can reach and formally record a consensus on an issue, even if that only takes 5 minutes to reflect the consensus arrived at over an email conversation.  So the minutes to those meetings should still be the canonical source of what was decided, even if the why and rationales are a bit more spread out.

 

While using Git to manage RFCs makes sense for code-level decisions, using Git/Github for TSC proposals and discussions feels like it might exclude quite a few people.  Needing to do a git clone to change text is a fair uplift from going to a wiki page and clicking edit - totally justified when you're all maintainers and already have git copies of your core projects' repos locally, but harder outside that context.  In both systems you get visibility into who's changed what.  In a wiki you get search for free (yes, one could grep locally...).  In either scenario you need gardeners, which feels like the most precious resource we have. 

 

Brian

 

On 6/11/19 3:22 PM, hmontgomery@... wrote:

I think this is a great idea.  We have forgotten and/or reinvented so many things over the years, and good documentation would help us keep track of policy, as well as help newcomers unused to the TSC workflow.

 

I don’t know what the exact best way for this to happen is—as Shawn mentions, all of the projects that used the Rust template have tweaked it, sometimes substantially.  But I think something like this would help us from making mistakes related to lack of information on previous TSC decisions.  I’d support such a task force.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Shawn Amundson
Sent: Tuesday, June 11, 2019 1:48 PM
To: hyperledger-tsc <hyperledger-tsc@...>
Subject: [Hyperledger TSC] Proposal for TSC RFCs?

 

As a project maintainer and part of the Hyperledger community, it is difficult to track what past decisions (especially related to policy) have been made by the TSC. The quality of proposals going to the TSC also seem to vary quite a bit, as does the amount of discussion about them.

In several of the projects, we have adopted an RFC process based on the one used for Rust (why invent a new one, if there is already a great one) - https://github.com/rust-lang/rfcs. Each project has adjusted it to its own needs.

Proposals like those coming out of the lifecycle and CI/CD discussions could be captured in this manner. Something like - https://github.com/rust-lang/rfcs/blob/master/0000-template.md. It's a really nice format, with sections to capture drawbacks, rationale, and alternatives -- which leads to a more informed decision.

Would the TSC be open to adopting something like this?

If so, could we form a task force to put together a solid proposal for it? (Yes, I'm volunteering.)

 

-Shawn

 

 

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


Re: Hyperledger taxonomy and revised greenhouse graphic for review

Middleton, Dan <dan.middleton@...>
 

I had a similar reaction. Frameworks are the underlying fabric ;)  responsible for data replication policies.

Thinking about future projects what would this look like if we got a consensus library project?

What other forward looking considerations come to mind?

 

Ok, now we’re up to nearly a nickel.

 

--dan

 

From: <tsc@...> on behalf of Dave Cecchi <david_cecchi@...>
Date: Wednesday, June 12, 2019 at 8:17 AM
To: "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] Hyperledger taxonomy and revised greenhouse graphic for review

 

My two cents is only that - especially with Transact starting to drive more "unification" - it may be worth reconsidering the visual to be more representative of the "stack".  This is really a catalog, but even a mildly technical audience wants to know "how do these things work together (if at all)".  With blockchain platforms / frameworks at the top and everything else smallboxed as siblings underneath, the mental model the picture presents doesn't necessarily drive to solutions/capabilities.  Maybe that's deliberate, though?  Again, just my 2 cents.

-dc


Re: Hyperledger taxonomy and revised greenhouse graphic for review

Dave Cecchi
 

My two cents is only that - especially with Transact starting to drive more "unification" - it may be worth reconsidering the visual to be more representative of the "stack".  This is really a catalog, but even a mildly technical audience wants to know "how do these things work together (if at all)".  With blockchain platforms / frameworks at the top and everything else smallboxed as siblings underneath, the mental model the picture presents doesn't necessarily drive to solutions/capabilities.  Maybe that's deliberate, though?  Again, just my 2 cents.

-dc


Re: Proposal for TSC RFCs?

Brian Behlendorf
 

The minutes and recordings of the TSC meetings are the formal recording of decisions made and should be considered canonical.  Since Jan 24th of this year, those notes are taken & stored on the Wiki:


Previously, minutes were taken either as emails to the TSC list or as pages on Google Docs, and then posted along with recordings on a similar page, but on our older wiki:


It would be Really Cool if volunteers emerged to do two things:

1) Faithfully copy over the hypertext from the old Wiki's archive page to the current one
2) Migrate all the minutes stored on Google Docs to wiki pages.

Doing both will make it easier to search across the minutes, ensure they don't get modified without visibility, etc.  Any takers?  This is on the long long backlog for HL's small staffed community architecture team, but seems like an easy thing we could ask for help with.



New project proposals are formally tracked:


However, it's clearly not kept up to date well enough, and that's another example of history that has not been ported over to the new Wiki.  Any volunteers to help clean that up?  It's annoying enough to me in its current state and the air temperature is still too warm to fall asleep so I may get to it myself tonight.  But if someone feels up for it, feel free to tag in.

Requiring a formal proposal template for all topics for TSC conversations, or those that would result in decisions, feels a bit process-heavy, as often small suggestions during a conversation become decisions made.  But for the larger concepts, such as new graphical takes on the greenhouse, I've been encouraging people to make these suggestions in longer form ahead of time, giving TSC members a chance to read & consider before discussing on the calls.  I'm also completely happy (as anyone who knows my antipathy for calls knows) to see issues opened, discussed, and decided completely outside of the calls.  Getting people to at least use the mailing list and Wiki for these proposals rather than Google Docs would be an improvement; seeing a page in the TSC space of outstanding issues (much like the "backlog" queue maintained in the current agenda) would as well.  But the calls are at least a place where the TSC can reach and formally record a consensus on an issue, even if that only takes 5 minutes to reflect the consensus arrived at over an email conversation.  So the minutes to those meetings should still be the canonical source of what was decided, even if the why and rationales are a bit more spread out.

While using Git to manage RFCs makes sense for code-level decisions, using Git/Github for TSC proposals and discussions feels like it might exclude quite a few people.  Needing to do a git clone to change text is a fair uplift from going to a wiki page and clicking edit - totally justified when you're all maintainers and already have git copies of your core projects' repos locally, but harder outside that context.  In both systems you get visibility into who's changed what.  In a wiki you get search for free (yes, one could grep locally...).  In either scenario you need gardeners, which feels like the most precious resource we have. 

Brian

On 6/11/19 3:22 PM, hmontgomery@... wrote:

I think this is a great idea.  We have forgotten and/or reinvented so many things over the years, and good documentation would help us keep track of policy, as well as help newcomers unused to the TSC workflow.

 

I don’t know what the exact best way for this to happen is—as Shawn mentions, all of the projects that used the Rust template have tweaked it, sometimes substantially.  But I think something like this would help us from making mistakes related to lack of information on previous TSC decisions.  I’d support such a task force.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Shawn Amundson
Sent: Tuesday, June 11, 2019 1:48 PM
To: hyperledger-tsc <hyperledger-tsc@...>
Subject: [Hyperledger TSC] Proposal for TSC RFCs?

 

As a project maintainer and part of the Hyperledger community, it is difficult to track what past decisions (especially related to policy) have been made by the TSC. The quality of proposals going to the TSC also seem to vary quite a bit, as does the amount of discussion about them.

In several of the projects, we have adopted an RFC process based on the one used for Rust (why invent a new one, if there is already a great one) - https://github.com/rust-lang/rfcs. Each project has adjusted it to its own needs.

Proposals like those coming out of the lifecycle and CI/CD discussions could be captured in this manner. Something like - https://github.com/rust-lang/rfcs/blob/master/0000-template.md. It's a really nice format, with sections to capture drawbacks, rationale, and alternatives -- which leads to a more informed decision.

Would the TSC be open to adopting something like this?

If so, could we form a task force to put together a solid proposal for it? (Yes, I'm volunteering.)

 

-Shawn

 


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


Re: Proposal to the TSC: enable 2FA requirement across all orgs

Brian Behlendorf
 

Thanks Ry!  Let's add to the agenda for Thursday.

Brian

On 6/11/19 3:40 PM, Ry Jones wrote:
Where we are today:
for the main org, there are three users with commit bits and no 2FA. None of these users has made a commit in over a year to any Hyperledger project as far as I can tell. Thanks to everyone that enabled two factor auth! I think it's fairly low risk to enable the requirement for 2FA at any time the TSC says it's OK.

For Labs, we have ~80 people in the org and ~20 without 2FA enabled. I haven't pushed as hard on Labs, so I suspect we should delay enabling it for a while. I haven't audited who has write bits, but I assume it's close to 100%.
Ry

On Tue, Jun 4, 2019 at 7:22 AM Ry Jones <rjones@...> wrote:
I did an audit of the main org. Slightly over half of our 400 members are not using two factor authentication.

There is no easy way to tie those members to activity in the org.

--
Ry Jones
Community Architect, Hyperledger


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


Re: Proposal to the TSC: enable 2FA requirement across all orgs

Ry Jones
 

Where we are today:
for the main org, there are three users with commit bits and no 2FA. None of these users has made a commit in over a year to any Hyperledger project as far as I can tell. Thanks to everyone that enabled two factor auth! I think it's fairly low risk to enable the requirement for 2FA at any time the TSC says it's OK.

For Labs, we have ~80 people in the org and ~20 without 2FA enabled. I haven't pushed as hard on Labs, so I suspect we should delay enabling it for a while. I haven't audited who has write bits, but I assume it's close to 100%.
Ry

On Tue, Jun 4, 2019 at 7:22 AM Ry Jones <rjones@...> wrote:
I did an audit of the main org. Slightly over half of our 400 members are not using two factor authentication.

There is no easy way to tie those members to activity in the org.

--
Ry Jones
Community Architect, Hyperledger


Re: Proposal for TSC RFCs?

hmontgomery@us.fujitsu.com <hmontgomery@...>
 

I think this is a great idea.  We have forgotten and/or reinvented so many things over the years, and good documentation would help us keep track of policy, as well as help newcomers unused to the TSC workflow.

 

I don’t know what the exact best way for this to happen is—as Shawn mentions, all of the projects that used the Rust template have tweaked it, sometimes substantially.  But I think something like this would help us from making mistakes related to lack of information on previous TSC decisions.  I’d support such a task force.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Shawn Amundson
Sent: Tuesday, June 11, 2019 1:48 PM
To: hyperledger-tsc <hyperledger-tsc@...>
Subject: [Hyperledger TSC] Proposal for TSC RFCs?

 

As a project maintainer and part of the Hyperledger community, it is difficult to track what past decisions (especially related to policy) have been made by the TSC. The quality of proposals going to the TSC also seem to vary quite a bit, as does the amount of discussion about them.

In several of the projects, we have adopted an RFC process based on the one used for Rust (why invent a new one, if there is already a great one) - https://github.com/rust-lang/rfcs. Each project has adjusted it to its own needs.

Proposals like those coming out of the lifecycle and CI/CD discussions could be captured in this manner. Something like - https://github.com/rust-lang/rfcs/blob/master/0000-template.md. It's a really nice format, with sections to capture drawbacks, rationale, and alternatives -- which leads to a more informed decision.

Would the TSC be open to adopting something like this?

If so, could we form a task force to put together a solid proposal for it? (Yes, I'm volunteering.)

 

-Shawn

 


Proposal for TSC RFCs?

Shawn Amundson
 

As a project maintainer and part of the Hyperledger community, it is difficult to track what past decisions (especially related to policy) have been made by the TSC. The quality of proposals going to the TSC also seem to vary quite a bit, as does the amount of discussion about them.

In several of the projects, we have adopted an RFC process based on the one used for Rust (why invent a new one, if there is already a great one) - https://github.com/rust-lang/rfcs. Each project has adjusted it to its own needs.

Proposals like those coming out of the lifecycle and CI/CD discussions could be captured in this manner. Something like - https://github.com/rust-lang/rfcs/blob/master/0000-template.md. It's a really nice format, with sections to capture drawbacks, rationale, and alternatives -- which leads to a more informed decision.

Would the TSC be open to adopting something like this?

If so, could we form a task force to put together a solid proposal for it? (Yes, I'm volunteering.)

-Shawn


Re: [Hyperledger Smart Contracts WG] Announcement of new (white)paper "Blockchain 3.0 Smart Contracts in e-Government 3.0 Applications"

VIPIN BHARATHAN
 

Hi Sofia,

Glad to see that you are making great progress.

I have written something up for the provenance use case for the Performance and Scale working group. It is still a preliminary draft version
If we are working on a metrics proposal, we would need a smart contracts infrastructure  that is platform agnostic (if possible), would be great if we can get the knowledge base and current thinking from Transact, Grid, the Smart Contracts SIG as well as the Supply Chain SIG into looking at this problem and to get a comprehensive solution.


Let us continue the conversation.. I am cc: ing the tsc list in light of broader vision that we need to have and to get their guidance.

Best,
Vipin

dlt.nyc
Vipin Bharathan
Enterprise Blockchain Consultant
vip@...


From: smart-contracts-wg@... <smart-contracts-wg@...> on behalf of Sofia Terzi via Lists.Hyperledger.Org <sterzi=iti.gr@...>
Sent: Saturday, June 8, 2019 1:14 PM
To: smart-contracts-wg@...
Subject: [Hyperledger Smart Contracts WG] Announcement of new (white)paper "Blockchain 3.0 Smart Contracts in e-Government 3.0 Applications"
 
Dear All,

I am more than happy to announce a new paper called "Blockchain 3.0 Smart Contracts in e-Government 3.0 Applications" which has been uploaded on our wiki for review [ https://wiki.hyperledger.org/pages/viewpage.action?pageId=13863551 ]. You are all welcome to add comments and content to it, we will discuss it on our next Smart Contracts WG meeting on Wednesday 19 June at 3.00pm GMT, so I invite you to attend. Also, there has been added much new content on the wiki, check it out https://wiki.hyperledger.org/display/SCWG/Smart+Contracts+Working+Group

Looking forward to hearing from you soon!

Best,
Sofia Terzi


Re: Hyperledger taxonomy and revised greenhouse graphic for review

Duncan Johnston-Watt
 

+1. Apart from Specialty which is American :)


On Tue, Jun 11, 2019 at 8:42 PM Brian Behlendorf <bbehlendorf@...> wrote:
On 6/11/19 9:55 AM, Shawn Amundson wrote:
I'd like to see more community involvement in these decisions and proposals.

That's literally why I sent this email.  :)  No decisions have been made yet.  This was based on conversations here and on TSC calls and private feedback to us, and is a proposal.

The following top-level categories would probably work better:

- Distributed Ledgers
- Libraries
- Specialty
- Tools

Distributed ledgers would be categorized by their ability to run general smart contracts. Libraries would be code libraries meant to be used by other projects. Specialty would be a projects with a specific focus. Tools would be app-level projects that don't contain business logic.

It could break down like this:

Distributed Ledgers:
- Burrow
- Fabric
- Iroha
- Sawtooth

Libraries:
- Ursa
- Transact

Specialty:
- Aries - wallet/edge
- Grid - supply chain
- Indy - identity
- Quilt - interop
- Composer

Tools:
- Caliper
- Cello
- Explorer

I'd possibly move Quilt to Libraries and Composer to Tools but I'm pretty OK with the rest of the above.

Brian


-Shawn

On Mon, Jun 10, 2019 at 8:31 PM Brian Behlendorf <bbehlendorf@...> wrote:
Dear TSC and others,

With the recent growth in the Hyperledger greenhouse, and continued expansion anticipated for the foreseeable future, it's time for an update to our greenhouse graphic and related project taxonomy. I requested the help of the LF Staff and Marketing Committe Chairs and they came back with two graphics that accommodate the following needed improvements: 
  • Updated the taxonomy for clarity and precision. Projects will now be classified as frameworks, components, templates and tools instead of just frameworks and tools.  We made a guess as to where each project would like to be, realizing the boundaries can be fuzzy.  If you feel they should be grouped differently let's discuss that, but we can accommodate some movement within the layout. 
  • We placed in some blank generic logos to accommodate anticipated expansion.  When we publish this formally we will remove the generic logos; it's merely intended to show where we'd expand.
  • Illustrate a broader view of the various ways to participate in the greenhouse by including a sort of foundation floor in this greenhouse to include Labs, as well as a community section including WGs, SIGs, Meetups and HGF.  If this results in a graphic that's too tall or busy for, say, a slide in a presentation slide deck, this section can be moved to its own slide, which is why we show it with and without.  It's anticipated that we'd make each of the individual components here look better before final push, perhaps by coming up with logos for each or at least different colors.
  • Emphasize the frameworks, as they are likely the first projects we want people new to HL to know about, and they pull together many of the other pieces as components.  We still need better taglines for each framework but those can be improved over time.
  • We removed the taglines for the other projects for visual simplicity; perhaps on the website when showing this graphic we can have a roll-over that shows more depth on each project before shooting you over to the project's particular home page.
  • Remove the greyed out other LF projects and "Community Stewardship and Technical, Legal, Marketing, Organizational Infrastructure" copy to avoid this looking like a sea of small print as the greenhouse grows.
Please see the revised graphics below.  We invite you to share your comments on this thread or on the call Thursday, and either then or in the near future a vote reflecting the TSC's acceptance.



HL_Greenhouse_New_V4_Community.png





HL_Greenhouse_New_V4_NoCommunity.png



I didn't turn this into a Wiki page just yet as I didn't want anyone to be confused that this was anything other than a draft, but if I'm being too cautious on that front and someone else fels it would be useful to do that, feel free.

We'll look at checking in the source materials for this chart and the logo into the wiki or GH repo.

Thanks!

Brian


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


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




Re: Hyperledger taxonomy and revised greenhouse graphic for review

Brian Behlendorf
 

On 6/11/19 9:55 AM, Shawn Amundson wrote:
I'd like to see more community involvement in these decisions and proposals.

That's literally why I sent this email.  :)  No decisions have been made yet.  This was based on conversations here and on TSC calls and private feedback to us, and is a proposal.

The following top-level categories would probably work better:

- Distributed Ledgers
- Libraries
- Specialty
- Tools

Distributed ledgers would be categorized by their ability to run general smart contracts. Libraries would be code libraries meant to be used by other projects. Specialty would be a projects with a specific focus. Tools would be app-level projects that don't contain business logic.

It could break down like this:

Distributed Ledgers:
- Burrow
- Fabric
- Iroha
- Sawtooth

Libraries:
- Ursa
- Transact

Specialty:
- Aries - wallet/edge
- Grid - supply chain
- Indy - identity
- Quilt - interop
- Composer

Tools:
- Caliper
- Cello
- Explorer

I'd possibly move Quilt to Libraries and Composer to Tools but I'm pretty OK with the rest of the above.

Brian


-Shawn

On Mon, Jun 10, 2019 at 8:31 PM Brian Behlendorf <bbehlendorf@...> wrote:
Dear TSC and others,

With the recent growth in the Hyperledger greenhouse, and continued expansion anticipated for the foreseeable future, it's time for an update to our greenhouse graphic and related project taxonomy. I requested the help of the LF Staff and Marketing Committe Chairs and they came back with two graphics that accommodate the following needed improvements: 
  • Updated the taxonomy for clarity and precision. Projects will now be classified as frameworks, components, templates and tools instead of just frameworks and tools.  We made a guess as to where each project would like to be, realizing the boundaries can be fuzzy.  If you feel they should be grouped differently let's discuss that, but we can accommodate some movement within the layout. 
  • We placed in some blank generic logos to accommodate anticipated expansion.  When we publish this formally we will remove the generic logos; it's merely intended to show where we'd expand.
  • Illustrate a broader view of the various ways to participate in the greenhouse by including a sort of foundation floor in this greenhouse to include Labs, as well as a community section including WGs, SIGs, Meetups and HGF.  If this results in a graphic that's too tall or busy for, say, a slide in a presentation slide deck, this section can be moved to its own slide, which is why we show it with and without.  It's anticipated that we'd make each of the individual components here look better before final push, perhaps by coming up with logos for each or at least different colors.
  • Emphasize the frameworks, as they are likely the first projects we want people new to HL to know about, and they pull together many of the other pieces as components.  We still need better taglines for each framework but those can be improved over time.
  • We removed the taglines for the other projects for visual simplicity; perhaps on the website when showing this graphic we can have a roll-over that shows more depth on each project before shooting you over to the project's particular home page.
  • Remove the greyed out other LF projects and "Community Stewardship and Technical, Legal, Marketing, Organizational Infrastructure" copy to avoid this looking like a sea of small print as the greenhouse grows.
Please see the revised graphics below.  We invite you to share your comments on this thread or on the call Thursday, and either then or in the near future a vote reflecting the TSC's acceptance.



HL_Greenhouse_New_V4_Community.png





HL_Greenhouse_New_V4_NoCommunity.png



I didn't turn this into a Wiki page just yet as I didn't want anyone to be confused that this was anything other than a draft, but if I'm being too cautious on that front and someone else fels it would be useful to do that, feel free.

We'll look at checking in the source materials for this chart and the logo into the wiki or GH repo.

Thanks!

Brian


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


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


Re: Hyperledger taxonomy and revised greenhouse graphic for review

Shawn Amundson
 

I'd like to see more community involvement in these decisions and proposals. It may help for the TSC to select appoint some maintainers to the MC to ensure all the projects are represented in that forum.

"Templates" is a poor choice for a category name, as it suggests a set of template files -- a very static thing. None of the projects (including grid) provide a set of templated files.

The following top-level categories would probably work better:

- Distributed Ledgers
- Libraries
- Specialty
- Tools

Distributed ledgers would be categorized by their ability to run general smart contracts. Libraries would be code libraries meant to be used by other projects. Specialty would be a projects with a specific focus. Tools would be app-level projects that don't contain business logic.

It could break down like this:

Distribute ledgers:
- Burrow
- Fabric
- Iroha
- Sawtooth

Libraries:
- Ursa
- Transact

Specialty:
- Aries - wallet/edge
- Grid - supply chain
- Indy - identity
- Quilt - interop
- Composer

Tools:
- Caliper
- Cello
- Explorer

-Shawn


On Mon, Jun 10, 2019 at 8:31 PM Brian Behlendorf <bbehlendorf@...> wrote:
Dear TSC and others,

With the recent growth in the Hyperledger greenhouse, and continued expansion anticipated for the foreseeable future, it's time for an update to our greenhouse graphic and related project taxonomy. I requested the help of the LF Staff and Marketing Committe Chairs and they came back with two graphics that accommodate the following needed improvements: 
  • Updated the taxonomy for clarity and precision. Projects will now be classified as frameworks, components, templates and tools instead of just frameworks and tools.  We made a guess as to where each project would like to be, realizing the boundaries can be fuzzy.  If you feel they should be grouped differently let's discuss that, but we can accommodate some movement within the layout. 
  • We placed in some blank generic logos to accommodate anticipated expansion.  When we publish this formally we will remove the generic logos; it's merely intended to show where we'd expand.
  • Illustrate a broader view of the various ways to participate in the greenhouse by including a sort of foundation floor in this greenhouse to include Labs, as well as a community section including WGs, SIGs, Meetups and HGF.  If this results in a graphic that's too tall or busy for, say, a slide in a presentation slide deck, this section can be moved to its own slide, which is why we show it with and without.  It's anticipated that we'd make each of the individual components here look better before final push, perhaps by coming up with logos for each or at least different colors.
  • Emphasize the frameworks, as they are likely the first projects we want people new to HL to know about, and they pull together many of the other pieces as components.  We still need better taglines for each framework but those can be improved over time.
  • We removed the taglines for the other projects for visual simplicity; perhaps on the website when showing this graphic we can have a roll-over that shows more depth on each project before shooting you over to the project's particular home page.
  • Remove the greyed out other LF projects and "Community Stewardship and Technical, Legal, Marketing, Organizational Infrastructure" copy to avoid this looking like a sea of small print as the greenhouse grows.
Please see the revised graphics below.  We invite you to share your comments on this thread or on the call Thursday, and either then or in the near future a vote reflecting the TSC's acceptance.



HL_Greenhouse_New_V4_Community.png





HL_Greenhouse_New_V4_NoCommunity.png



I didn't turn this into a Wiki page just yet as I didn't want anyone to be confused that this was anything other than a draft, but if I'm being too cautious on that front and someone else fels it would be useful to do that, feel free.

We'll look at checking in the source materials for this chart and the logo into the wiki or GH repo.

Thanks!

Brian


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


Re: Hyperledger project naming guidelines - draft for discussion

Mic Bowman
 

FWIW...

I've added this to the list of topics for the life cycle group.

--mic


On Mon, Jun 10, 2019 at 6:36 PM Brian Behlendorf <bbehlendorf@...> wrote:
The happy path is that the project, when approved by the TSC, is being approved with a particular name that everyone's happy with.  That way we can immediately set up the repo, mailing lists, Jira queue, and all other project-specific artifacts where the name is used or derived from, and where a rename is expensive.  I believe that means it's worth "marketing resources", meaning time from a mix of HL staff and perhaps some engagement with the MC, on going over naming with a new project proposal even before it's accepted by the TSC.  Often, when we catch wind of a potential new project, HL staff already engage with them, often even before a proposal is made, to help coach the proposers on how to craft a proposal that addresses likely TSC concerns, and naming can be just one part of that consultation.

The feedback seems clear: let's make the naming process proposal a part of the project lifecycle discussion happening in another thread.  We'll route it over to there.

Brian

On 6/10/19 11:42 AM, Montgomery, Hart wrote:

I agree with Dan here.

 

Also, I am not a marketing person, so take this cum grano salis, but we probably spend too much time on naming as a technical community. I’m not sure naming guidelines will be that useful either (as Brian points out as well)—I think the best approach is to require new projects to consult with or get sign-off from the marketing committee on their names.  This can be an interactive process that varies based on the needs of each project.

 

Does this make sense?

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Middleton, Dan
Sent: Monday, June 10, 2019 6:10 AM
To: Shawn Amundson <amundson@...>; Brian Behlendorf <bbehlendorf@...>
Cc: Hyperledger List <tsc@...>; Meredith Bennett <mbennett@...>
Subject: Re: [Hyperledger TSC] Hyperledger project naming guidelines - draft for discussion

 

I’d prefer to only engage marketing resources etc. after a project has been formally approved by the TSC.

 

--Dan

 

From: <tsc@...> on behalf of Shawn Amundson <amundson@...>
Date: Saturday, June 8, 2019 at 12:04 PM
To: Brian Behlendorf <bbehlendorf@...>
Cc: Hyperledger List <tsc@...>, Meredith Bennett <mbennett@...>
Subject: Re: [Hyperledger TSC] Hyperledger project naming guidelines - draft for discussion

 

We should probably fold the timing question into the lifecycle discussion, because it may depend on some of the other topics like whether everything goes through labs first.

 

-Shawn

 

On Fri, Jun 7, 2019 at 4:32 PM Brian Behlendorf <bbehlendorf@...> wrote:

Thanks all, all these comments (and those expressed during the TSC call, and those expressed in side channels elsewhere) will get back to Meredith, who'll be working on an update.

 

To a few points:

 

* These were created as a way to formalize an existing informal process, whose informality was cited as the main reason why debates over names felt arbitrary and unfair, and when feedback was given why it was sometimes dismissed.  Creating these guidelines and process won't necessarily resolve debates over names, but hopefully give us a chance to channel those discussions more productively and have process that feels optimally fair.

 

* Naming discussions necessarily involve a tremendous amount of subjectivity, aesthetics that will differ person to person, language and cultural differences, etc.  There is no algorithm that will give us a binary result as to whether a name should be allowed or not.  So instead we give guidelines, and it might be OK if those guidelines end up possibly conflicting when evaluated individually.  It also means we should not worry about whether names would have had to change if we'd used this process before now.  Bygones. 

 

And a few open questions:

 

* It seems like the primary bone of contention is around whether those names should be descriptive ("The name should give people some understanding of what the technology does and/or how people can use it.") or not.  Most current HL project names aren't related at all to what the software does.  Fitting something adequate into 8 characters, without being misleading, can be tough.  Still, it can help people looking over the landscape better if the terms have something to connect them to the rest, functionally.  Would anyone like to argue in favor of this requirement, or offer a rephrasing?

 

* Finally it seems like people want more detail as it relates to timing, and when a name should be locked in.  The timeline was written without regard to events like when a project is proposed or approved.  In my opinion, it makes sense to consider a name potentially changeable after a project is first publicly proposed, but then locked in once it's voted upon by the TSC, so that we can proceed ASAP to setting up associated resources and getting an announcement made.  Thoughts?  If it makes sense to others we can modify the process to specifically align with the project proposal/acceptance process, perhaps even merge the two.

 

Brian

 

 

On 6/7/19 12:20 PM, Shawn Amundson wrote:

Agree.

 

Additionally, having the MC or other HL staff attempt to identify potential problems with specific names and conveying that to the project team would be the really helpful thing here. Some names having bad connotations in other languages is a great example of something that the projects might not have the resources to identify independently.

 

-Shawn

 

On Fri, Jun 7, 2019 at 10:06 AM Christopher B Ferris <chrisfer@...> wrote:

As I also commented on the call, I agree that the guidelines as written don't really address the concerns.

I also agree that the guidance to use descriptive names is also more likely to result in problems especially when we have multiple similar projects (AS WE HAVE TODAY).

 

Short, catchy, names that are memorable and unique are what we should be advocating.

 

Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Cognitive Applications
email: chrisfer@...
twitter: @christo4ferris

IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Middleton, Dan" <dan.middleton@...>
Sent by: tsc@...
To: Brian Behlendorf <bbehlendorf@...>, Shawn Amundson <amundson@...>
Cc: "tsc@..." <tsc@...>
Subject: [EXTERNAL] Re: [Hyperledger TSC] Hyperledger project naming guidelines - draft for discussion
Date: Fri, Jun 7, 2019 9:46 AM
 

Per my verbal comments in the TSC meeting, I do not think these guidelines will prevent the kind of problems we’ve had in the past.

For example, there’s nothing here that makes clear a name like “blockchain” is impermissible.

 

Regarding the notion of descriptive names, I’m unclear whether that is guidance to adopt that for new names or simply another option to fully abstract names like Ursa.

 

I would appreciate if the Marketing Committee could revise these guidelines with these points in mind and the others described in this thread. There may have been other verbal feedback from the TSC meeting which is not yet captured in this thread.

 

Thanks,

Dan

 

From: <tsc@...> on behalf of Brian Behlendorf <bbehlendorf@...>
Date: Friday, June 7, 2019 at 12:46 AM
To: Shawn Amundson <amundson@...>
Cc: "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] Hyperledger project naming guidelines - draft for discussion

 

Ah, I didn't mean to ignore:

 

On 6/6/19 6:48 AM, Shawn Amundson wrote:

Who are the current members of the MC?

They're not listed publicly, but they are representatives from our Premier Members, and their calls & discussion list are open to PR contacts at all General Members.  It's defined in Section 5 of the Hyperledger Charter.  Led by Dan O'Prey from Digital Asset and Alissa Worley from Accenture.  It's how we coordinate with members on getting our collective word out about the projects and activities at HL.   They don't have any perogative or control over what goes on in the technical side of Hyperledger, but we thought they might be helpful in thinking about naming guidelines.

Brian

--

Brian Behlendorf

Executive Director, Hyperledger

Twitter: @brianbehlendorf

 

 

 

 

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


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


Upcoming Event: Hyperledger Learning Materials Development WG Quarterly Update Due #tsc-wg-update - Thu, 06/13/2019 #tsc-wg-update #cal-reminder

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Reminder: Hyperledger Learning Materials Development WG Quarterly Update Due #tsc-wg-update

When: Thursday, 13 June 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Learning Materials Development WG update to the TSC was due 10 June, 2019, and it will be presented to the TSC on 13 June, 2019. Please review the update at TSC Working Group Updates prior to the meeting and add your questions to the update.

1541 - 1560 of 3892