Simplify branching and documentation strategy
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 23.1k
- Forks
- 1.1k
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 9
Description
Currently, this repository follows a branching strategy with master and develop branches. Pull requests are created against the develop branch for ongoing development, and only when a release is made, changes are merged into master. However, this approach has some drawbacks, such as an outdated README.rst for small documentation fixes until a release is made and confusion for new contributors who create pull requests against the wrong branch (master).
My proposal would be an alternative approach that involves simplifying the branching strategy and handling documentation differently (https://github.com/getsops/community/issues/9), while also renaming master to main (https://github.com/getsops/community/issues/16).
Proposed alternative
- A single
mainbranch (renamed fromdevelop). - Most of
README.rstmoved to e.g.docs/. - Link from
README.mdto (latest) tagged docs. - (Eventually) a documentation website.
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
Review README.rst and README.md, then read the linked community issues about documentation and branch naming. The work is done when the repository has an agreed single-main branching strategy, documentation is moved and linked as proposed, and the resulting contributor workflow is clear.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git
- Domain
- devops, documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100