CHANGES IN COMPOSER Re: [Hyperledger Healthcare WG] Agenda for 9/28 HLHCWG #Patient-Member-Subgroup Meeting #patient-member-subgroup #donormilk


Zeljko Milinovic <zeljko.milgrz@...>
 

Hi to all,

I just came upon an article:


It seems so that IBM folks will no longer invest so much in Composer.

My question to all of you and especially to Ben, what are our alternatives?

Could we still use Javascript or we have to remodel and reprogram everything in Go language?

Kind Regards.

Zeljko Milinovic

Zeljko Milinovic <zeljko.milgrz@...> schrieb am So., 30. Sep. 2018, 09:22:

Hi Marissa,

Thanks for the great Email. I added my suggestions in bolded text.

____________________


Responses to Zeljko and Ben's Questions

 

1 .We could make inside the WIKI page some Collaboration, or maybe would be great if we could rent some JIRA Spaces for developing the project further.

 => Agreed, a board would be convenient to organize ourselves and help prioritize what is a P0 feature versus nice to haves. @all, do we already have a board tool available?

I have made a request with Hyperledger Help Desk to get us a JIRA workspace where we can organize ourselves. We confirmed that logging into this tool will be via Linux Foundation ID, so it will ensure equal access to everyone on the projects. TBD on when we get this, but I will keep everyone posted. Friday we had discussed using the donor milk wiki as a placeholder for requirements and stories (see Section 2). @Mikhail Elias  you had mentioned wanting to use this as a test case for some wiki work, so let me know how I can help

Thanks Marissa. I think to make further great progress with the PoC the JIRA workspace is of a great esence to the project, as I mentioned already. Team cannot continue to be agile without this tool. Wiki is ok and we can collaborate here, but the project needs more for the troubleshootings and builds.

2. We could use Mocha and Cucumber for testing the model before deploying

 => I've never used Cucumber but if we have time to write some proper unit tests before the deadline then yes, we should. I'll try to include some proper user stories we can turn into tests sometime next week.

Ben has built a great .CTO model that I have reviewed and commented. I have learned a lot from his model, great work Ben. As fort he Mocha and Cucumber, we can use these tools to test the model before we get into further application development. Those are great frameworks for testing the model assuming that we will have a lot of data on the chain and to simulate those situations.

My knowledge is very limited here, but I'm assuming we're talking about setting up a test network? In speaking with Tracy, she reminded me that all Fabric nodes do not have to be in the same cloud server, so I have reached out to the #fabric Rocket.Chat channel to seek advice here. While Zeljko's offer is generous to stand up a VPS for the group, it is not ideal. If this is not what you're referring to here, my comments are still relevant, just not for this topic :-).

As fort he VPS instance, maybe we could get on from the Linux Foundation. I offered help here and also talked to Ben about this. This is also very important, because when we start to build the WEB and MOBILE APPs , we would need a living REST Server and also to achieve UNIT Testing without a living VPS instance will not be possible.

3. We should check the Child-Parent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships

 => I'm using a tree based structure where every change of state (split/pooling) triggers the creation of a new asset ID. This isn't quite the same as RR (you can revert back into the original asset ID) but with every node being linked to both parent and child this allows for complete traceability.

No comment

As for the relationships, tree based what Ben did is great, but I think when we test this model with simulating a lot of data with Mocha or Cucumber, we could come up on performance issues with the Mobile app, becuase every change of state creates a new Asset ID, an I was thinking with RR we have a unique ID for one asset from the beginning of the life cycle. But this is something to be tested in the future with Ben. May be that I am also wrong here, cannot really tell before I test the Model on a live network VPS.

4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset

 => This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions.

Yes, if people want to start logging issues in GitHub now (as we wait for JIRA), please feel free to do so in the Issues Tab of the repo. I've created a "test issue" on this

5. Some Documentation and Model Planning would be great to have.

 => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute.

Yay, documentation!

 

@Benjamin Djidi - are we still looking for someone to engage on the access permissions work? Markus CC'd here had mentioned he had some resources to lend, so we can pursue that if needed. Also, would it be helpful to speak to the Identity Working Group on this? They have offered to come and talk to the HCWG, so was wondering if this would be along the same vein or not.

As for the relationships, this should not be a great issue. It needs to be defined (from the Use Case and the processess that are now in use) which participants need to access what and it can be coded pretty fast.

Recommended approach for working with the Donor Milk code repository

 

I'd love for someone to write up a quick best practices for engaging with the milk-donor repo code. I'm not the best person to do it. Anyone interested?

 

Below are all of the resources we have so far. In addition to the below we have confirmed that only members of the milk-donor-committers team can actually merge a pull request: currently this is Angela, Ben, and Zeljko. Let me know if others want to be included in this group.

 

Here are the resources that Angela, Ry and Tracy have sent out (Many Thanks!):

The link to the github docs that outlines and explains how to create a pull request to add files from a fork

https://help.github.com/articles/creating-a-pull-request-from-a-fork/

Making your first pull request in Hyperledger: https://www.youtube.com/watch?v=f5XZe7dv0_U

Here are a couple of more resources that may help:

Gist on Contributing - Tracy made this for the Training and Education WG, but if you change out https://github.com/hyperledger/education and references to local education repository, the general ideas should apply to the Milk Donor lab.

git Workflow Presentation - a presentation that is basically identical to the above Gist.

Tracy uses this workflow to sync her local fork - https://help.github.com/articles/syncing-a-fork/. There should probably be a step #6 which is a `git push` command to push the merged changes back to the local fork

Update on MPV UI Workflow

 

I know this is far from what the person creating the UI will need, but I tried to breakdown the high- level flow by actors and then whether or not the system was engaged at each step. This can be found in Section 2 of the Wiki in a PPT: happy_path_mpv_flow_for_donor_milk.pptx

 

Several questions came up for me while working on this, especially around when the donor milk application was going to be used on a computer vs a handheld for scanning, and how scanning would actually work in the laboratory setting. I'd like to get feedback and then take this to our SMEs for input. Thoughts?

We could use the Bar Code or QRCode NodeJS libraries for scanning the assets for the apps. Just a thought.

 

Kind regards.

Zeljko Milinovic, MSc

http://itstuffallaround.blogspot.com/


Am So., 30. Sep. 2018 um 04:06 Uhr schrieb Marissa Iannarone <mari.iannarone@...>:
Hello Everyone!

We had a great meeting on Friday, and thanks to Ben for showing us what has been built in the network so far. We will have full notes posted shortly, but I wanted to respond to a couple of questions that Zeljko and Ben posed below, offer a few resources on how to engage with the repo, and give an update on the UI MVP userflow. If you have any questions, please let me know.

Responses to Zeljko and Ben's Questions

1 .We could make inside the WIKI page some Collaboration, or maybe would be great if we could rent some JIRA Spaces for developing the project further.
 => Agreed, a board would be convenient to organize ourselves and help prioritize what is a P0 feature versus nice to haves. @all, do we already have a board tool available?
I have made a request with Hyperledger Help Desk to get us a JIRA workspace where we can organize ourselves. We confirmed that logging into this tool will be via Linux Foundation ID, so it will ensure equal access to everyone on the projects. TBD on when we get this, but I will keep everyone posted. Friday we had discussed using the donor milk wiki as a placeholder for requirements and stories (see Section 2). @Mikhail Elias  you had mentioned wanting to use this as a test case for some wiki work, so let me know how I can help
2. We could use Mocha and Cucumber for testing the model before deploying
 => I've never used Cucumber but if we have time to write some proper unit tests before the deadline then yes, we should. I'll try to include some proper user stories we can turn into tests sometime next week.
My knowledge is very limited here, but I'm assuming we're talking about setting up a test network? In speaking with Tracy, she reminded me that all Fabric nodes do not have to be in the same cloud server, so I have reached out to the #fabric Rocket.Chat channel to seek advice here. While Zeljko's offer is generous to stand up a VPS for the group, it is not ideal. If this is not what you're referring to here, my comments are still relevant, just not for this topic :-).
3. We should check the Child-Parent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships
 => I'm using a tree based structure where every change of state (split/pooling) triggers the creation of a new asset ID. This isn't quite the same as RR (you can revert back into the original asset ID) but with every node being linked to both parent and child this allows for complete traceability.
No comment
4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset
=> This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions.
Yes, if people want to start logging issues in GitHub now (as we wait for JIRA), please feel free to do so in the Issues Tab of the repo. I've created a "test issue" on this
5. Some Documentation and Model Planning would be great to have.
 => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute.
Yay, documentation!

@Benjamin Djidi - are we still looking for someone to engage on the access permissions work? Markus CC'd here had mentioned he had some resources to lend, so we can pursue that if needed. Also, would it be helpful to speak to the Identity Working Group on this? They have offered to come and talk to the HCWG, so was wondering if this would be along the same vein or not.

Recommended approach for working with the Donor Milk code repository

I'd love for someone to write up a quick best practices for engaging with the milk-donor repo code. I'm not the best person to do it. Anyone interested?

Below are all of the resources we have so far. In addition to the below we have confirmed that only members of the milk-donor-committers team can actually merge a pull request: currently this is Angela, Ben, and Zeljko. Let me know if others want to be included in this group.

Here are the resources that Angela, Ry and Tracy have sent out (Many Thanks!):
Update on MPV UI Workflow

I know this is far from what the person creating the UI will need, but I tried to breakdown the high- level flow by actors and then whether or not the system was engaged at each step. This can be found in Section 2 of the Wiki in a PPT: happy_path_mpv_flow_for_donor_milk.pptx

Several questions came up for me while working on this, especially around when the donor milk application was going to be used on a computer vs a handheld for scanning, and how scanning would actually work in the laboratory setting. I'd like to get feedback and then take this to our SMEs for input. Thoughts?

Best,
M

Marissa Iannarone
Associate with Forum Solutions LLC
phone number: +01 (360) 525 4961
email: mari.iannarone@...



On Sat, Sep 29, 2018 at 5:17 PM Benjamin Djidi <benjamin.djidi@...> wrote:
Hi Zeljko,

Thanks for checking and sorry for the delay in answering. To your points:

1 .We could make inside the WIKI page some Collaboration, or maybe would be great if we could rent some JIRA Spaces for developing the project further.
 => Agreed, a board would be convenient to organize ourselves and helo prioritize what is a P0 feature versus nice to haves. @all, do we already have a board tool available?
2. We could use Mocha and Cucumber for testing the model before deploying
 => I've never used Cucumber but if we have time to write some proper unit tests before the deadline then yes, we should. I'll try to include some proper user stories we can turn into tests sometime next week.
3. We should check the Child-Parent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships
 => I'm using a tree based structure where every change of state (split/pooling) triggers the creation of a new asset ID. This isn't quite the same as RR (you can revert back into the original asset ID) but with every node being linked to both parent and child this allows for complete traceability.
4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset
=> This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions.
5. Some Documentation and Model Planning would be great to have.
 => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute.

