jrf-systems / jrf-systems/docsify-deploy
Work standards and guidelines
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
Why do we have this?
Everyone has patterns they follow when working and unless we talk about them, standardize, and agree on how to work together we will trip each other.
How to create branches
We're going follow the Git-flow model and deviate where it make sense for this project.
Gitflow Summary
Turns out you just need to use the tag
Naming branches
Branches should follow the following naming convention to make it easy to figure out what issue the branch goes to along with what type of issue the branch is working on.
I think we should stick with the following tag names:
featurebug
Naming convention:
<tag>/<projectNumber>-<dash-seperated-description>
Example:
feature/10-create-tree-component
Contributor guide
No contributing guide indexed for this repository
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
No file or test is named. Review the proposed Git-flow and branch-naming guidance in this issue, then identify where the project's agreed work standards should be documented; done means the team has a decided, published convention rather than an unresolved proposal.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100