Agenda for 9/28 HLHCWG #Patient-Member-Subgroup Meeting #patient-member-subgroup #donormilk


Marissa Iannarone
 

Hi All,

Looking forward to our meeting on Friday, Sept 28th at 9am PST. Dial-in information can be found here

We are currently looking for technical support for our Donor Milk PoC and HiMSS AsiaPac submission so please let me know if you're interested in 1) building out the DAPP layer or 2) setting up permissions and access controls for the network. See here for the initial ask.

Agenda for 9/28 Meeting:
  • Welcome and Hyperledger anti-trust policy review - 9:00-9:10 am
  • Updates - POC and HiMSS AsiaPac submission - 9:10-9:20 am
  • Overview of Donor Milk MVP workflow and future scenarios to build out - see Section 2 of the Wiki with the "Happy Path" MVP - 9:20-9:30 am
  • Review of current network and discussion of additional technical needs and ideas for resourcing (Ben D. will present) - 9:30-9:55 am
  • Wrap up and next steps
Let me know if you have any questions.

Best,
Marissa

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


A. Courtney
 

Hello Marissa and Ben,
Is the current network's .bna file / files available in github to open the network inside the playground and take a look before Friday's meeting? A UI build would need to create a connection of the network to a frontend user interface so it can read and interact with the current state of the network as it changes and is updated during use ( UI updating the block chain). The .bna file availability would be needed to create the connection build. Thanks!

Sincerely,


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

   

On Mon, Sep 24, 2018, 8:02 PM Marissa Iannarone <mari.iannarone@...> wrote:
Hi All,

Looking forward to our meeting on Friday, Sept 28th at 9am PST. Dial-in information can be found here

We are currently looking for technical support for our Donor Milk PoC and HiMSS AsiaPac submission so please let me know if you're interested in 1) building out the DAPP layer or 2) setting up permissions and access controls for the network. See here for the initial ask.

Agenda for 9/28 Meeting:
  • Welcome and Hyperledger anti-trust policy review - 9:00-9:10 am
  • Updates - POC and HiMSS AsiaPac submission - 9:10-9:20 am
  • Overview of Donor Milk MVP workflow and future scenarios to build out - see Section 2 of the Wiki with the "Happy Path" MVP - 9:20-9:30 am
  • Review of current network and discussion of additional technical needs and ideas for resourcing (Ben D. will present) - 9:30-9:55 am
  • Wrap up and next steps
Let me know if you have any questions.

Best,
Marissa

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


Marissa Iannarone
 

Hi Angela,

Great question. The latest is not yet available to everyone in GitHub. I’ve reached out to Ry this morning to get Ben permissions needed to push the code he’s built. I’ll keep everyone posted.

-Marissa

On Sep 25, 2018, at 8:47 AM, A. Courtney <adrastiabiotech@...> wrote:

Hello Marissa and Ben,
Is the current network's .bna file / files available in github to open the network inside the playground and take a look before Friday's meeting? A UI build would need to create a connection of the network to a frontend user interface so it can read and interact with the current state of the network as it changes and is updated during use ( UI updating the block chain). The .bna file availability would be needed to create the connection build. Thanks!

Sincerely,


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

   

On Mon, Sep 24, 2018, 8:02 PM Marissa Iannarone <mari.iannarone@...> wrote:
Hi All,

Looking forward to our meeting on Friday, Sept 28th at 9am PST. Dial-in information can be found here

We are currently looking for technical support for our Donor Milk PoC and HiMSS AsiaPac submission so please let me know if you're interested in 1) building out the DAPP layer or 2) setting up permissions and access controls for the network. See here for the initial ask.

Agenda for 9/28 Meeting:
  • Welcome and Hyperledger anti-trust policy review - 9:00-9:10 am
  • Updates - POC and HiMSS AsiaPac submission - 9:10-9:20 am
  • Overview of Donor Milk MVP workflow and future scenarios to build out - see Section 2 of the Wiki with the "Happy Path" MVP - 9:20-9:30 am
  • Review of current network and discussion of additional technical needs and ideas for resourcing (Ben D. will present) - 9:30-9:55 am
  • Wrap up and next steps