Thanks,

Ben.

On Wed, Sep 26, 2018 at 9:01 AM Zeljko Milinovic <zeljko.milgrz@...> wrote:
Hi, 

I have seen the .CTO File from Ben. 

@Benjamin - nice work with the assets and the Model.

I have maybe some suggestions. 

1 .We could make inside the WIKI page some Collaboration , or maybe would be great if we could rent some JIRA Spaces for developing the project further.
2. We could use Mocha and Cucumber for testing the model before deploying
3. We should check the Child-Parrent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships
4. Maybe we could discusss topics in JIRA about the Owner Status of the milkAsset Asset
5. Some Documentation and Model Planing would be great to have.

I can offer my Jira skills and also Project Management skills within the Scope of this Project.

Kind Regards.

Zeljko Milinovic, MSc
Certified Blockchain Architect
Austria, Graz

Rich Bloch <richardbloch@...> schrieb am Mi., 26. Sep. 2018, 17:19:
Good Morning Ry,

Understood. True that ACL management is not particularly mature in Github. And as you point out, the implications can be sweeping.

It's too bad that we can't silo spinout projects of HL such as this to prevent this workflow limitation.

Appreciate the explanation... I suspected it was policy-related :/.

Thanks

Rich

Richard Bloch
Principal, Business Learning Incorporated
Systems & Software Engineering
Seattle, Washington USA
   206.588.6054 - work 
   425.417.8255- mobile 
    www.businesslearninginc.com


On Tue, Sep 25, 2018 at 10:15 PM Ry Jones <rjones@...> wrote:
Rich,
It boils down to the GitHub default workflow. You don’t need anyone’s say-so to fork a public (or private) repo - you might need someone’s say-so to create a branch in a repo you don’t own.

There are further difficulties around this. GitHub’s ACL management leaves a lot to be desired - permissions I wish I could delegate are part of the Owner or Admin role; giving someone these roles grants very broad permissions, up to and including deleting the entire org.

The Linux Foundation position, pre-Hyperledger, was everyone needs to use Gerrit. In fact, some projects in Hyperledger are using Gerrit right now. Gerrit is not all sunshine and rainbows, though.

I personally find Gerrit more amenable, but GitHub has won the field.
Ry

On Tue, Sep 25, 2018 at 17:10 Rich Bloch <richardbloch@...> wrote:
Good Afternoon,

Out of curiosity (perhaps this is HL policy), why generate so many forks instead of just creating separate branches? I'd think that, unless the forks lead to substantially different endpoints, it'd likely be easier to manage the branches (branching and merging is key when you have many devs working collaboratively). Again, not criticizing... just curious (and a learning opportunity for me).

Rich
--
Ry Jones
Community Architect, Hyperledger
Chat: @ry

--

Benjamin Djidi

Sr. BIE, Amazon International Expansion
Former Founding Partner, Revstr
President Emeritus, IESEG International Club

+33 762 001 145


Rich Bloch
 

Good Afternoon All,

This issue came up in our Hyperledger Seattle Meetup discussion on Slack recently. 

Convector seems to be one option, but here's a good article to consider: https://hackernoon.com/hyperledger-composer-has-been-put-on-pause-what-are-your-options-now-dfc3a97a6308.

Rich

Richard Bloch
Principal, Business Learning Incorporated
Systems & Software Engineering
Seattle, Washington USA
   206.588.6054 - work 
   425.417.8255- mobile 
    www.businesslearninginc.com


On Mon, Oct 1, 2018 at 1:03 PM Zeljko Milinovic <zeljko.milgrz@...> wrote:
Hi to all,

I just came upon an article:


It seems so that IBM folks will no longer invest so much in Composer.

My question to all of you and especially to Ben, what are our alternatives?

Could we still use Javascript or we have to remodel and reprogram everything in Go language?

Kind Regards.

Zeljko Milinovic

Zeljko Milinovic <zeljko.milgrz@...> schrieb am So., 30. Sep. 2018, 09:22:

Hi Marissa,

Thanks for the great Email. I added my suggestions in bolded text.

____________________


Responses to Zeljko and Ben's Questions

 

1 .We could make inside the WIKI page some Collaboration, or maybe would be great if we could rent some JIRA Spaces for developing the project further.

 => Agreed, a board would be convenient to organize ourselves and help prioritize what is a P0 feature versus nice to haves. @all, do we already have a board tool available?

I have made a request with Hyperledger Help Desk to get us a JIRA workspace where we can organize ourselves. We confirmed that logging into this tool will be via Linux Foundation ID, so it will ensure equal access to everyone on the projects. TBD on when we get this, but I will keep everyone posted. Friday we had discussed using the donor milk wiki as a placeholder for requirements and stories (see Section 2). @Mikhail Elias  you had mentioned wanting to use this as a test case for some wiki work, so let me know how I can help

Thanks Marissa. I think to make further great progress with the PoC the JIRA workspace is of a great esence to the project, as I mentioned already. Team cannot continue to be agile without this tool. Wiki is ok and we can collaborate here, but the project needs more for the troubleshootings and builds.

2. We could use Mocha and Cucumber for testing the model before deploying

 => I've never used Cucumber but if we have time to write some proper unit tests before the deadline then yes, we should. I'll try to include some proper user stories we can turn into tests sometime next week.

Ben has built a great .CTO model that I have reviewed and commented. I have learned a lot from his model, great work Ben. As fort he Mocha and Cucumber, we can use these tools to test the model before we get into further application development. Those are great frameworks for testing the model assuming that we will have a lot of data on the chain and to simulate those situations.

My knowledge is very limited here, but I'm assuming we're talking about setting up a test network? In speaking with Tracy, she reminded me that all Fabric nodes do not have to be in the same cloud server, so I have reached out to the #fabric Rocket.Chat channel to seek advice here. While Zeljko's offer is generous to stand up a VPS for the group, it is not ideal. If this is not what you're referring to here, my comments are still relevant, just not for this topic :-).

As fort he VPS instance, maybe we could get on from the Linux Foundation. I offered help here and also talked to Ben about this. This is also very important, because when we start to build the WEB and MOBILE APPs , we would need a living REST Server and also to achieve UNIT Testing without a living VPS instance will not be possible.

3. We should check the Child-Parent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships

 => I'm using a tree based structure where every change of state (split/pooling) triggers the creation of a new asset ID. This isn't quite the same as RR (you can revert back into the original asset ID) but with every node being linked to both parent and child this allows for complete traceability.

No comment

As for the relationships, tree based what Ben did is great, but I think when we test this model with simulating a lot of data with Mocha or Cucumber, we could come up on performance issues with the Mobile app, becuase every change of state creates a new Asset ID, an I was thinking with RR we have a unique ID for one asset from the beginning of the life cycle. But this is something to be tested in the future with Ben. May be that I am also wrong here, cannot really tell before I test the Model on a live network VPS.

4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset

 => This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions.

Yes, if people want to start logging issues in GitHub now (as we wait for JIRA), please feel free to do so in the Issues Tab of the repo. I've created a "test issue" on this

5. Some Documentation and Model Planning would be great to have.

 => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute.

Yay, documentation!

 

@Benjamin Djidi - are we still looking for someone to engage on the access permissions work? Markus CC'd here had mentioned he had some resources to lend, so we can pursue that if needed. Also, would it be helpful to speak to the Identity Working Group on this? They have offered to come and talk to the HCWG, so was wondering if this would be along the same vein or not.

As for the relationships, this should not be a great issue. It needs to be defined (from the Use Case and the processess that are now in use) which participants need to access what and it can be coded pretty fast.

Recommended approach for working with the Donor Milk code repository

 

I'd love for someone to write up a quick best practices for engaging with the milk-donor repo code. I'm not the best person to do it. Anyone interested?

 

Below are all of the resources we have so far. In addition to the below we have confirmed that only members of the milk-donor-committers team can actually merge a pull request: currently this is Angela, Ben, and Zeljko. Let me know if others want to be included in this group.

 

Here are the resources that Angela, Ry and Tracy have sent out (Many Thanks!):

The link to the github docs that outlines and explains how to create a pull request to add files from a fork

https://help.github.com/articles/creating-a-pull-request-from-a-fork/

Making your first pull request in Hyperledger: https://www.youtube.com/watch?v=f5XZe7dv0_U

Here are a couple of more resources that may help:

Gist on Contributing - Tracy made this for the Training and Education WG, but if you change out https://github.com/hyperledger/education and references to local education repository, the general ideas should apply to the Milk Donor lab.

git Workflow Presentation - a presentation that is basically identical to the above Gist.

Tracy uses this workflow to sync her local fork - https://help.github.com/articles/syncing-a-fork/. There should probably be a step #6 which is a `git push` command to push the merged changes back to the local fork

Update on MPV UI Workflow

 

I know this is far from what the person creating the UI will need, but I tried to breakdown the high- level flow by actors and then whether or not the system was engaged at each step. This can be found in Section 2 of the Wiki in a PPT: happy_path_mpv_flow_for_donor_milk.pptx

 

Several questions came up for me while working on this, especially around when the donor milk application was going to be used on a computer vs a handheld for scanning, and how scanning would actually work in the laboratory setting. I'd like to get feedback and then take this to our SMEs for input. Thoughts?

We could use the Bar Code or QRCode NodeJS libraries for scanning the assets for the apps. Just a thought.

 

Kind regards.

Zeljko Milinovic, MSc

http://itstuffallaround.blogspot.com/


Am So., 30. Sep. 2018 um 04:06 Uhr schrieb Marissa Iannarone <mari.iannarone@...>:
Hello Everyone!

We had a great meeting on Friday, and thanks to Ben for showing us what has been built in the network so far. We will have full notes posted shortly, but I wanted to respond to a couple of questions that Zeljko and Ben posed below, offer a few resources on how to engage with the repo, and give an update on the UI MVP userflow. If you have any questions, please let me know.

Responses to Zeljko and Ben's Questions

1 .We could make inside the WIKI page some Collaboration, or maybe would be great if we could rent some JIRA Spaces for developing the project further.
 => Agreed, a board would be convenient to organize ourselves and help prioritize what is a P0 feature versus nice to haves. @all, do we already have a board tool available?
I have made a request with Hyperledger Help Desk to get us a JIRA workspace where we can organize ourselves. We confirmed that logging into this tool will be via Linux Foundation ID, so it will ensure equal access to everyone on the projects. TBD on when we get this, but I will keep everyone posted. Friday we had discussed using the donor milk wiki as a placeholder for requirements and stories (see Section 2). @Mikhail Elias  you had mentioned wanting to use this as a test case for some wiki work, so let me know how I can help
2. We could use Mocha and Cucumber for testing the model before deploying
 => I've never used Cucumber but if we have time to write some proper unit tests before the deadline then yes, we should. I'll try to include some proper user stories we can turn into tests sometime next week.
