Templates for Incubation Status
https://bestpractices.coreinfrastructure.org/en
Project Checklist
- Wiki space Maintenance
- Github or Gerrit repositories
- Graphic Set
- Whitepaper
- Training Documentation Packet
- Diverse group of Maintainers
Templates Resource Checklist:
______ Whitepaper | ______ | ______ | ________ | ______________ Presentations | ________ EdX | ______ Webinar | __________ Github | ______ |
---|
Format for Standard
...
To exit incubation, as project must have Sufficient user documentation
The project must including enough documentation for anyone to test or deploy any of the modules.
...
BEST PRACTICE BADGE
...
Online User Guides
...
On Line Course
...
Graphic Set:
...
Webinars
...
Self Paced Training
...
Instructor Led Training
...
Code on
Github
...
MOOC
Section
EDX Chapter
...
Presentations:
Technical /
Non-technical
...
Use Cases
Requirements for BEST PRACTICE BADGE :
Core Infrastructure Initiative
***UPDATE CII TO INCLUDE COMMUNITY READINESS AND DOCUMENTATION.
Basics: | ||
---|---|---|
|
| |
|
| |
|
| |
|
| |
|
| |
Change Control | ||
Public version-controlled source repository | The project MUST have a version-controlled source repository that is publicly readable and has a URL. [repo_public] Show details The project's source repository MUST track what changes were made, who made the changes, and when the changes were made. [repo_track] To enable collaborative review, the project's source repository MUST include interim versions for review between releases; it MUST NOT include only final releases. [repo_interim] Show details It is SUGGESTED that common distributed version control software be used (e.g., git) for the project's source repository. [repo_distributed] Show details | |
Unique version numbering |
It is SUGGESTED that projects identify each release within their version control system. For example, it is SUGGESTED that those using git identify each release using git tags. [version_tags] | |
Release notes | The project MUST provide, in each release, release notes that are a human-readable summary of major changes in that release to help users determine if they should upgrade and what the upgrade impact will be. The release notes MUST NOT be the raw output of a version control log (e.g., the "git log" command results are not release notes). Projects whose results are not intended for reuse in multiple locations (such as the software for a single website or service) AND employ continuous delivery MAY select "N/A". (URL required) [release_notes] The release notes MUST identify every publicly known vulnerability with a CVE assignment or similar that is fixed in each new release, unless users typically cannot practically update the software themselves. If there are no release notes or there have been no publicly known vulnerabilities, choose "not applicable" (N/A). [release_notes_vulns] | |
REPORTING | ||
Bug-reporting process | ||
Vulnerability report process | ||
Quality | ||
Working build system | ||
Automated test suite | ||
New functionality testing | ||
Warning flags | ||
Security | ||
Secure development knowledge | ||
Use basic good cryptographic practices | ||
Secured delivery against man-in-the-middle (MITM) attacks | ||
Other security issues | ||
Static code analysis | ||
Dynamic code analysis | ||
Example : Explorer
Best practices
- All project names must be prefaced with “Hyperledger.”
- Ensure the name is uniquely identifiable. Anticipate and remove potential confusion.
- Are there closely named brands in the tech industry or elsewhere?
- Is it similar to popular existing open source projects?
- Is your project also a common word? If it’s too generic, searching for it and enforcing trademark compliance may be difficult.
- The name should give people some understanding of what the technology does and/or how people can use it.
- Who does your project most appeal to? Understand your target user and what kind of names or brands they respond to.
- Think carefully about what the name evokes. It sets the tone and intent, and will ideally inspire action.
- Consider incorporating a thematic mascot (e.g., Ursa’s bear, Aries’ ram, Burrow’s marmot).
- Aim for no more than eight characters so it will be quick to type and the logo won’t take up too much space.
- Think inclusively.
- Avoid complex acronyms and unnecessarily technical terminology/jargon. How will the name will translate to other cultures or people that may join the project in the future?
- If you select a name related to an inside joke, make sure the origin story is one you’re willing to share with the masses as part of the brand narrative.
- Make sure the name is easy to remember and easy to pronounce. Consider potential mispronunciations.
Project Checklist
- Wiki space Maintenance
- Github or Gerrit repositories
- Graphic Set
- Whitepaper
- Training Documentation Packet
- Diverse group of Maintainers
Templates Resource Checklist:
On-the-fly Style Guide for Hyperledger Publications | Hyperledger Style Guide for Publications
“I put together this style guide on-the-fly while working on publications for Hyperledger. When I encounter an inconsistency or a questionable term, I decide which way seems to make the most sense. I personally dislike the Chicago Manual of Style because it so often says ‘either approach is acceptable.’ I’m not saying these decisions are perfect and must stand forever, but I have followed these guidelines in the first four or five white papers I’ve revised and in several case studies I’ve written over the past year.”—Gordon |
White Paper Standards |
|
To exit incubation, as project must have Sufficient user documentation
The project must including enough documentation for anyone to test or deploy any of the modules.
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
·
...
Requirements for BEST PRACTICE BADGE :
Best practices
- All project names must be prefaced with “Hyperledger.”
- Ensure the name is uniquely identifiable. Anticipate and remove potential confusion.
- Are there closely named brands in the tech industry or elsewhere?
- Is it similar to popular existing open source projects?
- Is your project also a common word? If it’s too generic, searching for it and enforcing trademark compliance may be difficult.
- The name should give people some understanding of what the technology does and/or how people can use it.
- Who does your project most appeal to? Understand your target user and what kind of names or brands they respond to.
- Think carefully about what the name evokes. It sets the tone and intent, and will ideally inspire action.
- Consider incorporating a thematic mascot (e.g., Ursa’s bear, Aries’ ram, Burrow’s marmot).
- Aim for no more than eight characters so it will be quick to type and the logo won’t take up too much space.
- Think inclusively.
- Avoid complex acronyms and unnecessarily technical terminology/jargon. How will the name will translate to other cultures or people that may join the project in the future?
- If you select a name related to an inside joke, make sure the origin story is one you’re willing to share with the masses as part of the brand narrative.
- Make sure the name is easy to remember and easy to pronounce. Consider potential mispronunciations.
Project Checklist
- Wiki space Maintenance
- Repositories
- Github or Gerrit repositories
- Graphic Set
- Whitepaper
- Training Documentation Packet
- Mooc
- Webinars
...