new approach to Golden Path Templates
Goal
What we have been calling golden Path templates are examples of golden path templates.
These examples are not features that users would use as they are in the repo. Instead, they serve as a foundation for our users and teams to build unique templates.
Since each organization has unique ways of handling applications, a template created for one application will not be universally applicable. As such, Golden Path templates should be viewed as examples that users and teams can use as a blueprint to create their templates.
Acceptance criteria
- [ ] It should be clear that this repo contains examples and not finished (ready to be consumed) templates. Renaming the repo to
software-template-examplesand explaining this in repo README.md should make this clear.- [ ] don't forget to update showcase configuration
- [ ] Remove similar templates. Some templates are almost identical; for example, the only difference between
quarkus-backendandspring-boot-backendis that they use different skeletons; otherwise, the template is almost identical. Find other similar templates and keep just one example of the same template flow. - [ ] Each of the remaining GPTs should be well documented. The Readme of the template should explain the purpose of the template and describe any requirements or setups of 3rd party systems.
template.yamlitself should contain comments explaining the purpose of each step or parameter. The template description should clearly state that the template is just an example.
Issues in Epic
- [ ] tbd
Notes
Another thing we might need to capture here is moving away from the term GPT wherever we might have it and standardize on community terminology which I believe is just software templates.