1. Toc
  2. Topics

[Hyperledger Project TSC] Sub-projects (was Re: Hyperledger ImprovementProjectnumbering)

Brian Behlendorf <bbehlendorf@...>
 



One thing I think we should get clarity on: the concept of "sub-projects".

To me, a "project" is a collection of developers and code who have maintainers, and make their own decisions about their roadmap, release schedule, and the like. If so, what's the value of a "sub-project"?  Even if there is substantial overlap in terms of personnel with another project, even if it's designed to be mostly tied/dependent on one particular other project, wouldn't it make sense to think of them as peers to other projects?  In what way is "fabric-sdk", for example, a meaningful "sub" to the "fabric" project, from a community/maintainership perspective?

So my humble proposal would be that where the TSC has formally approved new projects - fabric-sdk-python, fabric-sdk-java, fabric-sdk-nodejs, chaincode-tools (is that it?) that these be considered peer projects, with their own maintainers, Slack channel, mailing list, spot on the Wiki landing page, Jira project tag, and git repo(s).  We *might* even want to give them their own project product/code name, as new submissions should have in the future.  We could and should choose on a landing page on the Wiki to group such related projects together, but if we're also eager to see cross-project linkages form (like Explorer talking to Fabric, maybe also to Iroha, maybe to Corda?) then avoiding unnecessary silo-ization may be a good thing.

Sorry if this is a tangent to the current conversation, but felt it would be worth noting.

Brian


