Synchronize Documentation: Synchronize documentation versions in template repos
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 36
- Forks
- 14
- PR merge metrics
- No merged PRs in 30d
Description
Checked for duplicates
Yes - I've already checked
Category
Information Sharing - documentation design, templates, communication, etc.
Describe the need
We have a need to ensure that documentation files are canonical and updated regularly in templatized repos. For example, the README format is updated in the slim-starterkit repository but it is not updated in the slim-starterkit-python repository. Similar scenarios evolve with GitHub PR and Issue templates, GitHub Action YAML descriptors and other files.
This proposal is to script the copy and release of approved changes. The slim-starterkit repository will be declared the canonical reference. All requested files will be copied into the other repos distributing these files and a PR created. The PR will be automatically approved and the repo will also be automatically tagged. All updated files will be distributed by a single execution.
Potential files:
- CHANGELOG.md
- CODE_OF_CONDUCT.md
- CONTRIBUTING.md
- GOVERNANCE.md
- LICENSE
- README.md
- others, as determined
Versioning:
Version numbers will be inserted at the bottom of all files, according to the last known tag version of the slim-starterkit repo. The script will only execute against the main branch so as to only collect tagged content.
Technology:
The script may be Bash-based or through the multi-gitter tool.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the slim-starterkit repository as the proposed canonical source and comparing its candidate files with the template repositories named in the issue. Decide whether Bash or multi-gitter is the execution path, then define how main-branch content, tag-based versions, pull requests, approvals, and repository tags should be handled. Done means one execution distributes all approved files consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, shell
- Domain
- documentation, release, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100