Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue 122 Contrib Docs #123

Draft
wants to merge 3 commits into
base: development
Choose a base branch
from
Draft

Issue 122 Contrib Docs #123

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
2c0ce5f
Update contribution documentation with better PR policies
dtg3 Oct 16, 2019
6becd16
Address pull request comment regarding QT
dtg3 Oct 18, 2019
48eefb0
Add patching for previous release
dtg3 Oct 18, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 23 additions & 8 deletions CONTRIB.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,26 +1,41 @@
### Coding Standards
* Configure editor so indents are four spaces (Should be the default in Visual Studio 2017).
* Configure editor so indents are four spaces (Should be the default in Visual Studio).
* All source and WPF filenames will be Pascal Case (example: MainClass.cs).
* When possible If no standard library functionality exists, then use Qt.
* Naming Styles:
* We are primarily following these (guidelines)[https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions] from Microsoft with the exception of local variables
* Class names, members, and functions will be Pascal Case
* We are primarily following these (guidelines)[https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions] from Microsoft with the exception of local variables.
* Class names, members, and functions will be Pascal Case.
* Local variables and function parameters will be Camel Case (example: localVar).
* Online examples from MS contradict the style guideline for local variables, but I feel this provides visual differentiation of scope for identifiers.
* Constants will be in call caps.

* Do not use magic numbers. Instead, use named constants.

### Project Standards
* Do not commit autogenerated files to the project repository.
* Addition of any 3rd party libraries (other than support for trackers) must be requested in a GitHub issue complete with links to the library and explanation of its need/value for the project.

### Branching
* The master branch is used for the most recent and tested stable release. No commits are to be added to the master branch by anyone other than a release manager.
* The master branch is used for the most recent and tested stable release.
* **No commits are to be added to the master branch by anyone other than a release manager.**
* Merging temporary fix/feature branches into will be done via pull request and by a release manager.
* The develop branch contains tested features to be included in the next release.
* If you are an internal member of the project and collaborating on features, please make your changes in a branch named issue##-keyword, where ## represents the issue number and a keyword or short phrase is provided to easily identify the branch.

### Patch Fixes for Existing Releases
* If a bug fix is required for an existing release, changes must be made based on the appropriate release tag.
* This becomes important when patching a previous release and master has diverged (e.g. patching version 1.5 after 2.0 has been released).
* Hotfix/patch tags may be issued for patch fixes to previous releases.
* If master and the current tag are equivalent (same current release, master may be used as the base for changes).
* Fixes will be done in a temporary branch, and a pull request will be submitted to merge those changes with master (and development if appropriate).
* Patched releases will be packaged at the discression of the development team and PI(s).
* The subsequent patched release **must** have a release tag generated at the time of release (freezing the state).

### Pull Requests
* NO CODE IS TO BE MERGED INTO MASTER OR DEVELOP WITHOUT A PULL REQUEST FOR CODE REVIEW.
* **NO CODE IS TO BE MERGED INTO STAGING BRANCHES (MASTER, DEVELOPMENT, ETC) WITHOUT A PULL REQUEST FOR CODE REVIEW.**
* Pull requests will be used to migrate fixes and features into staging branches.
* Pull requests **must** be based on an existing issue on GitHub.
* A pull request must be reviewed by at least one development team member other than the original author (with two being preferrable).
* If no particular development team member is needed for review, using the @iTrace-Dev/itrace-developers in the pull request should notify all development team members of the pull request.
* Pull requests must outline what testing was done by the author(s) prior to the pull request, and briefly describe the fix/feature.
* Pull request reviews must contain testing procedures used by the reviewer(s) or indicate that procedures were repeated as outlined by the original pull request author(s) or other reviewer(s).
* Ensure that you periodically update branches with code changes from your branch base (master/develop/etc) to ensure that regressions and merge conflicts are resolved before pull requests are submitted.
* If you are having difficulties with a merge conflict or are uncomfortable making a pull request, please reach out to another member of the development group via an issue comment or Discord.
* If you are having difficulties with a merge conflict or are uncomfortable making a pull request, please reach out to another member of the development group via a comment on the issue inquestions or Discord.