DEVELOPERS Select link to Get Started:   https://start-here.hyperledger.org/

Get started in a LMDWG project .

https://zoom.us/j/93304666234?pwd=OEswSmpjS2oxeWE2NmZId2hBanBnQT09 https://github.com/hyperledger/learning-materials-dev

• GitHub Repository  
  New https://github.com/hyperledger/learning-materials-dev
  NEW PROJECT https://github.com/hyperledger-labs/university-course  Rafael will be presenting on this topic later : Project Plan - Build a university course on Hyperledger Fabric using Hyperledger Umbra

Purpose:

Hosting content that makes sense to have in GitHub (i.e. where source control makes sense, as opposed to using the wiki) that the LMDWG members want to share for collaboration.  Ideally, this should just be a "development" area where it is being prepped for some greater purpose in the published Hyperledger documentation space.  This should not be the final destination where a contribution comes to grow old and die, since we're a development working group.

Structure:

• LICENSE governing the contents of the repo.  Ry Jones, Hyperledger Community Architect, has set us up with Apache 2.0 in the currently empty repo.
• ACTIVE/<project> holds active projects
• ARCHIVE/<old-project> holds projects that are no longer being maintained.  
• README.md explains the purpose of the repo
• CONTRIBUTING.md explains how to contribute a <project> and how to file issues. It would point to ACTIVE/<project>/CONTRIBUTING.md files for specifics on how to contribute to each <project>
• ACTIVE/<project>/README.md explains what <project> is, how to use it, and its intended destination
• ACTIVE/<project>/CONTRIBUTING.md gives requirements for how to contribute to each <project>  
• ACTIVE/<project>/MAINTAINERS.md lists who is responsible for <project>
• ACTIVE/<project>/TESTING.md explains how to run the tests for the project

Rules:

• Anyone who contributes a <project> must be willing to be the maintainer of that <project>.  This means answering questions, responding to issues, keeping things up-to-date, and driving the contribution to its destination in the published Hyperledger documentation space.  They may have co-maintainers.
• Issues should be reported using the GitHub issues mechanism.  We should come up with some guidelines to make sure people submit issues with relevant details.  We should also come up with expected response time for the maintainers to respond to issues.
• Contributions should be submitted by GitHub Pull Request.  For anything that involves code, it must have a test suite to ensure nothing breaks and passing tests and instructions for others to run the test suite.  New contributions must also pass the test suite and, if implementing new features not covered by the test suite, new tests should also be submitted to the test suite & everything should pass.  
• Any ACTIVE/<project> that has had no updates for a year will be moved to ARCHIVE/ and all the Issues & PRs for it will be closed as obsolete.  This can happen sooner at the request of the <project> maintainer.
• Any other suggestions for rules?  

2. Project Plan - Build a university course on Hyperledger Fabric using Hyperledger Umbra

Hello all,
I'm building a university course on Hyperledger Technologies, with focus on Hyperledger Fabric. This course is open source and will be exposed as an Hyperledger Lab. Despite being focused on Fabric, I think it would be very valuable including a lab class on Hyperledger Besu.

I would like very much to welcome any ideas, suggestions, and contributions.
Please feel free to reach me!

Cheers,

--Rafael BelchiorPh.D. student in Computer Science and Engineering, Blockchain - Técnico Lisboa
https://rafaelapb.github.io/
https://www.linkedin.com/in/rafaelpbelchior/

Hi all,

For those who didn't catch it in the recent LMDWG calls, we have a new GitHub repo for the LMDWG at hyperledger/learning-materials-dev.  

(Some of you may recall the hyperledger/education repo that we were involved with.  The purpose of that repo was the EdX courses and it became obsolete.  The old education repos were archived and can now be found read-only at hyperledger-archives/education and hyperledger-0archives/education-cryptomoji)

Before we start populating it, I propose we have a plan for its structure and some rules.  Here are my thoughts and I request your comments & feedback, especially if any of you have experience as GitHub repo maintainers.

Purpose:
Hosting content that makes sense to have in GitHub (i.e. where source control makes sense, as opposed to using the wiki) that the LMDWG members want to share for collaboration.  Ideally, this should just be a "development" area where it is being prepped for some greater purpose in the published Hyperledger documentation space.  This should not be the final destination where a contribution comes to grow old and die, since we're a development working group.

Structure:

• LICENSE governing the contents of the repo.  Ry Jones, Hyperledger Community Architect, has set us up with Apache 2.0 in the currently empty repo.
• ACTIVE/<project> holds active projects
• ARCHIVE/<old-project> holds projects that are no longer being maintained.  
• README.md explains the purpose of the repo
• CONTRIBUTING.md explains how to contribute a <project> and how to file issues. It would point to ACTIVE/<project>/CONTRIBUTING.md files for specifics on how to contribute to each <project>
• ACTIVE/<project>/README.md explains what <project> is, how to use it, and its intended destination
• ACTIVE/<project>/CONTRIBUTING.md gives requirements for how to contribute to each <project>  
• ACTIVE/<project>/MAINTAINERS.md lists who is responsible for <project>
• ACTIVE/<project>/TESTING.md explains how to run the tests for the project

Rules:

• Anyone who contributes a <project> must be willing to be the maintainer of that <project>.  This means answering questions, responding to issues, keeping things up-to-date, and driving the contribution to its destination in the published Hyperledger documentation space.  They may have co-maintainers.
• Issues should be reported using the GitHub issues mechanism.  We should come up with some guidelines to make sure people submit issues with relevant details.  We should also come up with expected response time for the maintainers to respond to issues.
• Contributions should be submitted by GitHub Pull Request.  For anything that involves code, it must have a test suite to ensure nothing breaks and passing tests and instructions for others to run the test suite.  New contributions must also pass the test suite and, if implementing new features not covered by the test suite, new tests should also be submitted to the test suite & everything should pass.  
• Any ACTIVE/<project> that has had no updates for a year will be moved to ARCHIVE/ and all the Issues & PRs for it will be closed as obsolete.  This can happen sooner at the request of the <project> maintainer.
• Any other suggestions for rules?  

I still need to find out from Ry how commit rights work with the Hyperledger repositories.

Thanks & regards,

Nathalie C. Chan King Choy
Project Manager focused on Open Source and Community

12/17 email

Nathalie.

We should include The Linux Foundation education/training group in these discussions. This repository was initially created to house all of the educational material that was created for the different Hyperledger courses. This did not happen. I am not aware of the status of the EdX course in comparison to what is currently in the education repository. I know that a lot of the demo-specific content was supposed to be removed from the EdX course, as it was hard to keep the material up to date with the rapidly changing frameworks. As such, I am curious if it makes sense to archive the education repository.

...