Krolyxon
Commit 9cdeeab

Branches

Refs →

nsxivCONTRIBUTING.md

74 lines · 3.5 KB · Markdown

1Project Scope
2-------------
3
4 * Bug fixes and maintenance
5 * Prioritize extensibility and simplicity
6 * Do not make the codebase more complex, keep it simple to hack on
7 * Do not add extra dependency (if we do, add compile time switch to disable it)
8 * New features may be added if it cannot be achieved (easily) via a shell script,
9 doesn't break backwards compatibility and doesn't violate any of the above rules.
10
11Note: Since we aim to be a drop-in replacement for sxiv, we intend to keep all
12sxiv's behaviors/features even in cases where removing them would make the
13code-base simpler.
14
15
16Contribution Guideline
17----------------------
18
19When contributing, make sure:
20
21 * Your contribution falls under nsxiv's scope and aim
22 * You follow the existing code style (see [.editorconfig](.editorconfig))
23 * You open the pull request from a new branch, not from master
24 * To avoid using force pushes, especially for bigger patches. Only use them
25 when there's merge conflicts.
26
27If your contribution is not suitable for general use, it will not be included in nsxiv.
28For changes that are very much up to preference, such as changing values in config.h,
29please do not open a pull request unless you have an objective explanation.
30
31See the [open issues](https://github.com/nsxiv/nsxiv/issues) to find something
32to work on. You can also filter the issues via label:
33
34* [Good first issue](https://github.com/nsxiv/nsxiv/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22):
35 (Easy) Issues which do not require much if any experience.
36* [Up for grabs](https://github.com/nsxiv/nsxiv/issues?q=is%3Aissue+is%3Aopen+label%3A%22up+for+grabs%22):
37 (Intermediate) Issues which are free for anyone who wants to pick it up.
38 Might require some experience.
39* [Help wanted](https://github.com/nsxiv/nsxiv/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22):
40 (Intermediate/Experienced) Issues where we require some help.
41
42Development workflow for maintainers
43------------------------------------
44
45If we notice you contributing and/or showing interest in issues/pull requests,
46we may invite you to join the nsxiv org as a member. Being a member simply means
47you will be able to approve, disapprove and merge pull requests.
48
49Our workflow regarding pull requests is the following:
50
51 * Code related changes require two approvals, but documentation related
52 changes (e.g. typo) can be merged with just one.
53 * Always prefer squashing when merging. In the case a PR makes more than one
54 significant change, use the "don't squash" tag and rebase instead.
55 * When merging, make sure the commit message is cleaned up properly so that
56 it reflects the current intention of the PR.
57
58For releases, the process is the following:
59
60 * Tag the release with a "vN" tag, where N is the version number. Also set
61 the commit message and tag description for the release commit to "Release
62 version N".
63 * Update `VERSION` macro in the `Makefile`.
64 * Update the changelog (`CHANGELOG.md`):
65 * Include link to the release tarball and add the release date.
66 * Document only the changes or fixes between releases. Don't document
67 changes which never made it into a release.
68 * Use the "Changes" section to document behavior changes since the last
69 release, the "Added" section for new features, and the "Fixes" section
70 for fixed bugs or regressions. Include pull request IDs.
71
72For mundane development related talks which don't warrant their own issue, use
73the [general-dev](https://github.com/nsxiv/nsxiv/discussions/119) discussion
74thread.