File: CONTRIBUTING.md

package info (click to toggle)
python-gsd 2.4.0-1
  • links: PTS, VCS
  • area: main
  • in suites: bullseye
  • size: 904 kB
  • sloc: python: 2,742; ansic: 1,881; makefile: 157; cpp: 109
file content (84 lines) | stat: -rw-r--r-- 2,290 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
Contributions are welcomed via
[pull requests on GitHub](https://github.com/glotzerlab/gsd/pulls).
Contact the **GSD** developers before starting work to ensure it meshes well
with the planned development direction and standards set for the project.

# Features

## Implement functionality in a general and flexible fashion

New features should be applicable to a variety of use-cases. The **GSD**
developers can assist you in designing flexible interfaces.

## Maintain performance of existing code paths

Expensive code paths should only execute when requested.

# Version control

## Base your work off the correct branch

Bug fixes should be based on `maint`. New features should be based on `master`.

## Propose a minimal set of related changes

All changes in a pull request should be closely related. Multiple change sets
that are loosely coupled should be proposed in separate pull requests.

## Agree to the Contributor Agreement

All contributors must agree to the Contributor Agreement
([ContributorAgreement.md](ContributorAgreement.md)) before their pull request
can be merged.

# Source code

## Use a consistent style

[style.rst](doc/style.rst) defines the style guidelines for **GSD** code.

## Document code with comments

Use doxygen header comments for classes, functions, etc. Also comment complex
sections of code so that other developers can understand them.

## Compile without warnings

Your changes should compile without warnings.

# Tests

## Write unit tests

Add unit tests for all new functionality.

## Validity tests

The developer should run research-scale simulations using the new functionality
and ensure that it behaves as intended.

# User documentation

## Write user documentation

Document public-facing API with Python docstrings in Google style.

## Example notebooks

Demonstrate new functionality in the documentation examples pages.

## Document version status

Each user-facing Python class, method, etc. with a docstring should have
[versionadded, versionchanged, and deprecated Sphinx
directives]

## Add developer to the credits

Update the credits documentation to reference what each developer contributed to
the code.

## Propose a change log entry

Propose a short concise entry describing the change in the pull request
description.