My knowledge is very limited here, but I'm assuming we're talking about setting up a test network? In speaking with Tracy, she reminded me that all Fabric nodes do not have to be in the same cloud server, so I have reached out to the #fabric Rocket.Chat channel to seek advice here. While Zeljko's offer is generous to stand up a VPS for the group, it is not ideal. If this is not what you're referring to here, my comments are still relevant, just not for this topic :-).
3. We should check the Child-Parent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships
 => I'm using a tree based structure where every change of state (split/pooling) triggers the creation of a new asset ID. This isn't quite the same as RR (you can revert back into the original asset ID) but with every node being linked to both parent and child this allows for complete traceability.
No comment
4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset
=> This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions.
Yes, if people want to start logging issues in GitHub now (as we wait for JIRA), please feel free to do so in the Issues Tab of the repo. I've created a "test issue" on this
5. Some Documentation and Model Planning would be great to have.
 => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute.
Yay, documentation!

@Benjamin Djidi - are we still looking for someone to engage on the access permissions work? Markus CC'd here had mentioned he had some resources to lend, so we can pursue that if needed. Also, would it be helpful to speak to the Identity Working Group on this? They have offered to come and talk to the HCWG, so was wondering if this would be along the same vein or not.

Recommended approach for working with the Donor Milk code repository

I'd love for someone to write up a quick best practices for engaging with the milk-donor repo code. I'm not the best person to do it. Anyone interested?

Below are all of the resources we have so far. In addition to the below we have confirmed that only members of the milk-donor-committers team can actually merge a pull request: currently this is Angela, Ben, and Zeljko. Let me know if others want to be included in this group.

Here are the resources that Angela, Ry and Tracy have sent out (Many Thanks!):
Update on MPV UI Workflow

I know this is far from what the person creating the UI will need, but I tried to breakdown the high- level flow by actors and then whether or not the system was engaged at each step. This can be found in Section 2 of the Wiki in a PPT: happy_path_mpv_flow_for_donor_milk.pptx

Several questions came up for me while working on this, especially around when the donor milk application was going to be used on a computer vs a handheld for scanning, and how scanning would actually work in the laboratory setting. I'd like to get feedback and then take this to our SMEs for input. Thoughts?

Best,
M

Marissa Iannarone
Associate with Forum Solutions LLC
phone number: +01 (360) 525 4961
email: mari.iannarone@...



On Sat, Sep 29, 2018 at 5:17 PM Benjamin Djidi <benjamin.djidi@...> wrote:
Hi Zeljko,

Thanks for checking and sorry for the delay in answering. To your points:

1 .We could make inside the WIKI page some Collaboration, or maybe would be great if we could rent some JIRA Spaces for developing the project further.
 => Agreed, a board would be convenient to organize ourselves and helo prioritize what is a P0 feature versus nice to haves. @all, do we already have a board tool available?
2. We could use Mocha and Cucumber for testing the model before deploying
 => I've never used Cucumber but if we have time to write some proper unit tests before the deadline then yes, we should. I'll try to include some proper user stories we can turn into tests sometime next week.
3. We should check the Child-Parent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships
 => I'm using a tree based structure where every change of state (split/pooling) triggers the creation of a new asset ID. This isn't quite the same as RR (you can revert back into the original asset ID) but with every node being linked to both parent and child this allows for complete traceability.
4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset
=> This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions.
5. Some Documentation and Model Planning would be great to have.
 => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute.

Thanks,

Ben.

On Wed, Sep 26, 2018 at 9:01 AM Zeljko Milinovic <zeljko.milgrz@...> wrote:
Hi, 

I have seen the .CTO File from Ben. 

@Benjamin - nice work with the assets and the Model.

I have maybe some suggestions. 

1 .We could make inside the WIKI page some Collaboration , or maybe would be great if we could rent some JIRA Spaces for developing the project further.
2. We could use Mocha and Cucumber for testing the model before deploying
3. We should check the Child-Parrent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships
4. Maybe we could discusss topics in JIRA about the Owner Status of the milkAsset Asset
5. Some Documentation and Model Planing would be great to have.

I can offer my Jira skills and also Project Management skills within the Scope of this Project.

Kind Regards.

Zeljko Milinovic, MSc
Certified Blockchain Architect
Austria, Graz

Rich Bloch <richardbloch@...> schrieb am Mi., 26. Sep. 2018, 17:19:
Good Morning Ry,

Understood. True that ACL management is not particularly mature in Github. And as you point out, the implications can be sweeping.

It's too bad that we can't silo spinout projects of HL such as this to prevent this workflow limitation.

Appreciate the explanation... I suspected it was policy-related :/.

Thanks

Rich

Richard Bloch
Principal, Business Learning Incorporated
Systems & Software Engineering
Seattle, Washington USA
   206.588.6054 - work 
   425.417.8255- mobile 
    www.businesslearninginc.com


On Tue, Sep 25, 2018 at 10:15 PM Ry Jones <rjones@...> wrote:
Rich,
It boils down to the GitHub default workflow. You don’t need anyone’s say-so to fork a public (or private) repo - you might need someone’s say-so to create a branch in a repo you don’t own.

There are further difficulties around this. GitHub’s ACL management leaves a lot to be desired - permissions I wish I could delegate are part of the Owner or Admin role; giving someone these roles grants very broad permissions, up to and including deleting the entire org.

The Linux Foundation position, pre-Hyperledger, was everyone needs to use Gerrit. In fact, some projects in Hyperledger are using Gerrit right now. Gerrit is not all sunshine and rainbows, though.

I personally find Gerrit more amenable, but GitHub has won the field.
Ry

On Tue, Sep 25, 2018 at 17:10 Rich Bloch <richardbloch@...> wrote:
Good Afternoon,

Out of curiosity (perhaps this is HL policy), why generate so many forks instead of just creating separate branches? I'd think that, unless the forks lead to substantially different endpoints, it'd likely be easier to manage the branches (branching and merging is key when you have many devs working collaboratively). Again, not criticizing... just curious (and a learning opportunity for me).

Rich
--
Ry Jones
Community Architect, Hyperledger
Chat: @ry

--

Benjamin Djidi

Sr. BIE, Amazon International Expansion
Former Founding Partner, Revstr
President Emeritus, IESEG International Club

+33 762 001 145


Zeljko Milinovic <zeljko.milgrz@...>
 

Hi,

Yes I have seen the Convector.
But the question is, is it under Hyperledger Umbrella. Will it be supported native in the future. 
Is it better to use an Nodejs shim alternative?

Kr 

Zeljko Milinovic 


Richard Bloch <richardbloch@...> schrieb am Mo., 1. Okt. 2018, 22:58:

Good Afternoon All,

This issue came up in our Hyperledger Seattle Meetup discussion on Slack recently. 

Convector seems to be one option, but here's a good article to consider: https://hackernoon.com/hyperledger-composer-has-been-put-on-pause-what-are-your-options-now-dfc3a97a6308.

Rich

Richard Bloch
Principal, Business Learning Incorporated
Systems & Software Engineering
Seattle, Washington USA
   206.588.6054 - work 
   425.417.8255- mobile 
    www.businesslearninginc.com


On Mon, Oct 1, 2018 at 1:03 PM Zeljko Milinovic <zeljko.milgrz@...> wrote:
Hi to all,

I just came upon an article:


It seems so that IBM folks will no longer invest so much in Composer.

My question to all of you and especially to Ben, what are our alternatives?

Could we still use Javascript or we have to remodel and reprogram everything in Go language?

Kind Regards.

Zeljko Milinovic

Zeljko Milinovic <zeljko.milgrz@...> schrieb am So., 30. Sep. 2018, 09:22:

Hi Marissa,

Thanks for the great Email. I added my suggestions in bolded text.

____________________


Responses to Zeljko and Ben's Questions

 

1 .We could make inside the WIKI page some Collaboration, or maybe would be great if we could rent some JIRA Spaces for developing the project further.

 => Agreed, a board would be convenient to organize ourselves and help prioritize what is a P0 feature versus nice to haves. @all, do we already have a board tool available?

I have made a request with Hyperledger Help Desk to get us a JIRA workspace where we can organize ourselves. We confirmed that logging into this tool will be via Linux Foundation ID, so it will ensure equal access to everyone on the projects. TBD on when we get this, but I will keep everyone posted. Friday we had discussed using the donor milk wiki as a placeholder for requirements and stories (see Section 2). @Mikhail Elias  you had mentioned wanting to use this as a test case for some wiki work, so let me know how I can help

Thanks Marissa. I think to make further great progress with the PoC the JIRA workspace is of a great esence to the project, as I mentioned already. Team cannot continue to be agile without this tool. Wiki is ok and we can collaborate here, but the project needs more for the troubleshootings and builds.

2. We could use Mocha and Cucumber for testing the model before deploying

 => I've never used Cucumber but if we have time to write some proper unit tests before the deadline then yes, we should. I'll try to include some proper user stories we can turn into tests sometime next week.

Ben has built a great .CTO model that I have reviewed and commented. I have learned a lot from his model, great work Ben. As fort he Mocha and Cucumber, we can use these tools to test the model before we get into further application development. Those are great frameworks for testing the model assuming that we will have a lot of data on the chain and to simulate those situations.

My knowledge is very limited here, but I'm assuming we're talking about setting up a test network? In speaking with Tracy, she reminded me that all Fabric nodes do not have to be in the same cloud server, so I have reached out to the #fabric Rocket.Chat channel to seek advice here. While Zeljko's offer is generous to stand up a VPS for the group, it is not ideal. If this is not what you're referring to here, my comments are still relevant, just not for this topic :-).

As fort he VPS instance, maybe we could get on from the Linux Foundation. I offered help here and also talked to Ben about this. This is also very important, because when we start to build the WEB and MOBILE APPs , we would need a living REST Server and also to achieve UNIT Testing without a living VPS instance will not be possible.

3. We should check the Child-Parent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships

 => I'm using a tree based structure where every change of state (split/pooling) triggers the creation of a new asset ID. This isn't quite the same as RR (you can revert back into the original asset ID) but with every node being linked to both parent and child this allows for complete traceability.

No comment

As for the relationships, tree based what Ben did is great, but I think when we test this model with simulating a lot of data with Mocha or Cucumber, we could come up on performance issues with the Mobile app, becuase every change of state creates a new Asset ID, an I was thinking with RR we have a unique ID for one asset from the beginning of the life cycle. But this is something to be tested in the future with Ben. May be that I am also wrong here, cannot really tell before I test the Model on a live network VPS.

4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset

 => This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions.

Yes, if people want to start logging issues in GitHub now (as we wait for JIRA), please feel free to do so in the Issues Tab of the repo. I've created a "test issue" on this

5. Some Documentation and Model Planning would be great to have.

 => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute.

Yay, documentation!

 

@Benjamin Djidi - are we still looking for someone to engage on the access permissions work? Markus CC'd here had mentioned he had some resources to lend, so we can pursue that if needed. Also, would it be helpful to speak to the Identity Working Group on this? They have offered to come and talk to the HCWG, so was wondering if this would be along the same vein or not.

