Remove style guide and first contribution sections

CONTRIBUTING.md

@@ -6,7 +6,7 @@ Welcome to Puter, the open-source distributed internet operating system. We're e
 
 # Report bugs
 
-Before reporting a bug, please check our [the issues on our GitHub repository](https://github.com/HeyPuter/puter/issues) to see if the bug has already been reported. If it has, you can add a comment to the existing issue with any additional information you have.
+Before reporting a bug, please check [the issues on our GitHub repository](https://github.com/HeyPuter/puter/issues) to see if the bug has already been reported. If it has, you can add a comment to the existing issue with any additional information you have.
 
 If you find a new bug in Puter, please [open an issue on our GitHub repository](https://github.com/HeyPuter/puter/issues/new). We'll do our best to address the issue as soon as possible. When reporting a bug, please include as much information as possible, including:
 
@@ -45,48 +45,7 @@ If you'd like to contribute code to Puter, you need to fork the project and subm
 
 We'll review your pull request and work with you to get your changes merged into the project.
 
-## Style Changes
-
-### Identify Project-Level Conventions
-
-Please try to keep code style consistent with other source files in the area you are
-changing. We are a monorepo, which means there are multiple projects in this repository
-which may have different style conventions. For example:
-- Most code in `src/backend` follows [FOAM's whitespace convention](https://github.com/kgrgreer/foam3/blob/development/doc/guides/StyleGuide.md) for control structures.
-  While it's not a well-known or popular convention, it gives the visual cortex a bit
-  more room to breath when reading or skimming code.
-- Most code in `src/gui` follows standard whitespace.
-
-### Separate PRs for Formtting and Code
-
-**We recommend disabling auto-formatters**. We are a monorepo, so despite any efforts to have
-auto-formatters do what we expect for all source files, **they will not**. What they will
-do is create huge number of formatting changes that we don't want and make the functional
-changes within your PR almost impossible to review. Linters and
-formatters work well when all the code is cut from the same shape of cookie cutter, and
-that does not work well for us; we are concerned with more important things like unifying
-logic and separating data from code.
-
-Note: despite the statement above about auto-formatters, we will accept PRs that make
-auto-formatters less likely to break conventions, as long as these configurations reflect
-the fact that different projects under the monorepo may have different conventions.
-
-If you're changing code, **feel free to update the formatting of the code you are changing**,
-especially in cases when it makes your changes easier to review.
-
-In a PR that makes code changes, **DO NOT** include style changes in code that you are
-not making functional changes to.
-
-We will accept PRs that update style and no not include code changes. For example, you can
-use a formatter to make one or more source files consistent with the conventions of the
-project they reside under. **DO NOT** include functional changes in these PRs. It is easier
-to review style PRs separately because we can use javascript parsers to verify that there
-are no functional changes and then simply skim though the code and see if it "looks better".
-
-
-## Your first code contribution
-
-We maintain a list of issues that are good for first-time contributors. You can find these issues by searching for the [`good first issue`](https://github.com/HeyPuter/puter/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) label in our [GitHub repository](https://github.com/HeyPuter/puter). These issues are designed to be relatively easy to fix, and we're happy to help you get started. Pick an issue that interests you, and leave a comment on the issue to let us know you're working on it.
+<br>
 
 ## Documentation for Contributors