Add documentation for committing changes (#278)

Replaces documentation on ADRs which are not currently used.

docs/3-Contribution/4-Architecture-decisions.md

@@ -1,43 +0,0 @@
-# Architecture decisions
-
-Architecturally significant changes to this project are documented as a collection of records. Documents are numbered sequentially and monotonically. If a decision is reversed, we will keep the old one around, but mark it as superseded (it's still relevant to know that it was the decision, but is no longer the decision).
-
-If you'd like to make a significant change to this program, copy the template below and submit a PR which explains your proposal. Your proposal may accompany a working prototype, but significant decisions should be documented before there is significant development.
-
-# Template
-
-## A Title Which Summarizes The Decision
-
-### Authors
-
-- Your Name ([@username](https://github.com/marpaia))
-
-> List all people that have contributed to the decision and can speak authoritatively about some critical aspect it.
-
-### Status
-
-Accepted (March 15, 2018)
-
-> This should be one of:
-> - Proposal (the decision is being proposed and discussed (ie: in a PR))
-> - Accepted (the decision has been agreed upon and is the current adopted decision)
-> - Superseded (the decision has been superseded by a newer decision (include a link to the new decision))
-
-### Context
-
-The context section outlines the set of conditions which have brought you here. You should outline what it is that you're talking about and why this decision is being documented. Enumerate the context you have which has gone into this decision so that others understand not only the decision itself but why it was the best decision given the context of the situation.
-
-If significant conversation on this topic happened in Slack or in a meeting, do your best to summarize the context. Include links to Slack logs, GitHub issues, Pull Request discussions, etc.
-
-### Decision
-
-Summarize the decision that has been made and it's immediate practical implications. This section should be brief. Save the story-telling for Context and Consequences.
-
-
-### Consequences
-
-The closing section of the document explains what the consequences of this decision will be.
-
-Explain what's going to happen immediately. If this is a new approach to an existing problem, perhaps a set of refactors will need to take place. If a new programming pattern is being agreed upon, perhaps developers will need to be able to reference some code snippets.
-
-You should also explain the long-term maintainability and scale properties of the decision. Often times, a decision will introduce some new advantage, but nothing in life is without compromise. Explain what we should watch out for as your decision is accepted. What are bottlenecks that you foresee with your solution. How will it fall over? We think about this during the decision making process so that our decisions have as few unexpected consequences as possible after they're adopted.

docs/3-Contribution/4-Commiting-Changes.md

@@ -0,0 +1,47 @@
+# Committing Changes
+- [External Contributors](#external-contributors)
+- [Pull Requests](#pull-requests)
+  - [Merging Pull Requests](#merging-pull-requests)
+  - [Commit Messages](#commit-messages)
+
+## External Contributors
+
+Fleet does not require a CLA for external contributions. External contributors are encouraged to submit Pull Requests (PRs) following the instructions presented in this document.
+
+For significant changes, it is a good idea to discuss the proposal with the Fleet team in an Issue or in #fleet on [osquery Slack](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw) before commencing development. This helps ensure that your PR will be merged.
+
+Please keep in mind that any code merged to the Fleet repository becomes the responsibility of the Fleet team to maintain. Because of this, we are careful to ensure any contributions fit Fleet's vision, are well-tested, and high quality. We will work with contributors to ensure the appropriate standards are met.
+
+## Pull Requests
+
+Each developer (internal or external) creates a fork of the Fleet repository, committing changes to a branch within their fork. Changes are submitted by PR to be merged into Fleet.
+
+GitHub Actions automatically runs testers and linters on each PR. Please ensure that these checks pass. Checks can be run locally as described in [2-Testing.md](./2-Testing.md).
+
+For features that are still in-progress, the Pull Request can be marked as a "Draft". This helps make it clear which PRs are ready for review and merge.
+
+Internal contributors and reviewers are asked to apply the appropriate Labels for PRs. This helps with project management.
+
+PRs that address Issues should include a message indicating that they fix or close the Issue (eg. `Fixes #42`). GitHub uses this to automatically close the associated Issue when the PR is merged.
+
+### Merging Pull Requests
+
+In general, PRs should pass all CI checks and have at least one approving review before merge.
+
+Failing CI checks can be allowed if the failure is clearly unrelated to the changes in the PR. Please leave a comment indicating this before merging.
+
+For simple changes in which the internal author is confident, it can be appropriate to merge without an approving review.
+
+In general, we try to allow internal contributors to merge their own PRs after approval. This gives the opportunity for the author to make any final modifications and edit their own commit message.
+
+For external contributors, the merge must be performed by a teammate with merge permissions. Typically this would be the internal reviewer that approves the PR.
+
+### Commit Messages
+
+GitHub is configured to only allow "Squash Merges", meaning each PR (potentially containing multiple commits) becomes a single commit for merge. Occasionally it may be appropriate to "Rebase Merge" a complex PR that is best left as multiple commits. Please discuss within the PR if this seems appropriate.
+
+GitHub will automatically generate a commit title and description based on the commits within the PR. This is often messy and it is good practice to clean up the generated text. Typically, using the PR title and description is a good way to approach this.
+
+Keep in mind that the commit title and description are what developers see when running `git log` locally. Try to make this information helpful!
+
+Keeping to around 80 character line lengths helps with rendering when folks have narrow, tiled terminal windows.

docs/3-Contribution/README.md

@@ -9,8 +9,8 @@ Includes documentation about Fleet's full test suite and integration tests
 ### [Migrations](./3-Migrations.md)
 Information about creating and updating database migrations
 
-### [Architecture decisions](./4-Architecture-decisions.md) 
-Provides a template for making architecturally significant changes to the project
+### [Commiting Changes](./4-Commiting-Changes.md) 
+Contains information about how to merge changes into the codebase
 
 ### [Releasing Fleet](./5-Releasing-Fleet.md) 
 Provides a guide for Fleet's release process