As for the relationships, this should not be a great issue. It needs to be defined (from the Use Case and the processess that are now in use) which participants need to access what and it can be coded pretty fast.

Recommended approach for working with the Donor Milk code repository

 

I'd love for someone to write up a quick best practices for engaging with the milk-donor repo code. I'm not the best person to do it. Anyone interested?

 

Below are all of the resources we have so far. In addition to the below we have confirmed that only members of the milk-donor-committers team can actually merge a pull request: currently this is Angela, Ben, and Zeljko. Let me know if others want to be included in this group.

 

Here are the resources that Angela, Ry and Tracy have sent out (Many Thanks!):

The link to the github docs that outlines and explains how to create a pull request to add files from a fork

https://help.github.com/articles/creating-a-pull-request-from-a-fork/

Making your first pull request in Hyperledger: https://www.youtube.com/watch?v=f5XZe7dv0_U

Here are a couple of more resources that may help:

Gist on Contributing - Tracy made this for the Training and Education WG, but if you change out https://github.com/hyperledger/education and references to local education repository, the general ideas should apply to the Milk Donor lab.

git Workflow Presentation - a presentation that is basically identical to the above Gist.

Tracy uses this workflow to sync her local fork - https://help.github.com/articles/syncing-a-fork/. There should probably be a step #6 which is a `git push` command to push the merged changes back to the local fork

Update on MPV UI Workflow

 

I know this is far from what the person creating the UI will need, but I tried to breakdown the high- level flow by actors and then whether or not the system was engaged at each step. This can be found in Section 2 of the Wiki in a PPT: happy_path_mpv_flow_for_donor_milk.pptx

 

Several questions came up for me while working on this, especially around when the donor milk application was going to be used on a computer vs a handheld for scanning, and how scanning would actually work in the laboratory setting. I'd like to get feedback and then take this to our SMEs for input. Thoughts?

We could use the Bar Code or QRCode NodeJS libraries for scanning the assets for the apps. Just a thought.

 

Kind regards.

Zeljko Milinovic, MSc

http://itstuffallaround.blogspot.com/


Am So., 30. Sep. 2018 um 04:06 Uhr schrieb Marissa Iannarone <mari.iannarone@...>:
Hello Everyone!

We had a great meeting on Friday, and thanks to Ben for showing us what has been built in the network so far. We will have full notes posted shortly, but I wanted to respond to a couple of questions that Zeljko and Ben posed below, offer a few resources on how to engage with the repo, and give an update on the UI MVP userflow. If you have any questions, please let me know.

Responses to Zeljko and Ben's Questions

1 .We could make inside the WIKI page some Collaboration, or maybe would be great if we could rent some JIRA Spaces for developing the project further.
 => Agreed, a board would be convenient to organize ourselves and help prioritize what is a P0 feature versus nice to haves. @all, do we already have a board tool available?
I have made a request with Hyperledger Help Desk to get us a JIRA workspace where we can organize ourselves. We confirmed that logging into this tool will be via Linux Foundation ID, so it will ensure equal access to everyone on the projects. TBD on when we get this, but I will keep everyone posted. Friday we had discussed using the donor milk wiki as a placeholder for requirements and stories (see Section 2). @Mikhail Elias  you had mentioned wanting to use this as a test case for some wiki work, so let me know how I can help
2. We could use Mocha and Cucumber for testing the model before deploying
 => I've never used Cucumber but if we have time to write some proper unit tests before the deadline then yes, we should. I'll try to include some proper user stories we can turn into tests sometime next week.
My knowledge is very limited here, but I'm assuming we're talking about setting up a test network? In speaking with Tracy, she reminded me that all Fabric nodes do not have to be in the same cloud server, so I have reached out to the #fabric Rocket.Chat channel to seek advice here. While Zeljko's offer is generous to stand up a VPS for the group, it is not ideal. If this is not what you're referring to here, my comments are still relevant, just not for this topic :-).
3. We should check the Child-Parent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships
 => I'm using a tree based structure where every change of state (split/pooling) triggers the creation of a new asset ID. This isn't quite the same as RR (you can revert back into the original asset ID) but with every node being linked to both parent and child this allows for complete traceability.
No comment
4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset
=> This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions.
Yes, if people want to start logging issues in GitHub now (as we wait for JIRA), please feel free to do so in the Issues Tab of the repo. I've created a "test issue" on this
5. Some Documentation and Model Planning would be great to have.
 => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute.
Yay, documentation!

@Benjamin Djidi - are we still looking for someone to engage on the access permissions work? Markus CC'd here had mentioned he had some resources to lend, so we can pursue that if needed. Also, would it be helpful to speak to the Identity Working Group on this? They have offered to come and talk to the HCWG, so was wondering if this would be along the same vein or not.

Recommended approach for working with the Donor Milk code repository

I'd love for someone to write up a quick best practices for engaging with the milk-donor repo code. I'm not the best person to do it. Anyone interested?

Below are all of the resources we have so far. In addition to the below we have confirmed that only members of the milk-donor-committers team can actually merge a pull request: currently this is Angela, Ben, and Zeljko. Let me know if others want to be included in this group.

Here are the resources that Angela, Ry and Tracy have sent out (Many Thanks!):
Update on MPV UI Workflow

I know this is far from what the person creating the UI will need, but I tried to breakdown the high- level flow by actors and then whether or not the system was engaged at each step. This can be found in Section 2 of the Wiki in a PPT: happy_path_mpv_flow_for_donor_milk.pptx

Several questions came up for me while working on this, especially around when the donor milk application was going to be used on a computer vs a handheld for scanning, and how scanning would actually work in the laboratory setting. I'd like to get feedback and then take this to our SMEs for input. Thoughts?

Best,
M

Marissa Iannarone
Associate with Forum Solutions LLC
phone number: +01 (360) 525 4961
email: mari.iannarone@...



On Sat, Sep 29, 2018 at 5:17 PM Benjamin Djidi <benjamin.djidi@...> wrote:
Hi Zeljko,

Thanks for checking and sorry for the delay in answering. To your points:

1 .We could make inside the WIKI page some Collaboration, or maybe would be great if we could rent some JIRA Spaces for developing the project further.
 => Agreed, a board would be convenient to organize ourselves and helo prioritize what is a P0 feature versus nice to haves. @all, do we already have a board tool available?
2. We could use Mocha and Cucumber for testing the model before deploying
 => I've never used Cucumber but if we have time to write some proper unit tests before the deadline then yes, we should. I'll try to include some proper user stories we can turn into tests sometime next week.
3. We should check the Child-Parent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships
 => I'm using a tree based structure where every change of state (split/pooling) triggers the creation of a new asset ID. This isn't quite the same as RR (you can revert back into the original asset ID) but with every node being linked to both parent and child this allows for complete traceability.
4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset
=> This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions.
5. Some Documentation and Model Planning would be great to have.
 => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute.

Thanks,

Ben.

On Wed, Sep 26, 2018 at 9:01 AM Zeljko Milinovic <zeljko.milgrz@...> wrote:
Hi, 

I have seen the .CTO File from Ben. 

@Benjamin - nice work with the assets and the Model.

I have maybe some suggestions. 

1 .We could make inside the WIKI page some Collaboration , or maybe would be great if we could rent some JIRA Spaces for developing the project further.
2. We could use Mocha and Cucumber for testing the model before deploying
3. We should check the Child-Parrent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships
4. Maybe we could discusss topics in JIRA about the Owner Status of the milkAsset Asset
5. Some Documentation and Model Planing would be great to have.

I can offer my Jira skills and also Project Management skills within the Scope of this Project.

Kind Regards.

Zeljko Milinovic, MSc
Certified Blockchain Architect
Austria, Graz

Rich Bloch <richardbloch@...> schrieb am Mi., 26. Sep. 2018, 17:19:
Good Morning Ry,

Understood. True that ACL management is not particularly mature in Github. And as you point out, the implications can be sweeping.

It's too bad that we can't silo spinout projects of HL such as this to prevent this workflow limitation.

Appreciate the explanation... I suspected it was policy-related :/.

Thanks

Rich

Richard Bloch
Principal, Business Learning Incorporated
Systems & Software Engineering
Seattle, Washington USA
   206.588.6054 - work 
   425.417.8255- mobile 
    www.businesslearninginc.com


On Tue, Sep 25, 2018 at 10:15 PM Ry Jones <rjones@...> wrote:
Rich,
It boils down to the GitHub default workflow. You don’t need anyone’s say-so to fork a public (or private) repo - you might need someone’s say-so to create a branch in a repo you don’t own.

There are further difficulties around this. GitHub’s ACL management leaves a lot to be desired - permissions I wish I could delegate are part of the Owner or Admin role; giving someone these roles grants very broad permissions, up to and including deleting the entire org.

The Linux Foundation position, pre-Hyperledger, was everyone needs to use Gerrit. In fact, some projects in Hyperledger are using Gerrit right now. Gerrit is not all sunshine and rainbows, though.

I personally find Gerrit more amenable, but GitHub has won the field.
Ry

On Tue, Sep 25, 2018 at 17:10 Rich Bloch <richardbloch@...> wrote:
Good Afternoon,

Out of curiosity (perhaps this is HL policy), why generate so many forks instead of just creating separate branches? I'd think that, unless the forks lead to substantially different endpoints, it'd likely be easier to manage the branches (branching and merging is key when you have many devs working collaboratively). Again, not criticizing... just curious (and a learning opportunity for me).

Rich
--
Ry Jones
Community Architect, Hyperledger
Chat: @ry

--

Benjamin Djidi

Sr. BIE, Amazon International Expansion
Former Founding Partner, Revstr
President Emeritus, IESEG International Club

+33 762 001 145


Rich Bloch
 

Good Afternoon Zeljko,

I see that you're bringing this issue up on both the #Fabric and #Composer channels, which is the right thing to do.

On those channels, it seems that there's really no coherent "go forward" strategy in place... yet.

For me, it'd depend more on the shorter term, and where the team devs' interests lay. As an example, I'm not a particular fan of JS/ECMAScript, but would prefer TypeScript over both. That said, I'd opt for GoLang over TS. Again, this is really a personal thing.

I'd be interested to get some insight from Ry and others on this listserv who may have an ear to the ground on this topic ;).

Rich

Richard Bloch
Principal, Business Learning Incorporated
Systems & Software Engineering
Seattle, Washington USA
   206.588.6054 - work 
   425.417.8255- mobile 
    www.businesslearninginc.com


On Mon, Oct 1, 2018 at 2:17 PM Zeljko Milinovic <zeljko.milgrz@...> wrote:
Hi,

Yes I have seen the Convector.
But the question is, is it under Hyperledger Umbrella. Will it be supported native in the future. 
Is it better to use an Nodejs shim alternative?

Kr 

