Reproog/novelWriter
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update readme and contributing guide

Browse Source
This commit is contained in:
Veronica Berglyd Olsen
2024-04-06 17:42:42 +02:00
parent d569001f32
commit 80ebf60ec5
2 changed files with 39 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CONTRIBUTING.md
+35 -25
View File
@@ -1,45 +1,45 @@
# Contributing Guide # Contributing Guide
When contributing to this repository, please first discuss the change you wish to make via the When contributing to this repository, please first discuss the change you wish to make with the
issue tracker or the discussions page with the owner of this repository. Especially if it is owner of this repository> Either via the issue tracker or on the discussions page. Especially if it
regarding new features. If you just want to make a minor correction, like fix a typo or similar, is regarding new features. If you just want to make a minor correction, like fix a typo or similar,
feel free to just make a pull request directly. feel free to just make a pull request directly.
The following contributions are welcome: **The following contributions are welcome:**
* Bugfixes for new or existing bugs. Please also report new bugs in the issue tracker even if you * Bugfixes for new or existing bugs. Please also report new bugs in the issue tracker even if you
also provide a fix. It makes it easier to keep track of what has been fixed and when. also provide a fix. It makes it easier to keep track of what has been fixed and when.
* Translations via the [crowdin project page](https://crowdin.com/project/novelwriter). * Translations via the [Crowdin project page](https://crowdin.com/project/novelwriter).
* Improvements to the documentation. Particularly if the documentation is unclear. Please don't * Improvements to the documentation. Particularly if the documentation is unclear. Please don't
make any larger changes to the documentation without discussing if with the maintainer first. make any larger changes to the documentation without discussing if with the maintainer first.
* Adaptations, installation or packaging features targeting specific operating systems. * Adaptations, installation or packaging features targeting specific operating systems.
Please do not: **Please do not:**
* Make a pull request that restructures or reformats existing code. If you think some parts of the * Make a pull request that restructures or reformats existing code. If you think some part of the
code could be improved, please make an issue thread or start a discussion. The same applies to code could be improved, please make an issue thread or start a discussion. The same applies to
any text document in the repository. any text document in the repository.
## Pull Requests ## Picking the Correct Branch for a Pull Request
This project follows the [OneFlow](https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow) As of April 2024, pre-releases and point releases (like 2.x) are made from the `main` branch. The
model. The `main` branch is the default branch. For general changes, please make a new branch in `main` branch is the default branch. For general changes, please make a new branch in your own fork
your own fork from the current `main` branch. Do not make pull requests from your own `main` from the current `main` branch. Do not make pull requests from your own `main` branch.
branch.
**Note:** If your contribution is a bugfix for a specific version, please make a bugfix branch from If you are submitting a fix to a current release, say 2.4, you must do so from the correct release
the tag you want the fix to be applied to, not directly from the `main` branch. This is important. branch. For 2.4 this is `releases/v2.4`. If you make a fix on the `main` branch, **it cannot be
included in a 2.4.x release**. This also applies to the current documentation published on the
main website.
Also check the following: **Also check the following:**
* Make sure your code passes all tests and conforms to the style guide. You can check that the * Make sure your code passes all tests and conforms to the style guide. You can check that the
code generally conforms by running the Python linting tool `flake8` from the root of the project code generally conforms by running the Python linting tool `flake8` from the root of the project
folder, although it doesn't check everything. The same check is also run on pull requests by the folder, although it doesn't check everything. The same check is also run on pull requests.
maintainer.
* Please provide a description of the changes in the pull request under the summary section of the * Please provide a description of the changes in the pull request under the summary section of the
pull request template, and reference any related issues by providing the issue number. pull request template, and reference any related issues by providing the issue number.
* Do not change the version number. * Do not change the version number.
* Do not submit files that were not actively changed but have otherwise been modifed. This is * Do not submit files that were not actively changed but have otherwise been modified. This is
mostly an issue with translation files. The language tool may update all files in the `i18n` mostly an issue with translation files. The language tool may update all files in the `i18n`
folder. folder.
@@ -68,14 +68,14 @@ style guide, but with a few exceptions. Some key points are listed below.
is the recommended line length in PEP8, but this is often too restrictive. 99 characters are is the recommended line length in PEP8, but this is often too restrictive. 99 characters are
acceptable when that is more practical. Readability has priority. Generally, if a code statement acceptable when that is more practical. Readability has priority. Generally, if a code statement
requires multiple lines, the lines should wrap at 79 characters if possible. If wrapping can be requires multiple lines, the lines should wrap at 79 characters if possible. If wrapping can be
avoided by going to 99, then that is generally preferrable. avoided by going to 99, then that is generally preferable.
* For text files, the text should be wrapped at 99 character. The exception is markdown image tags * For text files, the text should be wrapped at 99 character. The exception is markdown image tags
and urls which can run past that limit. and urls which can run past that limit.
**Variable and Function Names** **Variable and Function Names**
* PEP8 allows for camelCase for consistency with existing code. The Qt library uses camelCase, so * PEP8 allows for camelCase for consistency with existing code. The Qt library uses camelCase, so
the Python source code does too. the novelWriter source code does too.
* The exception to the above is for constants. They should always be in upper snake case, like PEP8 * The exception to the above is for constants. They should always be in upper snake case, like PEP8
states. states.
@@ -83,19 +83,29 @@ style guide, but with a few exceptions. Some key points are listed below.
* Only indentation by multiples of 4 spaces is allowed. * Only indentation by multiples of 4 spaces is allowed.
* No trailing spaces should occur on any line in the source code, including empty lines. * No trailing spaces should occur on any line in the source code, including empty lines.
* Ideally, a function should end on the same indention level as it started. Exceptions are allowed * All common line wrapping methods are allowed in the code, but avoid deep indentations.
if it makes the code easier to follow.
* Aligning operators and attributes in columns with multiple spaces is not allowed by PEP8. The * Aligning operators and attributes in columns with multiple spaces is not allowed by PEP8. The
rule is relaxed a bit here. Alignment is allowed when populating large dictionaries or setting rule is relaxed a bit here. Alignment is allowed when populating large dictionaries or setting
many class attributes. It does improve readability in such cases, but should not be overused. many class attributes. It does improve readability in such cases, but should not be overused.
**Type Annotation**
* All functions must be properly type annotated, and a return type stated in all cases.
* Do not use `List`, `Dict`, `Tuple`, etc, annotations that were deprecated in Python 3.9. You can
install the `flake8-pep585` extension to make sure you don't forget. This is also checked by the
syntax action run on pull requests.
* If annotations require a more recent Python version than the minimum version stated in the
project's `pyproject.toml`, hide it under an `if TYPE_CHECKING` condition so that the code can
still run on older versions. It's OK to require a more recent version for development.
### Linting with `flake8` ### Linting with `flake8`
A good tool for checking Python code for errors and code style is `flake8`. The documentation is A good tool for checking Python code for errors and code style is `flake8`. The documentation is
available [here](https://flake8.pycqa.org/en/latest/). available [here](https://flake8.pycqa.org/en/latest/).
The `setup.cfg` file in the root of this project has the following settings for `flake8` that The `.flake8` file in the root of this project has the following settings for that matches the
matches the above code style: required code style:
```conf ```conf
[flake8] [flake8]
ignore = E133,E221,E226,E228,E241,W503 ignore = E133,E221,E226,E228,E241,W503
@@ -115,7 +125,7 @@ command will give you a detailed description of the code lines that do not confo
Two of the ignored errors are due to the relaxed restriction on column alignment, these are the Two of the ignored errors are due to the relaxed restriction on column alignment, these are the
E221 and E241 error codes. E221 and E241 error codes.
The code E226 is ignored becuse it doesn't actually follow the The code E226 is ignored because it doesn't actually follow the
[PEP8 recommendation](https://www.python.org/dev/peps/pep-0008/#other-recommendations) [PEP8 recommendation](https://www.python.org/dev/peps/pep-0008/#other-recommendations)
of grouping longer equations by operator precedence like `2*a + 3*b` instead of `a * a + 3 * b`. of grouping longer equations by operator precedence like `2*a + 3*b` instead of `a * a + 3 * b`.
Generally, don't use spaces around `*`, `/` and `**`, but _do_ use spaces around `+` and `-`. Generally, don't use spaces around `*`, `/` and `**`, but _do_ use spaces around `+` and `-`.
README.md
+4
View File
@@ -49,6 +49,10 @@ code, please also read the full
Project credits are available in [CREDITS.md](https://github.com/vkbo/novelWriter/blob/main/CREDITS.md). Project credits are available in [CREDITS.md](https://github.com/vkbo/novelWriter/blob/main/CREDITS.md).
**Note:** As of April 2024, pre-releases and point releases (2.x) are made from the `main` branch.
Patches are made from `releases/v2.x` branches. So if you're submitting a fix to a current release,
**including changes to documentation**, they must be made to the correct branch.
### Translations ### Translations
New translations are always welcome. This project uses Crowdin to maintain translations, and you New translations are always welcome. This project uses Crowdin to maintain translations, and you