spiff-arena/SpiffWorkflow/CONTRIB

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 matches the release number in doc/conf.py