Zeljko Milinovic 


Richard Bloch <richardbloch@...> schrieb am Mo., 1. Okt. 2018, 22:58:
Good Afternoon All,

This issue came up in our Hyperledger Seattle Meetup discussion on Slack recently. 

Convector seems to be one option, but here's a good article to consider: https://hackernoon.com/hyperledger-composer-has-been-put-on-pause-what-are-your-options-now-dfc3a97a6308.

Rich

Richard Bloch
Principal, Business Learning Incorporated
Systems & Software Engineering
Seattle, Washington USA
   206.588.6054 - work 
   425.417.8255- mobile 
    www.businesslearninginc.com


On Mon, Oct 1, 2018 at 1:03 PM Zeljko Milinovic <zeljko.milgrz@...> wrote:
Hi to all,

I just came upon an article:


It seems so that IBM folks will no longer invest so much in Composer.

My question to all of you and especially to Ben, what are our alternatives?

Could we still use Javascript or we have to remodel and reprogram everything in Go language?

Kind Regards.

Zeljko Milinovic

Zeljko Milinovic <zeljko.milgrz@...> schrieb am So., 30. Sep. 2018, 09:22:

Hi Marissa,

Thanks for the great Email. I added my suggestions in bolded text.

____________________


Responses to Zeljko and Ben's Questions

 

1 .We could make inside the WIKI page some Collaboration, or maybe would be great if we could rent some JIRA Spaces for developing the project further.

 => Agreed, a board would be convenient to organize ourselves and help prioritize what is a P0 feature versus nice to haves. @all, do we already have a board tool available?

I have made a request with Hyperledger Help Desk to get us a JIRA workspace where we can organize ourselves. We confirmed that logging into this tool will be via Linux Foundation ID, so it will ensure equal access to everyone on the projects. TBD on when we get this, but I will keep everyone posted. Friday we had discussed using the donor milk wiki as a placeholder for requirements and stories (see Section 2). @Mikhail Elias  you had mentioned wanting to use this as a test case for some wiki work, so let me know how I can help

Thanks Marissa. I think to make further great progress with the PoC the JIRA workspace is of a great esence to the project, as I mentioned already. Team cannot continue to be agile without this tool. Wiki is ok and we can collaborate here, but the project needs more for the troubleshootings and builds.

2. We could use Mocha and Cucumber for testing the model before deploying

 => I've never used Cucumber but if we have time to write some proper unit tests before the deadline then yes, we should. I'll try to include some proper user stories we can turn into tests sometime next week.

Ben has built a great .CTO model that I have reviewed and commented. I have learned a lot from his model, great work Ben. As fort he Mocha and Cucumber, we can use these tools to test the model before we get into further application development. Those are great frameworks for testing the model assuming that we will have a lot of data on the chain and to simulate those situations.

My knowledge is very limited here, but I'm assuming we're talking about setting up a test network? In speaking with Tracy, she reminded me that all Fabric nodes do not have to be in the same cloud server, so I have reached out to the #fabric Rocket.Chat channel to seek advice here. While Zeljko's offer is generous to stand up a VPS for the group, it is not ideal. If this is not what you're referring to here, my comments are still relevant, just not for this topic :-).

As fort he VPS instance, maybe we could get on from the Linux Foundation. I offered help here and also talked to Ben about this. This is also very important, because when we start to build the WEB and MOBILE APPs , we would need a living REST Server and also to achieve UNIT Testing without a living VPS instance will not be possible.

3. We should check the Child-Parent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships

 => I'm using a tree based structure where every change of state (split/pooling) triggers the creation of a new asset ID. This isn't quite the same as RR (you can revert back into the original asset ID) but with every node being linked to both parent and child this allows for complete traceability.

No comment

As for the relationships, tree based what Ben did is great, but I think when we test this model with simulating a lot of data with Mocha or Cucumber, we could come up on performance issues with the Mobile app, becuase every change of state creates a new Asset ID, an I was thinking with RR we have a unique ID for one asset from the beginning of the life cycle. But this is something to be tested in the future with Ben. May be that I am also wrong here, cannot really tell before I test the Model on a live network VPS.

4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset

 => This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions.

Yes, if people want to start logging issues in GitHub now (as we wait for JIRA), please feel free to do so in the Issues Tab of the repo. I've created a "test issue" on this

5. Some Documentation and Model Planning would be great to have.

 => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute.

Yay, documentation!

 

@Benjamin Djidi - are we still looking for someone to engage on the access permissions work? Markus CC'd here had mentioned he had some resources to lend, so we can pursue that if needed. Also, would it be helpful to speak to the Identity Working Group on this? They have offered to come and talk to the HCWG, so was wondering if this would be along the same vein or not.

As for the relationships, this should not be a great issue. It needs to be defined (from the Use Case and the processess that are now in use) which participants need to access what and it can be coded pretty fast.

Recommended approach for working with the Donor Milk code repository

 

I'd love for someone to write up a quick best practices for engaging with the milk-donor repo code. I'm not the best person to do it. Anyone interested?

 

Below are all of the resources we have so far. In addition to the below we have confirmed that only members of the milk-donor-committers team can actually merge a pull request: currently this is Angela, Ben, and Zeljko. Let me know if others want to be included in this group.

 

Here are the resources that Angela, Ry and Tracy have sent out (Many Thanks!):

The link to the github docs that outlines and explains how to create a pull request to add files from a fork

https://help.github.com/articles/creating-a-pull-request-from-a-fork/

Making your first pull request in Hyperledger: https://www.youtube.com/watch?v=f5XZe7dv0_U

Here are a couple of more resources that may help:

Gist on Contributing - Tracy made this for the Training and Education WG, but if you change out https://github.com/hyperledger/education and references to local education repository, the general ideas should apply to the Milk Donor lab.

git Workflow Presentation - a presentation that is basically identical to the above Gist.

Tracy uses this workflow to sync her local fork - https://help.github.com/articles/syncing-a-fork/. There should probably be a step #6 which is a `git push` command to push the merged changes back to the local fork

Update on MPV UI Workflow

 

I know this is far from what the person creating the UI will need, but I tried to breakdown the high- level flow by actors and then whether or not the system was engaged at each step. This can be found in Section 2 of the Wiki in a PPT: happy_path_mpv_flow_for_donor_milk.pptx

 

Several questions came up for me while working on this, especially around when the donor milk application was going to be used on a computer vs a handheld for scanning, and how scanning would actually work in the laboratory setting. I'd like to get feedback and then take this to our SMEs for input. Thoughts?

We could use the Bar Code or QRCode NodeJS libraries for scanning the assets for the apps. Just a thought.

 

Kind regards.

Zeljko Milinovic, MSc

http://itstuffallaround.blogspot.com/


Am So., 30. Sep. 2018 um 04:06 Uhr schrieb Marissa Iannarone <mari.iannarone@...>:
Hello Everyone!

We had a great meeting on Friday, and thanks to Ben for showing us what has been built in the network so far. We will have full notes posted shortly, but I wanted to respond to a couple of questions that Zeljko and Ben posed below, offer a few resources on how to engage with the repo, and give an update on the UI MVP userflow. If you have any questions, please let me know.

Responses to Zeljko and Ben's Questions

1 .We could make inside the WIKI page some Collaboration, or maybe would be great if we could rent some JIRA Spaces for developing the project further.
 => Agreed, a board would be convenient to organize ourselves and help prioritize what is a P0 feature versus nice to haves. @all, do we already have a board tool available?
I have made a request with Hyperledger Help Desk to get us a JIRA workspace where we can organize ourselves. We confirmed that logging into this tool will be via Linux Foundation ID, so it will ensure equal access to everyone on the projects. TBD on when we get this, but I will keep everyone posted. Friday we had discussed using the donor milk wiki as a placeholder for requirements and stories (see Section 2). @Mikhail Elias  you had mentioned wanting to use this as a test case for some wiki work, so let me know how I can help
2. We could use Mocha and Cucumber for testing the model before deploying
 => I've never used Cucumber but if we have time to write some proper unit tests before the deadline then yes, we should. I'll try to include some proper user stories we can turn into tests sometime next week.
My knowledge is very limited here, but I'm assuming we're talking about setting up a test network? In speaking with Tracy, she reminded me that all Fabric nodes do not have to be in the same cloud server, so I have reached out to the #fabric Rocket.Chat channel to seek advice here. While Zeljko's offer is generous to stand up a VPS for the group, it is not ideal. If this is not what you're referring to here, my comments are still relevant, just not for this topic :-).
3. We should check the Child-Parent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships
 => I'm using a tree based structure where every change of state (split/pooling) triggers the creation of a new asset ID. This isn't quite the same as RR (you can revert back into the original asset ID) but with every node being linked to both parent and child this allows for complete traceability.
No comment
4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset
=> This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions.
Yes, if people want to start logging issues in GitHub now (as we wait for JIRA), please feel free to do so in the Issues Tab of the repo. I've created a "test issue" on this
5. Some Documentation and Model Planning would be great to have.
 => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute.
Yay, documentation!

@Benjamin Djidi - are we still looking for someone to engage on the access permissions work? Markus CC'd here had mentioned he had some resources to lend, so we can pursue that if needed. Also, would it be helpful to speak to the Identity Working Group on this? They have offered to come and talk to the HCWG, so was wondering if this would be along the same vein or not.

Recommended approach for working with the Donor Milk code repository

I'd love for someone to write up a quick best practices for engaging with the milk-donor repo code. I'm not the best person to do it. Anyone interested?

Below are all of the resources we have so far. In addition to the below we have confirmed that only members of the milk-donor-committers team can actually merge a pull request: currently this is Angela, Ben, and Zeljko. Let me know if others want to be included in this group.

Here are the resources that Angela, Ry and Tracy have sent out (Many Thanks!):
Update on MPV UI Workflow

I know this is far from what the person creating the UI will need, but I tried to breakdown the high- level flow by actors and then whether or not the system was engaged at each step. This can be found in Section 2 of the Wiki in a PPT: happy_path_mpv_flow_for_donor_milk.pptx

Several questions came up for me while working on this, especially around when the donor milk application was going to be used on a computer vs a handheld for scanning, and how scanning would actually work in the laboratory setting. I'd like to get feedback and then take this to our SMEs for input. Thoughts?

Best,
M

Marissa Iannarone
Associate with Forum Solutions LLC
phone number: +01 (360) 525 4961
email: mari.iannarone@...



On Sat, Sep 29, 2018 at 5:17 PM Benjamin Djidi <benjamin.djidi@...> wrote:
Hi Zeljko,

Thanks for checking and sorry for the delay in answering. To your points:

1 .We could make inside the WIKI page some Collaboration, or maybe would be great if we could rent some JIRA Spaces for developing the project further.
 => Agreed, a board would be convenient to organize ourselves and helo prioritize what is a P0 feature versus nice to haves. @all, do we already have a board tool available?
