It would be helpful to have the content-specific contribution guidelines, which could discuss the requirements, review process and strategy around content governance & lifecycle.
AC
Document best practices for storing and creating Hub manifests:
Hierarchy, e.g. prefer cap.interface.database.postgresql instead of cap.interface.postgres
How populator stores data e.g. generated path. Currently, they are calculated from dir structure (hierarchy).
How to deal with multiple revisions for the same Action. Currently, we use file names, e.g. install-0.0.1, install-0.2.1
Document review process and strategy around content governance & lifecycle.
To discuss: Apart from CONTRIBUTING.md, publish it also on website in Community section
Reason
"Consistent code is easier to maintain, is easier to rationalize, requires less cognitive overhead, and is easier to migrate or update as new conventions emerge or classes of bugs are fixed."
It's easier for us to review community PRs.
External contributors don't need to figure out the correct approach each time they create manifests.
There are no defined rules how the Hub content should be stored, which might be confusing for content developers.
Transparency
Use cases
Content Developer - knows how to create quality, good content.
Description
It would be helpful to have the content-specific contribution guidelines, which could discuss the requirements, review process and strategy around content governance & lifecycle.
AC
cap.interface.database.postgresqlinstead ofcap.interface.postgresinstall-0.0.1,install-0.2.1Reason
Use cases