gianmarco
/
nsxiv
Archived
1
0
Fork 0
Code Issues Pull Requests Activity

Document development workflow for maintainers (#202) 

Co-authored-by: NRK <nrk@disroot.org>
Co-authored-by: Berke Kocaoğlu <berke.kocaoglu@metu.edu.tr>
master
mamg22 2022-01-08 11:09:38 -04:00 committed by GitHub
parent a9c6cbcd20
commit 157cda5b31
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 36 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
CONTRIBUTING.md
View File

@ -21,6 +21,8 @@ When contributing, make sure:
* Your contribution falls under nsxiv's scope and aim
* You follow the existing code style (see [.editorconfig](.editorconfig))
* You open the pull request from a new branch, not from master
* To avoid using force pushes, especially for bigger patches. Only use them
when there's merge conflicts.
If your contribution is not suitable for general use, it will not be included in nsxiv.
For changes that are very much up to preference, such as changing values in config.h,
@ -36,3 +38,37 @@ to work on. You can also filter the issues via label:
Might require some experience.
* [Help wanted](https://github.com/nsxiv/nsxiv/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22):
(Intermediate/Experienced) Issues where we require some help.
Development workflow for maintainers
------------------------------------
If we notice you contributing and/or showing interest in issues/pull requests,
we may invite you to join the nsxiv org as a member. Being a member simply means
you will be able to approve, disapprove and merge pull requests.
Our workflow regarding pull requests is the following:
* Code related changes require two approvals, but documentation related
changes (e.g. typo) can be merged with just one.
* Always prefer squashing when merging. In the case a PR makes more than one
significant change, use the "don't squash" tag and rebase instead.
* When merging, make sure the commit message is cleaned up properly so that
it reflects the current intention of the PR.
For releases, the process is the following:
* Tag the release with a "vN" tag, where N is the version number. Also set
the commit message and tag description for the release commit to "Release
version N".
* Update `VERSION` macro in the `Makefile`.
* Update the changelog (`CHANGELOG.md`):
* Include link to the release tarball and add the release date.
* Document only the changes or fixes between releases. Don't document
changes which never made it into a release.
* Use the "Changes" section to document behavior changes since the last
release, the "Added" section for new features, and the "Fixes" section
for fixed bugs or regressions. Include pull request IDs.
For mundane development related talks which don't warrant their own issue, use
the [general-dev](https://github.com/nsxiv/nsxiv/discussions/119) discussion
thread.