2. We could use Mocha and Cucumber for testing the model before deploying
 => I've never used Cucumber but if we have time to write some proper unit tests before the deadline then yes, we should. I'll try to include some proper user stories we can turn into tests sometime next week.
3. We should check the Child-Parent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships
 => I'm using a tree based structure where every change of state (split/pooling) triggers the creation of a new asset ID. This isn't quite the same as RR (you can revert back into the original asset ID) but with every node being linked to both parent and child this allows for complete traceability.
4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset
=> This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions.
5. Some Documentation and Model Planning would be great to have.
 => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute.

Thanks,

Ben.

On Wed, Sep 26, 2018 at 9:01 AM Zeljko Milinovic <zeljko.milgrz@...> wrote:
Hi, 

I have seen the .CTO File from Ben. 

@Benjamin - nice work with the assets and the Model.

I have maybe some suggestions. 

1 .We could make inside the WIKI page some Collaboration , or maybe would be great if we could rent some JIRA Spaces for developing the project further.
2. We could use Mocha and Cucumber for testing the model before deploying
3. We should check the Child-Parrent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships
4. Maybe we could discusss topics in JIRA about the Owner Status of the milkAsset Asset
5. Some Documentation and Model Planing would be great to have.

I can offer my Jira skills and also Project Management skills within the Scope of this Project.

Kind Regards.

Zeljko Milinovic, MSc
Certified Blockchain Architect
Austria, Graz

Rich Bloch <richardbloch@...> schrieb am Mi., 26. Sep. 2018, 17:19:
Good Morning Ry,

Understood. True that ACL management is not particularly mature in Github. And as you point out, the implications can be sweeping.

It's too bad that we can't silo spinout projects of HL such as this to prevent this workflow limitation.

Appreciate the explanation... I suspected it was policy-related :/.

Thanks

Rich

Richard Bloch
Principal, Business Learning Incorporated
Systems & Software Engineering
Seattle, Washington USA
   206.588.6054 - work 
   425.417.8255- mobile 
    www.businesslearninginc.com


On Tue, Sep 25, 2018 at 10:15 PM Ry Jones <rjones@...> wrote:
Rich,
It boils down to the GitHub default workflow. You don’t need anyone’s say-so to fork a public (or private) repo - you might need someone’s say-so to create a branch in a repo you don’t own.

There are further difficulties around this. GitHub’s ACL management leaves a lot to be desired - permissions I wish I could delegate are part of the Owner or Admin role; giving someone these roles grants very broad permissions, up to and including deleting the entire org.

The Linux Foundation position, pre-Hyperledger, was everyone needs to use Gerrit. In fact, some projects in Hyperledger are using Gerrit right now. Gerrit is not all sunshine and rainbows, though.

I personally find Gerrit more amenable, but GitHub has won the field.
Ry

On Tue, Sep 25, 2018 at 17:10 Rich Bloch <richardbloch@...> wrote:
Good Afternoon,

Out of curiosity (perhaps this is HL policy), why generate so many forks instead of just creating separate branches? I'd think that, unless the forks lead to substantially different endpoints, it'd likely be easier to manage the branches (branching and merging is key when you have many devs working collaboratively). Again, not criticizing... just curious (and a learning opportunity for me).

Rich
--
Ry Jones
Community Architect, Hyperledger
Chat: @ry

--

Benjamin Djidi

Sr. BIE, Amazon International Expansion
Former Founding Partner, Revstr
President Emeritus, IESEG International Club

+33 762 001 145


Benjamin Djidi <benjamin.djidi@...>
 

Hi all,

