Merge branch 'develop' into autobots

.github/ISSUE_TEMPLATE/request_for_comments.md

@@ -0,0 +1,58 @@
+---
+name: Request for comments
+about: Request for comments discussion
+
+---
+# (RFC title goes here)
+
+## Summary
+
+> One paragraph explanation of the change.
+
+## Motivation
+
+> Why are we doing this? What use cases does it support? What is the expected
+outcome?
+
+## Design Detail
+
+> This is the bulk of the RFC.
+
+> Explain the design in enough detail for somebody
+familiar with the infrastructure to understand. This should get into specifics and corner-cases,
+and include examples of how the service is used. Any new terminology should be
+defined here.
+
+## Drawbacks
+
+> Why should we *not* do this? Please consider the impact on users,
+on the integration of this change with other existing and planned features etc.
+
+> There are tradeoffs to choosing any path, please attempt to identify them here.
+
+## Rationale and Alternatives
+
+> Why is this design the best in the space of possible designs?
+
+> What other designs have been considered and what is the rationale for not choosing them?
+
+> What is the impact of not doing this?
+
+
+## Prior Art
+
+Discuss prior art, both the good and the bad, in relation to this proposal. A few examples of what this can include are:
+
+> How other services / infrastructures in the same domain have solved this problem.
+
+> Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background.
+
+This section is intended to encourage you as an author to think about the lessons from other organisations, provide readers of your RFC with a fuller picture. If there is no prior art, that is fine - your ideas are interesting whether they are brand new or if it is an adaptation from other services.
+
+## Unresolved questions
+
+> What parts of the design do you expect to resolve through the RFC process before this gets merged?
+
+> What parts of the design do you expect to resolve through the implementation of this feature before stabilisation?
+
+> What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?

.github/lock.yml

@@ -0,0 +1,38 @@
+# Configuration for Lock Threads - https://github.com/dessant/lock-threads-app
+
+# Number of days of inactivity before a closed issue or pull request is locked
+daysUntilLock: 90
+
+# Skip issues and pull requests created before a given timestamp. Timestamp must
+# follow ISO 8601 (`YYYY-MM-DD`). Set to `false` to disable
+skipCreatedBefore: false
+
+# Issues and pull requests with these labels will be ignored. Set to `[]` to disable
+exemptLabels: []
+
+# Label to add before locking, such as `outdated`. Set to `false` to disable
+lockLabel: false
+
+# Comment to post before locking. Set to `false` to disable
+lockComment: >
+  This thread has been automatically locked since there has not been
+  any recent activity after it was closed. Please open a new issue for
+  related bugs.
+
+# Assign `resolved` as the reason for locking. Set to `false` to disable
+setLockReason: true
+
+# Limit to only `issues` or `pulls`
+# only: issues
+
+# Optionally, specify configuration settings just for `issues` or `pulls`
+# issues:
+#   exemptLabels:
+#     - help-wanted
+#   lockLabel: outdated
+
+# pulls:
+#   daysUntilLock: 30
+
+# Repository to extend settings from
+# _extends: repo

.github/pull_request_template.md

@@ -0,0 +1,8 @@
+**Describe the PR**
+A clear and concise description of the PR.
+
+**Related Issues/PRs**
+A clear and concise description of what you expected to happen.
+
+**Additional context**
+Add any other context about the problem here.

CONTRIBUTING.md

@@ -5,35 +5,4 @@
 Please read the [Developer Certificate of Origin](./dco.md) before contributing.
 The project is licensed under MIT.
 
-### Git Commit Messages
-
-* Use the present tense ("Add feature" not "Added feature")
-* Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
-* Limit the first line to 72 characters or less
-* Reference issues and pull requests liberally
-* Consider starting the commit message with an applicable emoji :smiley: :
-    * :art: `:art:` when improving the format/structure of the code
-    * :rocket: `:rocket:` when improving performance
-    * :bulb: `:bulb:` new idea
-    * :books: `:books:` To add new reference
-    * :construction: `:construction:` work in progress
-    * :computer: `:computer:` when adding feature
-    * :heavy_minus_sign: `:heavy_minus_sign:` when removing feature
-    * :non-potable_water: `:non-potable_water:` when plugging memory leaks
-    * :pencil2: `:pencil2:` when writing docs
-    * :penguin: `:penguin:` when fixing something on Linux
-    * :apple: `:apple:` when fixing something on macOS
-    * :checkered_flag: `:checkered_flag:` when closing pull requests
-    * :bug: `:bug:` when fixing a bug
-    * :fire: `:fire:` when removing code or files
-    * :green_heart: `:green_heart:` when fixing the CI build
-    * :dart: `:dart:` when adding tests
-    * :lock: `:lock:` when dealing with security
-    * :arrow_up: `:arrow_up:` when upgrading dependencies
-    * :arrow_down: `:arrow_down:` when downgrading dependencies
-    * :speaker: `:speaker:` when adding logging
-    * :mute: `:mute:` when reducing logging
-    * :shirt: `:shirt:` when removing linter warnings
-    * :hammer: `:hammer:` Refactor
-
-
+We appreciate your contribution and suggest following our [developer guidelines](https://mpm.cb-geo.com/#/code/developer)