Merge pull request #550 from Green-Software-Foundation/add-gh-process…

…es-doc

Add github processes doc to IF repo

github-processes.md

@@ -0,0 +1,158 @@
+
+## IF Repositories
+
+- [`if`](https://github.com/Green-Software-Foundation/if)
+    - source code for the IF
+- [`if-plugins`](https://github.com/Green-Software-Foundation/if-plugins)
+    - source code for standard library of plugins
+    - IF core team commit to maintaining these plugins 
+- [`if-unofficial-plugins`](https://github.com/Green-Software-Foundation/if-unofficial-plugins)
+    - source code for plugins relying on third-party data/APIs
+    - intended to be deprecated and removed in mid-term future
+    - plugins in this repo should be handed over to relevant organizations to maintain
+- [`if-plugin-template`](https://github.com/Green-Software-Foundation/if-plugin-template)
+    - template for new plugins
+    - intended for builders to bootstrap IF-compatible plugin development
+- [`if-standards`](https://github.com/Green-Software-Foundation/if-standards)
+    - not currently used, but intended to be the home of params.ts
+    - will have a dedicated discussion board and governance to set IF standards
+- [`if-exhaust plugins`](https://github.com/Green-Software-Foundation/if-exhaust-plugins)
+    - not currently used
+    - intended to become a separate repo just for exhaust plugins
+    - requires strict rules from if
+
+
+## Branch names and purposes
+
+Our main repositories all have two branches: `main` and `release`.
+Here are the rules applied to each branch:
+
+### `if`, `if-plugins`, `if-unofficial-plugins` and `if-exhaust-plugins`
+
+#### `main`
+- target branch for PRs
+- PRs can be merged into `main` with two core team reviews, one being QA
+- `main` regularly advances ahead of the `release` branch
+- merged into `release` periodically, only after full QA approval
+- pushing directly to `main` is forbidden - all changes are by PR
+- PRs will not be merged if they do not pass CI/CD
+
+#### `release`
+
+- release is our stable branch
+- it is protected and only merged into when we have a fully QA-approved `main` state that we want to release
+- npm packages are released using `release` branch
+- PRs into `release` are forbidden except to update tests, README, Github config, CI/CD or release config.
+- Pushing directly to `release` is forbidden
+- `release` should always satisfy a basic set of regression and scenario tests
+- merging `main` into `release` requires that all automated tests pass and two core team members have approved, one being QA.
+
+### `if-plugin-template` 
+
+- we only maintain a single branch: `main`
+- PRs to `main` can be merged after one approval from core team
+- Pushing directly to `main` is possible but discouraged
+
+
+### `if-docs`
+
+- we only maintain a single branch - `main`
+- PRs to `main` can be merged after one approval from core team
+- Pushing directly to `main` is possible but discouraged
+
+### When can we break our rules?
+
+- `release` branches have the strictest rules. We should never override the process outlined above for `release` branches in any repository.
+- On `main` we can be slightly more flexible. It is acceptable to skip QA for PRs that only change typos, documentation or comments. Any changes to source code or tests should be QA approved before merge.
+- In emergency scenarios where an urgent hotfix is required it might be required to skip QA review on `main` branches - this should only happen with QA authorization so QA can retroactively test as soon as possible.
+
+## DCO
+
+We require contributors to conform to the DCO agreement on our repositories. This means either signing commits or explicitly adding a DCO commit message. This ensures all contributors agree to the conditions imposed by our licenses and adhere to our expected practices. The DCO must be satisfied in order to PRs to be merged.
+
+## Commits
+
+Commits are expected to conform to the [conventional-commits](https://www.conventionalcommits.org/en/v1.0.0/) syntax.
+Commits are expected to be signed and have descriptive commit messages.
+We might ask people to provide new messages in some circumstances or to break their PRs into smaller logical units.
+
+## PR triage
+
+We run a weekly PR triage call on Thursdays. The most important outcome of this call is to examine open PRs and issues across all the IF repositories and determine which ones include changes that we might want to merge. This initial sift for changes that are or are not aligned with our goals for the IF should be prioritized above technical comments and fixes.
+
+Some reasons why a PR might not pass triage:
+
+- changes are not aligned with our vision for IF
+- we do not see a strong reason for making a change
+- changes are obviously technically incorrect
+- changes are too large to properly review (e.g. covering too many files)
+- too many changes are made in too few commits
+- commit messages are ambiguous
+- PR description is too short, vague or imprecise
+- PR would for some other reason take too long for core team to assess
+- PR makes changes that do not conform to our license
+- PR makes use of a third-party API or dataset in an illegitimate way (e.g. exposing data that should be paywalled)
+
+After a PR has passed triage, it can be assigned to a core team member to review. Developer review precedes QA review. Community PRs (PRs raised from outside the core team) will *always* go through a full QA vetting procedure before being merged.
+
+We intend to respond to new PRs and issues within 3 days of the ticket being opened, even if only with a brief message thanking the OP and explaining the triage process.
+
+
+## Labels
+
+```
+//review status labels 
+awaiting-triage 
+triage-pass 
+awaiting-review 
+review-pass 
+awaiting-qa 
+qa-pass 
+changes-needed 
+
+//change type labels 
+fix 
+feature 
+docs 
+package 
+other 
+
+// size labels 
+small 
+medium 
+large 
+
+// priority labels 
+high-priority 
+med-priority 
+low-priority 
+
+//delay explanation labels 
+abandoned 
+blocked 
+backlogged
+
+// other labels
+project-management
+agenda
+discussion
+help-wanted
+good-first-issue
+```
+
+Each PR is expected to have one label from each category (except `other`) assigned to it at all times.
+
+
+## Releases
+
+We aim to release fortnightly, every other Tuesday. We release npm packages for `if`, `if-plugins`, `if-unofficial-plugins`, and `if-plugin-template`.
+
+## Hotfixes
+
+We will hotfix by raising PRs into `release` when necessary. These PRs require sign-off by a core developer and our QA engineer. 
+
+If more than two hotfixes are required on a particular release, the team will call a spike meeting to determine the causes of the bugs, identify any changes required to our QA process and determine next steps for fixing the release. 
+
+Hotfixes on release can be merged back into `main` when they have been fully QA tested.
+
+We intend for hotfixes to be as infrequent as possible.