Thanks for the article Rich. As it greatly underlines, you have two options: Go or Node. It seems that a lot of the examples are now being written in go (see the marble contracts) but Node is very popular and I imagine more helpers will start popping up (I'm yet to play with convector). That being said, both the chat and doc seem to go the Go way (pun intended). Would be great to have contributors weight in.

Cheers,

Ben.


On Mon, Oct 1, 2018 at 2:43 PM Richard Bloch <richardbloch@...> wrote:
Good Afternoon Zeljko,

I see that you're bringing this issue up on both the #Fabric and #Composer channels, which is the right thing to do.

On those channels, it seems that there's really no coherent "go forward" strategy in place... yet.

For me, it'd depend more on the shorter term, and where the team devs' interests lay. As an example, I'm not a particular fan of JS/ECMAScript, but would prefer TypeScript over both. That said, I'd opt for GoLang over TS. Again, this is really a personal thing.

I'd be interested to get some insight from Ry and others on this listserv who may have an ear to the ground on this topic ;).

Rich

Richard Bloch
Principal, Business Learning Incorporated
Systems & Software Engineering
Seattle, Washington USA
   206.588.6054 - work 
   425.417.8255- mobile 
    www.businesslearninginc.com


On Mon, Oct 1, 2018 at 2:17 PM Zeljko Milinovic <zeljko.milgrz@...> wrote:
Hi,

Yes I have seen the Convector.
But the question is, is it under Hyperledger Umbrella. Will it be supported native in the future. 
Is it better to use an Nodejs shim alternative?

Kr 

Zeljko Milinovic 


Richard Bloch <richardbloch@...> schrieb am Mo., 1. Okt. 2018, 22:58:
Good Afternoon All,

This issue came up in our Hyperledger Seattle Meetup discussion on Slack recently. 

Convector seems to be one option, but here's a good article to consider: https://hackernoon.com/hyperledger-composer-has-been-put-on-pause-what-are-your-options-now-dfc3a97a6308.

Rich

Richard Bloch
Principal, Business Learning Incorporated
Systems & Software Engineering
Seattle, Washington USA
   206.588.6054 - work 
   425.417.8255- mobile 
    www.businesslearninginc.com


On Mon, Oct 1, 2018 at 1:03 PM Zeljko Milinovic <zeljko.milgrz@...> wrote:
Hi to all,

I just came upon an article:


It seems so that IBM folks will no longer invest so much in Composer.

My question to all of you and especially to Ben, what are our alternatives?

Could we still use Javascript or we have to remodel and reprogram everything in Go language?

Kind Regards.

Zeljko Milinovic

Zeljko Milinovic <zeljko.milgrz@...> schrieb am So., 30. Sep. 2018, 09:22:

Hi Marissa,

Thanks for the great Email. I added my suggestions in bolded text.

____________________


Responses to Zeljko and Ben's Questions

 

1 .We could make inside the WIKI page some Collaboration, or maybe would be great if we could rent some JIRA Spaces for developing the project further.

 => Agreed, a board would be convenient to organize ourselves and help prioritize what is a P0 feature versus nice to haves. @all, do we already have a board tool available?

I have made a request with Hyperledger Help Desk to get us a JIRA workspace where we can organize ourselves. We confirmed that logging into this tool will be via Linux Foundation ID, so it will ensure equal access to everyone on the projects. TBD on when we get this, but I will keep everyone posted. Friday we had discussed using the donor milk wiki as a placeholder for requirements and stories (see Section 2). @Mikhail Elias  you had mentioned wanting to use this as a test case for some wiki work, so let me know how I can help

Thanks Marissa. I think to make further great progress with the PoC the JIRA workspace is of a great esence to the project, as I mentioned already. Team cannot continue to be agile without this tool. Wiki is ok and we can collaborate here, but the project needs more for the troubleshootings and builds.

2. We could use Mocha and Cucumber for testing the model before deploying

 => I've never used Cucumber but if we have time to write some proper unit tests before the deadline then yes, we should. I'll try to include some proper user stories we can turn into tests sometime next week.

Ben has built a great .CTO model that I have reviewed and commented. I have learned a lot from his model, great work Ben. As fort he Mocha and Cucumber, we can use these tools to test the model before we get into further application development. Those are great frameworks for testing the model assuming that we will have a lot of data on the chain and to simulate those situations.

My knowledge is very limited here, but I'm assuming we're talking about setting up a test network? In speaking with Tracy, she reminded me that all Fabric nodes do not have to be in the same cloud server, so I have reached out to the #fabric Rocket.Chat channel to seek advice here. While Zeljko's offer is generous to stand up a VPS for the group, it is not ideal. If this is not what you're referring to here, my comments are still relevant, just not for this topic :-).

As fort he VPS instance, maybe we could get on from the Linux Foundation. I offered help here and also talked to Ben about this. This is also very important, because when we start to build the WEB and MOBILE APPs , we would need a living REST Server and also to achieve UNIT Testing without a living VPS instance will not be possible.

3. We should check the Child-Parent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships

 => I'm using a tree based structure where every change of state (split/pooling) triggers the creation of a new asset ID. This isn't quite the same as RR (you can revert back into the original asset ID) but with every node being linked to both parent and child this allows for complete traceability.

No comment

As for the relationships, tree based what Ben did is great, but I think when we test this model with simulating a lot of data with Mocha or Cucumber, we could come up on performance issues with the Mobile app, becuase every change of state creates a new Asset ID, an I was thinking with RR we have a unique ID for one asset from the beginning of the life cycle. But this is something to be tested in the future with Ben. May be that I am also wrong here, cannot really tell before I test the Model on a live network VPS.

4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset

 => This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions.

Yes, if people want to start logging issues in GitHub now (as we wait for JIRA), please feel free to do so in the Issues Tab of the repo. I've created a "test issue" on this

5. Some Documentation and Model Planning would be great to have.

 => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute.

Yay, documentation!

 

@Benjamin Djidi - are we still looking for someone to engage on the access permissions work? Markus CC'd here had mentioned he had some resources to lend, so we can pursue that if needed. Also, would it be helpful to speak to the Identity Working Group on this? They have offered to come and talk to the HCWG, so was wondering if this would be along the same vein or not.

As for the relationships, this should not be a great issue. It needs to be defined (from the Use Case and the processess that are now in use) which participants need to access what and it can be coded pretty fast.

Recommended approach for working with the Donor Milk code repository

 

I'd love for someone to write up a quick best practices for engaging with the milk-donor repo code. I'm not the best person to do it. Anyone interested?

 

Below are all of the resources we have so far. In addition to the below we have confirmed that only members of the milk-donor-committers team can actually merge a pull request: currently this is Angela, Ben, and Zeljko. Let me know if others want to be included in this group.

 

Here are the resources that Angela, Ry and Tracy have sent out (Many Thanks!):

The link to the github docs that outlines and explains how to create a pull request to add files from a fork

https://help.github.com/articles/creating-a-pull-request-from-a-fork/

Making your first pull request in Hyperledger: https://www.youtube.com/watch?v=f5XZe7dv0_U

Here are a couple of more resources that may help:

Gist on Contributing - Tracy made this for the Training and Education WG, but if you change out https://github.com/hyperledger/education and references to local education repository, the general ideas should apply to the Milk Donor lab.

git Workflow Presentation - a presentation that is basically identical to the above Gist.

Tracy uses this workflow to sync her local fork - https://help.github.com/articles/syncing-a-fork/. There should probably be a step #6 which is a `git push` command to push the merged changes back to the local fork

Update on MPV UI Workflow

 

I know this is far from what the person creating the UI will need, but I tried to breakdown the high- level flow by actors and then whether or not the system was engaged at each step. This can be found in Section 2 of the Wiki in a PPT: happy_path_mpv_flow_for_donor_milk.pptx

 

Several questions came up for me while working on this, especially around when the donor milk application was going to be used on a computer vs a handheld for scanning, and how scanning would actually work in the laboratory setting. I'd like to get feedback and then take this to our SMEs for input. Thoughts?

We could use the Bar Code or QRCode NodeJS libraries for scanning the assets for the apps. Just a thought.

 

Kind regards.

Zeljko Milinovic, MSc

http://itstuffallaround.blogspot.com/


Am So., 30. Sep. 2018 um 04:06 Uhr schrieb Marissa Iannarone <mari.iannarone@...>:
Hello Everyone!

We had a great meeting on Friday, and thanks to Ben for showing us what has been built in the network so far. We will have full notes posted shortly, but I wanted to respond to a couple of questions that Zeljko and Ben posed below, offer a few resources on how to engage with the repo, and give an update on the UI MVP userflow. If you have any questions, please let me know.

Responses to Zeljko and Ben's Questions

1 .We could make inside the WIKI page some Collaboration, or maybe would be great if we could rent some JIRA Spaces for developing the project further.
 => Agreed, a board would be convenient to organize ourselves and help prioritize what is a P0 feature versus nice to haves. @all, do we already have a board tool available?
I have made a request with Hyperledger Help Desk to get us a JIRA workspace where we can organize ourselves. We confirmed that logging into this tool will be via Linux Foundation ID, so it will ensure equal access to everyone on the projects. TBD on when we get this, but I will keep everyone posted. Friday we had discussed using the donor milk wiki as a placeholder for requirements and stories (see Section 2). @Mikhail Elias  you had mentioned wanting to use this as a test case for some wiki work, so let me know how I can help
2. We could use Mocha and Cucumber for testing the model before deploying
 => I've never used Cucumber but if we have time to write some proper unit tests before the deadline then yes, we should. I'll try to include some proper user stories we can turn into tests sometime next week.
My knowledge is very limited here, but I'm assuming we're talking about setting up a test network? In speaking with Tracy, she reminded me that all Fabric nodes do not have to be in the same cloud server, so I have reached out to the #fabric Rocket.Chat channel to seek advice here. While Zeljko's offer is generous to stand up a VPS for the group, it is not ideal. If this is not what you're referring to here, my comments are still relevant, just not for this topic :-).
3. We should check the Child-Parent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships
 => I'm using a tree based structure where every change of state (split/pooling) triggers the creation of a new asset ID. This isn't quite the same as RR (you can revert back into the original asset ID) but with every node being linked to both parent and child this allows for complete traceability.
No comment
4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset
=> This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions.
Yes, if people want to start logging issues in GitHub now (as we wait for JIRA), please feel free to do so in the Issues Tab of the repo. I've created a "test issue" on this
5. Some Documentation and Model Planning would be great to have.
 => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute.
Yay, documentation!

@Benjamin Djidi - are we still looking for someone to engage on the access permissions work? Markus CC'd here had mentioned he had some resources to lend, so we can pursue that if needed. Also, would it be helpful to speak to the Identity Working Group on this? They have offered to come and talk to the HCWG, so was wondering if this would be along the same vein or not.

Recommended approach for working with the Donor Milk code repository

I'd love for someone to write up a quick best practices for engaging with the milk-donor repo code. I'm not the best person to do it. Anyone interested?

Below are all of the resources we have so far. In addition to the below we have confirmed that only members of the milk-donor-committers team can actually merge a pull request: currently this is Angela, Ben, and Zeljko. Let me know if others want to be included in this group.

Here are the resources that Angela, Ry and Tracy have sent out (Many Thanks!):
Update on MPV UI Workflow

I know this is far from what the person creating the UI will need, but I tried to breakdown the high- level flow by actors and then whether or not the system was engaged at each step. This can be found in Section 2 of the Wiki in a PPT: happy_path_mpv_flow_for_donor_milk.pptx

Several questions came up for me while working on this, especially around when the donor milk application was going to be used on a computer vs a handheld for scanning, and how scanning would actually work in the laboratory setting. I'd like to get feedback and then take this to our SMEs for input. Thoughts?

Best,
M

Marissa Iannarone
Associate with Forum Solutions LLC
phone number: +01 (360) 525 4961
email: mari.iannarone@...



On Sat, Sep 29, 2018 at 5:17 PM Benjamin Djidi <benjamin.djidi@...> wrote:
Hi Zeljko,

Thanks for checking and sorry for the delay in answering. To your points:

1 .We could make inside the WIKI page some Collaboration, or maybe would be great if we could rent some JIRA Spaces for developing the project further.
 => Agreed, a board would be convenient to organize ourselves and helo prioritize what is a P0 feature versus nice to haves. @all, do we already have a board tool available?
2. We could use Mocha and Cucumber for testing the model before deploying
 => I've never used Cucumber but if we have time to write some proper unit tests before the deadline then yes, we should. I'll try to include some proper user stories we can turn into tests sometime next week.
3. We should check the Child-Parent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships
 => I'm using a tree based structure where every change of state (split/pooling) triggers the creation of a new asset ID. This isn't quite the same as RR (you can revert back into the original asset ID) but with every node being linked to both parent and child this allows for complete traceability.
4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset
=> This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions.
5. Some Documentation and Model Planning would be great to have.
 => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute.

Thanks,

Ben.

On Wed, Sep 26, 2018 at 9:01 AM Zeljko Milinovic <zeljko.milgrz@...> wrote:
Hi, 

I have seen the .CTO File from Ben. 

@Benjamin - nice work with the assets and the Model.

I have maybe some suggestions. 

1 .We could make inside the WIKI page some Collaboration , or maybe would be great if we could rent some JIRA Spaces for developing the project further.
2. We could use Mocha and Cucumber for testing the model before deploying
3. We should check the Child-Parrent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships
4. Maybe we could discusss topics in JIRA about the Owner Status of the milkAsset Asset
5. Some Documentation and Model Planing would be great to have.

I can offer my Jira skills and also Project Management skills within the Scope of this Project.

Kind Regards.

Zeljko Milinovic, MSc
Certified Blockchain Architect
Austria, Graz

Rich Bloch <richardbloch@...> schrieb am Mi., 26. Sep. 2018, 17:19:
Good Morning Ry,

Understood. True that ACL management is not particularly mature in Github. And as you point out, the implications can be sweeping.

It's too bad that we can't silo spinout projects of HL such as this to prevent this workflow limitation.

Appreciate the explanation... I suspected it was policy-related :/.

Thanks

Rich

Richard Bloch
Principal, Business Learning Incorporated
Systems & Software Engineering
Seattle, Washington USA
   206.588.6054 - work 
   425.417.8255- mobile 
    www.businesslearninginc.com


On Tue, Sep 25, 2018 at 10:15 PM Ry Jones <rjones@...> wrote:
Rich,
It boils down to the GitHub default workflow. You don’t need anyone’s say-so to fork a public (or private) repo - you might need someone’s say-so to create a branch in a repo you don’t own.

There are further difficulties around this. GitHub’s ACL management leaves a lot to be desired - permissions I wish I could delegate are part of the Owner or Admin role; giving someone these roles grants very broad permissions, up to and including deleting the entire org.

The Linux Foundation position, pre-Hyperledger, was everyone needs to use Gerrit. In fact, some projects in Hyperledger are using Gerrit right now. Gerrit is not all sunshine and rainbows, though.

I personally find Gerrit more amenable, but GitHub has won the field.
Ry

On Tue, Sep 25, 2018 at 17:10 Rich Bloch <richardbloch@...> wrote:
Good Afternoon,

Out of curiosity (perhaps this is HL policy), why generate so many forks instead of just creating separate branches? I'd think that, unless the forks lead to substantially different endpoints, it'd likely be easier to manage the branches (branching and merging is key when you have many devs working collaboratively). Again, not criticizing... just curious (and a learning opportunity for me).

Rich
--
Ry Jones
Community Architect, Hyperledger
Chat: @ry

--

Benjamin Djidi

Sr. BIE, Amazon International Expansion
Former Founding Partner, Revstr
President Emeritus, IESEG International Club

+33 762 001 145

--

Benjamin Djidi

Sr. BIE, Amazon International Expansion
Former Founding Partner, Revstr
President Emeritus, IESEG International Club

+33 762 001 145


ben.taylor@sophrosynecapital.com <ben.taylor@...>
 

Hi Ben,

We at LedgerDomain use Golang for everything including smart contracts and even wrote our own app server to replace and enhance node.js

It’s a substantial investment but the client experience and server performance is truly enhanced.

Feel free to reach out if you have any questions,
Ben 

On Oct 1, 2018, at 8:49 PM, Benjamin Djidi <benjamin.djidi@...> wrote:

Benjamin Djidi

Sr. BIE, Amazon International Expansion


Zeljko Milinovic <zeljko.milgrz@...>
 

Hi to both of the Bens :D

Thanks for the Input. 

Here are my opinions and questions.

Convecta approach could go out of support like composer in one year. I think it is a no go soluion.

As Ben D. stated there are two options Go or Node.

Go lang is for sure faster because it is native. I see also that the link for the shim documentation on GItHub for NodeJS Core ChainCode SDK is not working. I hope that the contributors will work to put more weight into NodeJS.

As for Go. I had some questions for the Ben T.
What are you using for modelling and defining the bussiness network (Assets, Pariticipants, Transactions), like we did in composer?

Any advice on how to approach the Architecture, Modelling and development Cycles would be really appreciated.

Kind regards.

Zeljko

Am Di., 2. Okt. 2018 um 03:07 Uhr schrieb Ben Taylor <ben.taylor@...>:

Hi Ben,

We at LedgerDomain use Golang for everything including smart contracts and even wrote our own app server to replace and enhance node.js

It’s a substantial investment but the client experience and server performance is truly enhanced.

Feel free to reach out if you have any questions,
Ben 

On Oct 1, 2018, at 8:49 PM, Benjamin Djidi <benjamin.djidi@...> wrote:

Benjamin Djidi

Sr. BIE, Amazon International Expansion


Mikhail Elias <hyperledger@...>
 

Another approach to consider would involve collaborating on modeling language development -- possibly within the context of the donor milk POC;  this currently seems to be where the IBM UK team seems to be most interested in allocating resources.

This collaboration could serve to bridge between future work on tools to support 'front-end' SDLC activities - domain analysis and requirements development - and 'back-end' development, testing, etc.

We could plan our upcoming transition to Confluence to support rapid prototyping and feedback of some of these analysis and modeling tools.


ben.taylor@sophrosynecapital.com <ben.taylor@...>
 

Zeljko,

We never used Composer at LedgerDomain so I’m not the best person to speak to that.  

Happy to chat directly if you have any questions, just shoot me an email at

Ben



On Oct 2, 2018, at 1:41 AM, Zeljko Milinovic <zeljko.milgrz@...> wrote:

Hi to both of the Bens :D

Thanks for the Input. 

Here are my opinions and questions.

Convecta approach could go out of support like composer in one year. I think it is a no go soluion.

As Ben D. stated there are two options Go or Node.

Go lang is for sure faster because it is native. I see also that the link for the shim documentation on GItHub for NodeJS Core ChainCode SDK is not working. I hope that the contributors will work to put more weight into NodeJS.

As for Go. I had some questions for the Ben T.
What are you using for modelling and defining the bussiness network (Assets, Pariticipants, Transactions), like we did in composer?

Any advice on how to approach the Architecture, Modelling and development Cycles would be really appreciated.

Kind regards.

Zeljko

Am Di., 2. Okt. 2018 um 03:07 Uhr schrieb Ben Taylor <ben.taylor@...>:
Hi Ben,

We at LedgerDomain use Golang for everything including smart contracts and even wrote our own app server to replace and enhance node.js

It’s a substantial investment but the client experience and server performance is truly enhanced.

Feel free to reach out if you have any questions,
Ben 

On Oct 1, 2018, at 8:49 PM, Benjamin Djidi <benjamin.djidi@...> wrote:

Benjamin Djidi

Sr. BIE, Amazon International Expansion


Varun Lashkari
 

I have worked with composer previously can I have a look at the bna file please? Please share me the link of repo.I will see what can be optimized. If someone has an EC2 instance to donate I can also make the bna live on restserver to store data on fabric network directly 😅 I hope that is useful for the community.


Mikhail Elias <hyperledger@...>
 

Please use the New Member Orientation wikipage to familiarize yourself with the project and to locate resources :
https://wiki.hyperledger.org/groups/healthcare/orientation

Feel free to edit and update the page with any information currently missing.


Zeljko Milinovic <zeljko.milgrz@...>
 

Hi Ben T.,

Thanks for the input. Yes I understood that you never used Composer at LedgerDomain. This is also a great approach.
I was thinking in the near future as soon as the PoC is over it will maybe need to go to production and this will not be possible with Composer.
So I wanted to change the mindset and to switch also future PoC-es to Go Lang.
That is why I wanted to ask for tips and insights on how to Model, Design a GoLang-Fabric PoC like we did with composer and .CTO Domain Language.
And also how to test the models on the beginning and also how to define Assets/Participants/Transactions like we did in Hyperledger Composer.

Any links or tips would be very appreciated.

Thanks in advance.

Kind regards.

Zeljko Milinovic, MSc

Am Di., 2. Okt. 2018 um 17:52 Uhr schrieb Ben Taylor <ben.taylor@...>:

Zeljko,

We never used Composer at LedgerDomain so I’m not the best person to speak to that.  

Happy to chat directly if you have any questions, just shoot me an email at

Ben



On Oct 2, 2018, at 1:41 AM, Zeljko Milinovic <zeljko.milgrz@...> wrote:

Hi to both of the Bens :D

Thanks for the Input. 

Here are my opinions and questions.

Convecta approach could go out of support like composer in one year. I think it is a no go soluion.

As Ben D. stated there are two options Go or Node.

Go lang is for sure faster because it is native. I see also that the link for the shim documentation on GItHub for NodeJS Core ChainCode SDK is not working. I hope that the contributors will work to put more weight into NodeJS.

As for Go. I had some questions for the Ben T.
What are you using for modelling and defining the bussiness network (Assets, Pariticipants, Transactions), like we did in composer?

Any advice on how to approach the Architecture, Modelling and development Cycles would be really appreciated.

Kind regards.

Zeljko

Am Di., 2. Okt. 2018 um 03:07 Uhr schrieb Ben Taylor <ben.taylor@...>:
Hi Ben,

We at LedgerDomain use Golang for everything including smart contracts and even wrote our own app server to replace and enhance node.js

It’s a substantial investment but the client experience and server performance is truly enhanced.

Feel free to reach out if you have any questions,
Ben 

On Oct 1, 2018, at 8:49 PM, Benjamin Djidi <benjamin.djidi@...> wrote:

Benjamin Djidi

Sr. BIE, Amazon International Expansion


Rich Bloch
 

Good Afternoon All,

This is an excellent discussion with a lot of very good information that we can share with other subgroups (and even other WGs) going forward.

To keep member's inboxes reasonably clear, I'd recommend that longer threads get moved over to our Rocket.Chat channel, primarily because the chat channel will self-document discussions much easier for future reference.


Again, a great discussion!

Rich

Richard Bloch
Principal, Business Learning Incorporated
Systems & Software Engineering
Seattle, Washington USA
   206.588.6054 - work 
   425.417.8255- mobile 
    www.businesslearninginc.com


On Tue, Oct 2, 2018 at 11:25 AM Zeljko Milinovic <zeljko.milgrz@...> wrote:
Hi Ben T.,

Thanks for the input. Yes I understood that you never used Composer at LedgerDomain. This is also a great approach.
I was thinking in the near future as soon as the PoC is over it will maybe need to go to production and this will not be possible with Composer.
So I wanted to change the mindset and to switch also future PoC-es to Go Lang.
That is why I wanted to ask for tips and insights on how to Model, Design a GoLang-Fabric PoC like we did with composer and .CTO Domain Language.
And also how to test the models on the beginning and also how to define Assets/Participants/Transactions like we did in Hyperledger Composer.

Any links or tips would be very appreciated.

Thanks in advance.

Kind regards.

Zeljko Milinovic, MSc

Am Di., 2. Okt. 2018 um 17:52 Uhr schrieb Ben Taylor <ben.taylor@...>:
Zeljko,

We never used Composer at LedgerDomain so I’m not the best person to speak to that.  

Happy to chat directly if you have any questions, just shoot me an email at

Ben



On Oct 2, 2018, at 1:41 AM, Zeljko Milinovic <zeljko.milgrz@...> wrote:

Hi to both of the Bens :D

Thanks for the Input. 

Here are my opinions and questions.

Convecta approach could go out of support like composer in one year. I think it is a no go soluion.

As Ben D. stated there are two options Go or Node.

Go lang is for sure faster because it is native. I see also that the link for the shim documentation on GItHub for NodeJS Core ChainCode SDK is not working. I hope that the contributors will work to put more weight into NodeJS.

As for Go. I had some questions for the Ben T.
What are you using for modelling and defining the bussiness network (Assets, Pariticipants, Transactions), like we did in composer?

Any advice on how to approach the Architecture, Modelling and development Cycles would be really appreciated.

Kind regards.

Zeljko

Am Di., 2. Okt. 2018 um 03:07 Uhr schrieb Ben Taylor <ben.taylor@...>:
Hi Ben,

We at LedgerDomain use Golang for everything including smart contracts and even wrote our own app server to replace and enhance node.js

It’s a substantial investment but the client experience and server performance is truly enhanced.

Feel free to reach out if you have any questions,
Ben 

On Oct 1, 2018, at 8:49 PM, Benjamin Djidi <benjamin.djidi@...> wrote:

Benjamin Djidi

Sr. BIE, Amazon International Expansion


A. Courtney
 

Hello all,
Zeljko, I put up some links using GoLang inside the Rocket chat. Hopefully, they will be helpful to all who are interested  as well. I also put up a link to obtain access to the IBM blockchain cloud which hosts the networks. You get 500 free credits to use to test the network using peers. 
Perhaps we as a project, should consider applying to obtain our IBM Network Enterprise license to host our network once it is production ready. Food for thought. Thanks!
( Zeljko, I can email you the links if you do not have access to the group's Rocket chat yet). 

Sincerely,


Founder Adrastia Biotech Corporation
Dr. A. Courtney, CEO
D.V.M., M.B.A., PhD Integrative Pathobiology
U.C. Davis Alumna

   


On Tue, Oct 2, 2018, 12:04 PM Richard Bloch <richardbloch@...> wrote:
Good Afternoon All,

This is an excellent discussion with a lot of very good information that we can share with other subgroups (and even other WGs) going forward.

To keep member's inboxes reasonably clear, I'd recommend that longer threads get moved over to our Rocket.Chat channel, primarily because the chat channel will self-document discussions much easier for future reference.


Again, a great discussion!

Rich

Richard Bloch
Principal, Business Learning Incorporated
Systems & Software Engineering
Seattle, Washington USA
   206.588.6054 - work 
   425.417.8255- mobile 
    www.businesslearninginc.com


On Tue, Oct 2, 2018 at 11:25 AM Zeljko Milinovic <zeljko.milgrz@...> wrote:
Hi Ben T.,

Thanks for the input. Yes I understood that you never used Composer at LedgerDomain. This is also a great approach.
I was thinking in the near future as soon as the PoC is over it will maybe need to go to production and this will not be possible with Composer.
So I wanted to change the mindset and to switch also future PoC-es to Go Lang.
That is why I wanted to ask for tips and insights on how to Model, Design a GoLang-Fabric PoC like we did with composer and .CTO Domain Language.
And also how to test the models on the beginning and also how to define Assets/Participants/Transactions like we did in Hyperledger Composer.

Any links or tips would be very appreciated.

Thanks in advance.

Kind regards.

Zeljko Milinovic, MSc

Am Di., 2. Okt. 2018 um 17:52 Uhr schrieb Ben Taylor <ben.taylor@...>:
Zeljko,

We never used Composer at LedgerDomain so I’m not the best person to speak to that.  

Happy to chat directly if you have any questions, just shoot me an email at

Ben



On Oct 2, 2018, at 1:41 AM, Zeljko Milinovic <zeljko.milgrz@...> wrote:

Hi to both of the Bens :D

Thanks for the Input. 

Here are my opinions and questions.

Convecta approach could go out of support like composer in one year. I think it is a no go soluion.

As Ben D. stated there are two options Go or Node.

Go lang is for sure faster because it is native. I see also that the link for the shim documentation on GItHub for NodeJS Core ChainCode SDK is not working. I hope that the contributors will work to put more weight into NodeJS.

As for Go. I had some questions for the Ben T.
What are you using for modelling and defining the bussiness network (Assets, Pariticipants, Transactions), like we did in composer?

Any advice on how to approach the Architecture, Modelling and development Cycles would be really appreciated.

Kind regards.

Zeljko

Am Di., 2. Okt. 2018 um 03:07 Uhr schrieb Ben Taylor <ben.taylor@...>:
Hi Ben,

We at LedgerDomain use Golang for everything including smart contracts and even wrote our own app server to replace and enhance node.js

It’s a substantial investment but the client experience and server performance is truly enhanced.

Feel free to reach out if you have any questions,
Ben 

On Oct 1, 2018, at 8:49 PM, Benjamin Djidi <benjamin.djidi@...> wrote:

Benjamin Djidi

Sr. BIE, Amazon International Expansion