Let me know if you have any questions.

Best,
Marissa

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


Marissa Iannarone
 

Hi All,

I might be missing something, but in looking at GitHub, I think everyone should be able to see Ben's fork of the Master Branch and his code, but let me know if this isn't accurate. Steps:

2. Click on the "4" next to Forks
image.png
3. Click on "milk-donor" in bdjidi / milk-donor
image.png
4. Under Branch select "bdjidi"
image.png

Cheers,
M

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



On Tue, Sep 25, 2018 at 9:08 AM Marissa Iannarone <mari.iannarone@...> wrote:
Hi Angela,

Great question. The latest is not yet available to everyone in GitHub. I’ve reached out to Ry this morning to get Ben permissions needed to push the code he’s built. I’ll keep everyone posted.

-Marissa

On Sep 25, 2018, at 8:47 AM, A. Courtney <adrastiabiotech@...> wrote:

Hello Marissa and Ben,
Is the current network's .bna file / files available in github to open the network inside the playground and take a look before Friday's meeting? A UI build would need to create a connection of the network to a frontend user interface so it can read and interact with the current state of the network as it changes and is updated during use ( UI updating the block chain). The .bna file availability would be needed to create the connection build. Thanks!

Sincerely,


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

   

On Mon, Sep 24, 2018, 8:02 PM Marissa Iannarone <mari.iannarone@...> wrote:
Hi All,

Looking forward to our meeting on Friday, Sept 28th at 9am PST. Dial-in information can be found here

We are currently looking for technical support for our Donor Milk PoC and HiMSS AsiaPac submission so please let me know if you're interested in 1) building out the DAPP layer or 2) setting up permissions and access controls for the network. See here for the initial ask.

Agenda for 9/28 Meeting:
  • Welcome and Hyperledger anti-trust policy review - 9:00-9:10 am
  • Updates - POC and HiMSS AsiaPac submission - 9:10-9:20 am
  • Overview of Donor Milk MVP workflow and future scenarios to build out - see Section 2 of the Wiki with the "Happy Path" MVP - 9:20-9:30 am
  • Review of current network and discussion of additional technical needs and ideas for resourcing (Ben D. will present) - 9:30-9:55 am
  • Wrap up and next steps
Let me know if you have any questions.

Best,
Marissa

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


Benjamin Djidi <benjamin.djidi@...>
 

Hi all,

Confirmed, the fork is public and anybody should be able to see the current .cto model.

Thanks,

Ben.

On Tue, Sep 25, 2018, 16:45 Marissa Iannarone <mari.iannarone@...> wrote:
Hi All,

I might be missing something, but in looking at GitHub, I think everyone should be able to see Ben's fork of the Master Branch and his code, but let me know if this isn't accurate. Steps:

2. Click on the "4" next to Forks
image.png
3. Click on "milk-donor" in bdjidi / milk-donor
image.png
4. Under Branch select "bdjidi"
image.png

Cheers,
M

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



On Tue, Sep 25, 2018 at 9:08 AM Marissa Iannarone <mari.iannarone@...> wrote:
Hi Angela,

Great question. The latest is not yet available to everyone in GitHub. I’ve reached out to Ry this morning to get Ben permissions needed to push the code he’s built. I’ll keep everyone posted.

-Marissa

On Sep 25, 2018, at 8:47 AM, A. Courtney <adrastiabiotech@...> wrote:

Hello Marissa and Ben,
Is the current network's .bna file / files available in github to open the network inside the playground and take a look before Friday's meeting? A UI build would need to create a connection of the network to a frontend user interface so it can read and interact with the current state of the network as it changes and is updated during use ( UI updating the block chain). The .bna file availability would be needed to create the connection build. Thanks!

