|
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
|
|
|
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
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
|
|
|
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
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
|
|
|
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 3. Click on "milk-donor" in bdjidi / milk-donor
4. Under Branch select "bdjidi"
Cheers, M
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 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
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
|
|
|
Benjamin Djidi <benjamin.djidi@...>
Hi all,
Confirmed, the fork is public and anybody should be able to see the current .cto model.
Thanks,
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 3. Click on "milk-donor" in bdjidi / milk-donor
4. Under Branch select "bdjidi"
Cheers, M
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
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
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
-- 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 |
Hi all,
Confirmed, the fork is public and anybody should be able to see the current .cto model.
Thanks,
Ben. 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 3. Click on "milk-donor" in bdjidi / milk-donor
4. Under Branch select "bdjidi"
Cheers, M
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
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
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
Benjamin Djidi
Sr. BIE, Amazon International Expansion
Former Founding Partner, Revstr
President Emeritus, IESEG International Club
+33 762 001 145
|
|
|
Ry Jones
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
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).
-- Ry Jones Community Architect, Hyperledger
|
|
|
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 |
On Tue, Sep 25, 2018 at 10:15 PM Ry Jones < rjones@...> wrote: 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
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).
Ry Jones Community Architect, Hyperledger
|
|
|
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
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 |
On Tue, Sep 25, 2018 at 10:15 PM Ry Jones < rjones@...> wrote: 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
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).
Ry Jones Community Architect, Hyperledger
|
|
|
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.
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
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 |
On Tue, Sep 25, 2018 at 10:15 PM Ry Jones < rjones@...> wrote: 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
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).
Ry Jones Community Architect, Hyperledger
-- Benjamin Djidi
Sr. BIE, Amazon International Expansion
Former Founding Partner, Revstr
President Emeritus, IESEG International Club
+33 762 001 145
|
|
|
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!): - The link to the github docs that outlines and explains
how to create a pull request to add files 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:
- 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
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
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. 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
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 |
On Tue, Sep 25, 2018 at 10:15 PM Ry Jones < rjones@...> wrote: 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
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).
Ry Jones Community Architect, Hyperledger
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/
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!): - The link to the github docs that outlines and explains
how to create a pull request to add files 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:
- 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
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
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. 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
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 |
On Tue, Sep 25, 2018 at 10:15 PM Ry Jones < rjones@...> wrote: 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
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).
Ry Jones Community Architect, Hyperledger
Benjamin Djidi
Sr. BIE, Amazon International Expansion
Former Founding Partner, Revstr
President Emeritus, IESEG International Club
+33 762 001 145
|
|
|
