docs: update pull request guidelines

We're going to start accepting pull requests more readily, but the
documentation on this topic required some updates to align with the new
policies enforced by recent CI changes.

Signed-off-by: Jacob Howard <[email protected]>

Author: xenoscopic

.github/pull_request_template.md

@@ -1,25 +1,20 @@
 <!--
 
-Please note: Mutagen is currently in a state of high code churn and I simply
-don't have the time to review pull requests. GitHub unfortunately doesn't allow
-me to disable pull requests, but please be aware that they will probably be left
-on the back burner for the foreseeable future. Sorry :-(
+Thanks for the pull request! Before submitting, please ensure that your commits
+adhere to the guidelines in CONTRIBUTING.md. Pull requests that do not meet
+these guidelines cannot be merged.
 
-– Jacob
+If you're not quite ready for a final review, please feel free to open a draft
+pull request.
 
+-->
 
-In any case, before taking the time to implement a change or feature, please
-discuss the proposed change on the Mutagen Community Slack Workspace:
-
-https://mutagen.io/slack
-
+**What does this pull request do and why is it needed?**
 
-If it *does* make sense to open a pull request, please adhere to the
-contributing guidelines:
+**Which issue(s) does this pull request address (if any)?**
 
-https://github.com/mutagen-io/mutagen/blob/master/CONTRIBUTING.md
+(Optional - feel free to delete this section)
 
-They're not too onerous. Pull requests that don't follow these guidelines will
-simply be closed.
+**Any other notes for the review process?**
 
--->
+(Optional - feel free to delete this section)

CONTRIBUTING.md

@@ -28,32 +28,24 @@ email us at [[email protected]](mailto:[email protected]).
 
 ## Pull requests
 
----
-
-**Please note:** I'm still working on formulating Mutagen's pull request policy.
-I'm trying to make it as simple as possible while ensuring code quality and
-project longevity. I very much want community contributions, but I haven't had
-an extensive amount of time to review pull requests or formulate a review
-process. I'm working on changing this, so I ask you to bear with me for just a
-little longer. Thank you!
-
-– Jacob
-
----
-
 Before taking the time to implement a change or feature, please discuss the
 proposed change on the
+[issue tracker](https://github.com/mutagen-io/mutagen/issues) or
 [Mutagen Community Slack Workspace](https://mutagen.io/slack).
 
 If it *does* make sense to open a pull request, please adhere to the following
-guidelines. Pull requests that don't follow these guidelines will simply be
-closed.
+guidelines. Pull requests that don't follow these guidelines will be closed.
 
 
-### Contributor License Agreement
+### Developer Certificate of Origin
 
-Mutagen pull requests will require a Contributor License Agreement, though the
-exact form of this agreement is still being decided.
+Pull requests to Mutagen must be submitted under the terms of the
+[Developer Certificate of Origin (DCO)](DCO). In order to accept a pull request,
+we require that you sign-off all commits in the pull request using the `-s` flag
+with `git commit` to indicate that you agree to the terms of the DCO. You must
+also
+[cryptographically sign](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits)
+your commits to verify your DCO sign-off.
 
 
 ### Code guidelines
@@ -62,33 +54,40 @@ In order to ensure that Mutagen's codebase remains clean and understandable to
 all developers, we kindly request that:
 
 - Code adheres to Go style guidelines, including those in
-  [Effective Go](https://golang.org/doc/effective_go.html) and the
+  [Effective Go](https://go.dev/doc/effective_go) and the
   [Go Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments)
 - All code be `go fmt`'d
-- Comments be wrapped at 80 columns (with exceptions for long strings like URLs)
-- Comments be used to break up code (see existing code for examples) and be
-  composed of full and complete sentences
-- New code include full test coverage
-
-Basically, when in doubt, new code should share the same style as the
-surrounding code.
+- New code matches the style and structure of its surrouding code (unless a full
+  refactor/rewrite of a package is being performed)
+- Comments be wrapped at 80 columns (with exceptions for long strings like URLs
+  that can't be wrapped)
+    - Code does not need to be wrapped at 80 lines, but please do try to keep
+      lines to a reasonable length
+- Comments be used to break up code blocks and be composed of full and complete
+  sentences
+  ([example](https://github.com/mutagen-io/mutagen/blob/67a94630f3f6ccf7fe7246b30ad75e68326ca2d1/pkg/synchronization/core/scan.go#L142-L240))
+- Imports be grouped by module, with standard library packages in the first
+  group ([example](https://github.com/mutagen-io/mutagen/blob/master/cmd/mutagen/forward/create.go#L3-L25))
+- Non-trivial changes include full test coverage
 
 
 ### Commit guidelines
 
 To help keep source control logs readable and useful, we also ask that all
-commits have well-formatted commit messages composed of a single subject line of
-50-70 characters, followed by a blank line, and finally the full, correctly
-punctuated commit message (also wrapped to 80 lines). We ask the same for the
-pull request message itself.
+commits have well-formatted commit messages that follow the
+[Go commit message guidelines](https://go.dev/doc/contribute#commit_messages).
+The component in the first line must be one of those listed in
+`scripts/ci/commitlint/config.json` and lines must not exceed 72 characters in
+length.
 
 Here's an example of a good message:
 
-    Modified synchronization controller state locking
+    sync: modified controller state locking
 
-    This commit modifies the synchronization controller's state locking to take
-    into account changes that can occur during shutdown. It requires that the
-    synchronization Goroutine hold the state lock until fully terminated.
+    This commit modifies the synchronization controller's state locking to
+    take into account changes that can occur during shutdown. It requires
+    that the synchronization Goroutine hold the state lock until fully
+    terminated.
 
     Fixes #00000
 

DCO

@@ -0,0 +1,37 @@
+Developer Certificate of Origin
+Version 1.1
+
+Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
+1 Letterman Drive
+Suite D4700
+San Francisco, CA, 94129
+
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
+
+
+Developer's Certificate of Origin 1.1
+
+By making a contribution to this project, I certify that:
+
+(a) The contribution was created in whole or in part by me and I
+    have the right to submit it under the open source license
+    indicated in the file; or
+
+(b) The contribution is based upon previous work that, to the best
+    of my knowledge, is covered under an appropriate open source
+    license and I have the right under that license to submit that
+    work with modifications, whether created in whole or in part
+    by me, under the same open source license (unless I am
+    permitted to submit under a different license), as indicated
+    in the file; or
+
+(c) The contribution was provided directly to me by some other
+    person who certified (a), (b) or (c) and I have not modified
+    it.
+
+(d) I understand and agree that this project and the contribution
+    are public and that a record of the contribution (including all
+    personal information I submit with it, including my sign-off) is
+    maintained indefinitely and may be redistributed consistent with
+    this project or the open source license(s) involved.