Sincerely,


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

   

On Mon, Sep 24, 2018, 8:02 PM Marissa Iannarone <mari.iannarone@...> wrote:
Hi All,

Looking forward to our meeting on Friday, Sept 28th at 9am PST. Dial-in information can be found here

We are currently looking for technical support for our Donor Milk PoC and HiMSS AsiaPac submission so please let me know if you're interested in 1) building out the DAPP layer or 2) setting up permissions and access controls for the network. See here for the initial ask.

Agenda for 9/28 Meeting:
  • Welcome and Hyperledger anti-trust policy review - 9:00-9:10 am
  • Updates - POC and HiMSS AsiaPac submission - 9:10-9:20 am
  • Overview of Donor Milk MVP workflow and future scenarios to build out - see Section 2 of the Wiki with the "Happy Path" MVP - 9:20-9:30 am
  • Review of current network and discussion of additional technical needs and ideas for resourcing (Ben D. will present) - 9:30-9:55 am
  • Wrap up and next steps
Let me know if you have any questions.

Best,
Marissa

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

--

Benjamin Djidi

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

+33 762 001 145


Rich Bloch
 

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

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 4:59 PM Benjamin Djidi <benjamin.djidi@...> wrote:
Hi all,

Confirmed, the fork is public and anybody should be able to see the current .cto model.

Thanks,

Ben.

On Tue, Sep 25, 2018, 16:45 Marissa Iannarone <mari.iannarone@...> wrote:
Hi All,

I might be missing something, but in looking at GitHub, I think everyone should be able to see Ben's fork of the Master Branch and his code, but let me know if this isn't accurate. Steps:

2. Click on the "4" next to Forks
image.png
3. Click on "milk-donor" in bdjidi / milk-donor
image.png
4. Under Branch select "bdjidi"
image.png

Cheers,
M

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



On Tue, Sep 25, 2018 at 9:08 AM Marissa Iannarone <mari.iannarone@...> wrote:
Hi Angela,

Great question. The latest is not yet available to everyone in GitHub. I’ve reached out to Ry this morning to get Ben permissions needed to push the code he’s built. I’ll keep everyone posted.

-Marissa

On Sep 25, 2018, at 8:47 AM, A. Courtney <adrastiabiotech@...> wrote:

Hello Marissa and Ben,
Is the current network's .bna file / files available in github to open the network inside the playground and take a look before Friday's meeting? A UI build would need to create a connection of the network to a frontend user interface so it can read and interact with the current state of the network as it changes and is updated during use ( UI updating the block chain). The .bna file availability would be needed to create the connection build. Thanks!

Sincerely,


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

   

On Mon, Sep 24, 2018, 8:02 PM Marissa Iannarone <mari.iannarone@...> wrote:
Hi All,

Looking forward to our meeting on Friday, Sept 28th at 9am PST. Dial-in information can be found here

We are currently looking for technical support for our Donor Milk PoC and HiMSS AsiaPac submission so please let me know if you're interested in 1) building out the DAPP layer or 2) setting up permissions and access controls for the network. See here for the initial ask.

Agenda for 9/28 Meeting:
  • Welcome and Hyperledger anti-trust policy review - 9:00-9:10 am
  • Updates - POC and HiMSS AsiaPac submission - 9:10-9:20 am
  • Overview of Donor Milk MVP workflow and future scenarios to build out - see Section 2 of the Wiki with the "Happy Path" MVP - 9:20-9:30 am
  • Review of current network and discussion of additional technical needs and ideas for resourcing (Ben D. will present) - 9:30-9:55 am
  • Wrap up and next steps
Let me know if you have any questions.

Best,
Marissa

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

--

Benjamin Djidi

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

+33 762 001 145


Ry Jones
 

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


Rich Bloch
 

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


Zeljko Milinovic <zeljko.milgrz@...>
 

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 <benjamin.djidi@...>
 

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


Marissa 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 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