(re the Wiki: Thanks Arnaud!  And Jeremy, and Baohua, and Binh, and others who've been editing pages there.)

On 10/24/2016 06:05 PM, Arnaud Le Hors via hyperledger-tsc wrote:
On the topic of documentation I started an effort to improve our wiki and would appreciate feedback.
Please, have a look at the "top level projects" pages:

http://wiki.hyperledger.org/

My goal is to have a landing page for each project with similar information.
All feedback welcome!

Note: I'm using markdown but the plugin shows some unreliability so if one of the pages doesn't render properly, please, let me know. The LF IT team is investigating the cause.

Thanks.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - IBM Cloud




From:        GMAIL Jatinder Bali via hyperledger-tsc <hyperledger-tsc@...>
To:        "'Brian Behlendorf'" <bbehlendorf@...>, <hyperledger-tsc@...>
Cc:        "'Vipin BHARATHAN'" <vipin.bharathan@...>
Date:        10/24/2016 06:08 PM
Subject:        Re: [Hyperledger Project TSC] Hyperledger Improvement        Project        numbering
Sent by:        hyperledger-tsc-bounces@...



Hi Brian,

 

In support of Vipin when I recently asked Andreas Antonopoulos on his favorite Bitcoin BIPS, Andreas answered :

 

BIP32, BIP39, BIP43, BIP44 - Wallet related BIPS.

BIP69, BIP150, BIP151 – Security related BIPS.

BIP141, BIP142, BIP143, BIP144, BIP145 – Segwit related BIPS.

 

Imagine the same conversation with defect or case number.

 

Regards,

Jatinder

 

From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of vipin bharathan via hyperledger-tsc
Sent: Monday, October 24, 2016 9:21 AM
To: Brian Behlendorf <bbehlendorf@...>
Cc: Vipin BHARATHAN <vipin.bharathan@...>; hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Hyperledger Improvement Project numbering

 

Hello Brian,

Thanks for the thoughtful response.

1. A landing page which quickly leads us to the various major projects under incubation. At this time there are three to my knowledge: Fabric, Saw Tooth Lake and Iroha. The question is whether this should classified using HIP numbers.
2. You draw a comparison to IETF draft docs rather than BIP numbers. I agree with this as well. At the time we drew up the Project Proposal Template we did not have the "umbrella" concept. Either way there are precedents for a numbering scheme. So in contrast to you I do not see a problem with a numbering scheme.
3.We already have either interfaces between projects (a potential chaintool, a potential universal explorer etc.)-Or projects that are meant to be hosted under single projects (Java API to Fabric; Python API to Fabric etc.). They need organization as well.

Overall this is an organisational matter, so I am OK with all approaches (an overall numbering scheme, sub numbering scheme for project specific variants, a numbering scheme for enveloping projects like a universal explorer or just a name). This is a naming scheme after all and it should yield unique names.  However the most important idea is to have a way of following a process from project inception so that the project proposal starts with a name, there is nothing wrong in changing the name in case the scope changes; i.e. a project changes from Fabric specific to universal. All this should aid transparency so that a new member can easily navigate the Hyperledger project tree and discover what they need easily.

Thanks,
Vipin

 

On Oct 22, 2016 6:47 PM, "Brian Behlendorf via hyperledger-tsc" <hyperledger-tsc@...> wrote:

Hi Vipin. I started this out as a private response but felt it made sense as a reply to the TSC mailing list.   I was thinking about this more after the TSC call, and I should articulate what I was thinking...

BIPs and EIPs are proposals for changes to the specifications for how those specific networks and technologies work.  They could just as easily refer to Jira ticket numbers if they ran their projects that way, but a BIP or EIP is a good way to distinguish one idea for change from another.  Perhaps the predecessor is more something like IETF drafts, or even ISO document codes (e.g. RFC 847 or ISO 9000).

The project proposal and incubation process at Hyperledger is something different.  It's for new projects that have an independent identity, such as "Iroha", potentially sub-classible as "Iroha-Android", where what's needed is a short memberable name that puts it on par with the other projects, and doesn't necessarily need to indicate a numbered ordering.  That is, I'd prefer that we refer to Iroha as "Iroha", and not as "HIP4", because it doesn't need a shorter name than "Iroha".  I also like the personalization it brings - these are communities of developers first, or should be.  And the sooner a project comes up with a great name, if it doesn't already have it, the better.

Potentially we could see HIPs as a way to formalize emerging, originally de-facto interfaces between projects - the current Fabric grpc API, for instance, especially if Iroha or Explorer or others wish to use it.  That is more in spirit with BIPs and EIPs.

But most importantly, you surface the need to have a great landing page describing our projects and the collaboration resources that correspond to them, as well as the ones being proposed.  The wiki is looking better and better, and I think could be the place for that kind of thing.  Thoughts?

Brian

On 10/04/2016 11:10 AM, Vipin BHARATHAN wrote:

Brian/Chris,

I had proposed the following on the tsc mailing list; it sank without a trace, maybe because it was posted on a Friday before a holiday. It is a governance topic of little interest to most developers.
The initial project proposal template did have this scheme and was unanimously approved by all the tsc members.

However we lack
a. An editor who will assign these numbers
b. A numbering scheme for all projects under incubation
c. A common jumping off point (a HIP page) on the wiki

Regards,
Vipin



Hi All,

It was envisaged in the Project Proposal Template that each proposal would have a number.
"HIP identifier a short description plus a serial number with a version (for example this document is Template for a Hyperledger Improvement Project HIP 0.2)"

The proposals that have been incubated have not been assigned numbers so far.
The assignment of HIP numbers and the assembly of the links to the various proposals from one page will assist the discovery of the various proposals under incubation or in other stages of adoption. As the number of projects under incubation as well as the breadth of our activities increase this would be very useful in increasing our transparency.
I suggest that we assign numbers to the already existing proposals
1.      Fabric
2.      Sawtooth Lake
3.      Chaintool Compiler
4.      Hyperledger Explorer
5.      The java chaincode
etc.

and any other proposals being incubated. These can be linked to from a top level page in the wiki.
In some of the open source projects like Bitcoin an editor is responsible for assigning the numbers. For a sample page from bitcoin please look at  https://github.com/bitcoin/bips.
Comments and questions are welcome,

Vipin

This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. Please note that certain functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.


Unless otherwise provided above, this message was sent by BNP Paribas, or one of its affiliates in Canada, having an office at 1981 McGill College Avenue, Montreal, QC, H3A 2W8, Canada. To the extent this message is being sent from or to Canada, you may unsubscribe from receiving commercial electronic messages by using this link: www.bnpparibas.ca/en/unsubscribe/<http://www.bnpparibas.ca/en/unsubscribe/>. See www.bnpparibas.ca<http://www.bnpparibas.ca> for more information on BNP Paribas, in Canada.



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

_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc

 




 This email has been checked for viruses by Avast antivirus software.
www.avast.com

_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc




_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc



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

I think that's a fair question actually. As I started looking into the wiki I found the name of the section called "Top level projects" somewhat puzzling. It got me wondering whether this was the right denomination because we have no such name in any of our governance documentation.

So, I'll be happy to rename the list to simply "Projects" and include in that list the other projects the TSC has approved.

At the same time, I know that the Fabric development team is organized in subteams that are focusing on various aspects and I also want to document that in an effort to make it easier for new people to understand what's going on, and who's doing what.

Once the wiki is beefed up I want to clean up the info we now have in various places (github, gerrit, etc) which is duplicative and out of date. We've got to limit the number of times the same info appears across our systems or it will remain confusing and difficult to maintain.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - IBM Cloud




From:        Brian Behlendorf via hyperledger-tsc <hyperledger-tsc@...>
To:        hyperledger-tsc@...
Date:        10/25/2016 12:34 AM
Subject:        [Hyperledger Project TSC] Sub-projects (was Re: Hyperledger ImprovementProjectnumbering)
Sent by:        hyperledger-tsc-bounces@...





One thing I think we should get clarity on: the concept of "sub-projects".

To me, a "project" is a collection of developers and code who have maintainers, and make their own decisions about their roadmap, release schedule, and the like. If so, what's the value of a "sub-project"?  Even if there is substantial overlap in terms of personnel with another project, even if it's designed to be mostly tied/dependent on one particular other project, wouldn't it make sense to think of them as peers to other projects?  In what way is "fabric-sdk", for example, a meaningful "sub" to the "fabric" project, from a community/maintainership perspective?

So my humble proposal would be that where the TSC has formally approved new projects - fabric-sdk-python, fabric-sdk-java, fabric-sdk-nodejs, chaincode-tools (is that it?) that these be considered peer projects, with their own maintainers, Slack channel, mailing list, spot on the Wiki landing page, Jira project tag, and git repo(s).  We *might* even want to give them their own project product/code name, as new submissions should have in the future.  We could and should choose on a landing page on the Wiki to group such related projects together, but if we're also eager to see cross-project linkages form (like Explorer talking to Fabric, maybe also to Iroha, maybe to Corda?) then avoiding unnecessary silo-ization may be a good thing.

Sorry if this is a tangent to the current conversation, but felt it would be worth noting.

Brian


(re the Wiki: Thanks Arnaud!  And Jeremy, and Baohua, and Binh, and others who've been editing pages there.)


On 10/24/2016 06:05 PM, Arnaud Le Hors via hyperledger-tsc wrote:
On the topic of documentation I started an effort to improve our wiki and would appreciate feedback.
Please, have a look at the "top level projects" pages:

http://wiki.hyperledger.org/

My goal is to have a landing page for each project with similar information.
All feedback welcome!

Note: I'm using markdown but the plugin shows some unreliability so if one of the pages doesn't render properly, please, let me know. The LF IT team is investigating the cause.

Thanks.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - IBM Cloud




From:        GMAIL Jatinder Bali via hyperledger-tsc <hyperledger-tsc@...>
To:        "'Brian Behlendorf'" <bbehlendorf@...>, <hyperledger-tsc@...>
Cc:        "'Vipin BHARATHAN'" <vipin.bharathan@...>
Date:        10/24/2016 06:08 PM
Subject:        Re: [Hyperledger Project TSC] Hyperledger Improvement        Project        numbering
Sent by:        hyperledger-tsc-bounces@...



Hi Brian,

 

In support of Vipin when I recently asked Andreas Antonopoulos on his favorite Bitcoin BIPS, Andreas answered :

 

BIP32, BIP39, BIP43, BIP44 - Wallet related BIPS.

BIP69, BIP150, BIP151 – Security related BIPS.

BIP141, BIP142, BIP143, BIP144, BIP145 – Segwit related BIPS.

 

Imagine the same conversation with defect or case number.

 

Regards,

Jatinder

 

From: hyperledger-tsc-bounces@...[mailto:hyperledger-tsc-bounces@...] On Behalf Of vipin bharathan via hyperledger-tsc
Sent: Monday, October 24, 2016 9:21 AM
To: Brian Behlendorf <bbehlendorf@...>
Cc: Vipin BHARATHAN <vipin.bharathan@...>; hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Hyperledger Improvement Project numbering

 

Hello Brian,

Thanks for the thoughtful response.

1. A landing page which quickly leads us to the various major projects under incubation. At this time there are three to my knowledge: Fabric, Saw Tooth Lake and Iroha. The question is whether this should classified using HIP numbers.
2. You draw a comparison to IETF draft docs rather than BIP numbers. I agree with this as well. At the time we drew up the Project Proposal Template we did not have the "umbrella" concept. Either way there are precedents for a numbering scheme. So in contrast to you I do not see a problem with a numbering scheme.
3.We already have either interfaces between projects (a potential chaintool, a potential universal explorer etc.)-Or projects that are meant to be hosted under single projects (Java API to Fabric; Python API to Fabric etc.). They need organization as well.

Overall this is an organisational matter, so I am OK with all approaches (an overall numbering scheme, sub numbering scheme for project specific variants, a numbering scheme for enveloping projects like a universal explorer or just a name). This is a naming scheme after all and it should yield unique names.  However the most important idea is to have a way of following a process from project inception so that the project proposal starts with a name, there is nothing wrong in changing the name in case the scope changes; i.e. a project changes from Fabric specific to universal. All this should aid transparency so that a new member can easily navigate the Hyperledger project tree and discover what they need easily.

Thanks,
Vipin

 

On Oct 22, 2016 6:47 PM, "Brian Behlendorf via hyperledger-tsc" <hyperledger-tsc@...> wrote:

Hi Vipin. I started this out as a private response but felt it made sense as a reply to the TSC mailing list.   I was thinking about this more after the TSC call, and I should articulate what I was thinking...

BIPs and EIPs are proposals for changes to the specifications for how those specific networks and technologies work.  They could just as easily refer to Jira ticket numbers if they ran their projects that way, but a BIP or EIP is a good way to distinguish one idea for change from another.  Perhaps the predecessor is more something like IETF drafts, or even ISO document codes (e.g. RFC 847 or ISO 9000).

The project proposal and incubation process at Hyperledger is something different.  It's for new projects that have an independent identity, such as "Iroha", potentially sub-classible as "Iroha-Android", where what's needed is a short memberable name that puts it on par with the other projects, and doesn't necessarily need to indicate a numbered ordering.  That is, I'd prefer that we refer to Iroha as "Iroha", and not as "HIP4", because it doesn't need a shorter name than "Iroha".  I also like the personalization it brings - these are communities of developers first, or should be.  And the sooner a project comes up with a great name, if it doesn't already have it, the better.

Potentially we could see HIPs as a way to formalize emerging, originally de-facto interfaces between projects - the current Fabric grpc API, for instance, especially if Iroha or Explorer or others wish to use it.  That is more in spirit with BIPs and EIPs.

But most importantly, you surface the need to have a great landing page describing our projects and the collaboration resources that correspond to them, as well as the ones being proposed.  The wiki is looking better and better, and I think could be the place for that kind of thing.  Thoughts?

Brian

On 10/04/2016 11:10 AM, Vipin BHARATHAN wrote:

Brian/Chris,

I had proposed the following on the tsc mailing list; it sank without a trace, maybe because it was posted on a Friday before a holiday. It is a governance topic of little interest to most developers.
The initial project proposal template did have this scheme and was unanimously approved by all the tsc members.

However we lack
a. An editor who will assign these numbers
b. A numbering scheme for all projects under incubation
c. A common jumping off point (a HIP page) on the wiki

Regards,
Vipin



Hi All,

It was envisaged in the Project Proposal Template that each proposal would have a number.
"HIP identifier a short description plus a serial number with a version (for example this document is Template for a Hyperledger Improvement Project HIP 0.2)"

The proposals that have been incubated have not been assigned numbers so far.
The assignment of HIP numbers and the assembly of the links to the various proposals from one page will assist the discovery of the various proposals under incubation or in other stages of adoption. As the number of projects under incubation as well as the breadth of our activities increase this would be very useful in increasing our transparency.
I suggest that we assign numbers to the already existing proposals
1.      Fabric
2.      Sawtooth Lake
3.      Chaintool Compiler
4.      Hyperledger Explorer
5.      The java chaincode
etc.

and any other proposals being incubated. These can be linked to from a top level page in the wiki.
In some of the open source projects like Bitcoin an editor is responsible for assigning the numbers. For a sample page from bitcoin please look at  https://github.com/bitcoin/bips.
Comments and questions are welcome,

Vipin

This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. Please note that certain functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.


Unless otherwise provided above, this message was sent by BNP Paribas, or one of its affiliates in Canada, having an office at 1981 McGill College Avenue, Montreal, QC, H3A 2W8, Canada. To the extent this message is being sent from or to Canada, you may unsubscribe from receiving commercial electronic messages by using this link: www.bnpparibas.ca/en/unsubscribe/<http://www.bnpparibas.ca/en/unsubscribe/>. See www.bnpparibas.ca<http://www.bnpparibas.ca> for more information on BNP Paribas, in Canada.



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

_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc

 


This email has been checked for viruses by Avast antivirus software.
www.avast.com

_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc



_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc

--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc

1 - 2 of 2