spiff-arena/SpiffWorkflow/CONTRIB

61 lines
2.2 KiB
Plaintext

Guide for Contributors
#######################
Coding style:
Please follow PEP8: http://www.python.org/dev/peps/pep-0008/
Testing:
Non-public classes and methods MUST be prefixed by _. This is also important
because the test and API documentation machinery makes assumptions based on
this convention.
Every added public class MUST have a corresponding unit test. The tests are
placed in the following directory: tests/SpiffWorkflow/
The test directory layout mirrors the source code directory layout, e.g.
SpiffWorkflow/specs/Join.py
has a corresponding test in
tests/SpiffWorkflow/specs/JoinTest.py
The unit test for each class MUST have a CORRELATE class attribute that points
to the tested class. (The test machinery uses this attribute to find untested
methods.)
Each commit MUST NOT break functionality. In other words, the code in the
repository should function at any time, and all test MUST pass.
Documentation:
Every public class and function or method MUST include API documentation. The
documentation MUST cover the method's arguments and return values.
Write inline documentation generously.
Repository:
Make sure that each commit contains related changes only. E.g. don't fix
two unrelated bugs in one commit, or introduce a new feature while refactoring
another part of the program in the same commit. When in doubt, use multiple
small commits. In general, most commits should be relatively small unless they
are plain additions.
Licensing:
You have to agree to licensing under the lGPLv3, and every added file MUST
include a copyright header.
If you modify a file and add a chunk of at least 7 lines in size, please add
yourself to the copyright header of that file.
## Releases
For you dev op folks who release builds to the larger community ...
Update the release tag: doc/conf.py
And also edit setup.py and assure that has the same release tag.
New versions of SpiffWorkflow are automatically published to PyPi whenever
a maintainer of our GitHub repository creates a new release on GitHub. This
is managed through GitHub's actions. The configuration of which can be
found in .github/workflows/....
Just create a release in GitHub that mathches the release number in doc/conf.py