| White Paper | Graphic Set: | Webinars | Self Paced Training | Instructor Led Training | Code onGithub | MOOCSection | Presentations:Technical / | Use Cases |
Fabric | · | · | · | ||||||
Sawtooth | · | · | · | · | |||||
Burrow | · | · | · | · | |||||
Indy | · | · | · | · | |||||
Iroha | · | · | · | · | |||||
Ursa | · | · | · | · | |||||
Aries | · | · | · | · | |||||
Transact | · | · | · | · | |||||
Composer | |||||||||
Cello | |||||||||
Caliper | |||||||||
Quilt | |||||||||
Grid | |||||||||
Explorer |
Requirements for BEST PRACTICE BADGE ( Developing Standards).
Project Checklist
- Wiki space Maintenance
- Repositories
- Github or Gerrit repositories
- Graphic Set
- Whitepaper
- Training Documentation Packet
- Mooc
- Webinars
Presentations:
GET MARKETING LOGO PACKET
should be proofread carefully
should use the Hyperledger/Linux Foundation standard colors and slide template
should use minimal text
Whitepapers:
White Paper Template
Just a few thoughts from Gordon
should contain standard front matter: Title page, About Hyperledger, About This Paper, Contents, Version number and Publication Date, Creative Commons notice, Acknowledgements, About the Working Group sponsor...
should explicitly define the audience, scope and purpose in the front matter
should probably use a numbering system to help organize the contents
should start with an introductory overview of the topics to be covered, and then move into the details of various topics
should use a recognized rhetorical approach when necessary: for example, move-from-the-familiar-to-the-unfamiliar, or compare-and-contrast
should list items in alphabetical order by default; if using any other ordering system, should explicitly state which (by chronology, location, platform, size and so on)
should contain standard back matter: Conclusions, Appendixes, Further Resources, References
should be prepared in Gdocs, not LaTex nor any other formatting language or system
should not require using Github to avoid unnecessary overhead and version control confusion