On the off chance anyone is interested in contributing to JCAP, there are some basic standards which should be ahered to:
- Document everything! For code documentation, use existing code (e.g. Dev/Input/Software/input.spin) as an example. PASM should be documented somewhat anal-retentively, line-by-line, with block comments for routines and subroutines. Header comments should follow the same standard established by existing code as well.
- Any discovered problems/concerns/features that you won't be addressing with your current commit need to have an issue created and assigned to the appropriate person(s), tag, milestone, and project. This eliminates the risk of development amnesia. Additionally, when a commit has satisfied an issue, the commit hash should be referenced in the closing comment of the issue.
- Commit messages need to at a minimum broadly describe each change made to the repository. Whether it's fixing a bug, adding a feature, adding a new datasheet, or updating some indentation, one should be able to read the commit message and understand immediately what's been done to the repo.
- Any documents (manuals, datasheets, tutorials) which are critical to your contributions should be placed in their appropriate subdirectories in /Docs. For similarly important generic links, place them in "Useful Links.txt" in /Docs.
Pull requests that don't follow these guidelines will be rejected until corrections have been made. While this all may seem like an over-processed waste of time, an auxiliary goal for JCAP is to create a project which maintains the highest possible standards to prevent headache down the road and belay confusion to anyone on the outside looking in.