docs: add new github docs

.github/CODEOWNERS

@@ -0,0 +1 @@
+* @CelticBoozer

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,116 @@
+# Code of Conduct - dotfiles
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to make participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+- Demonstrating empathy and kindness toward other people
+- Being respectful of differing opinions, viewpoints, and experiences
+- Giving and gracefully accepting constructive feedback
+- Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+- Focusing on what is best not just for us as individuals, but for the
+  overall community
+
+Examples of unacceptable behavior include:
+
+- The use of sexualized language or imagery, and sexual attention or
+  advances
+- Trolling, insulting or derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or email
+  address, without their explicit permission
+- Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate,
+threatening, offensive, or harmful.
+
+Project maintainers have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will
+communicate reasons for moderation decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official e-mail address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement at <[email protected]>.
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series
+of actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or
+permanent ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior, harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within
+the community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant](https://contributor-covenant.org/),
+version [1.4](https://www.contributor-covenant.org/version/1/4/code-of-conduct/code_of_conduct.md)
+and [2.0](https://www.contributor-covenant.org/version/2/0/code_of_conduct/code_of_conduct.md),
+and was generated by [contributing-gen](https://github.com/bttger/contributing-gen).

.github/CONTRIBUTING.md

@@ -0,0 +1,211 @@
+# Contributing to dotfiles
+
+First off, thanks for taking the time to contribute! ❤️
+
+All types of contributions are encouraged and valued.
+See the [Table of Contents](#table-of-contents) for different ways to help
+and details about how this project handles them. Please make sure to read the
+relevant section before making your contribution. It will make it a lot easier
+for us maintainers and smooth out the experience for all involved. The
+community looks forward to your contributions. 🎉
+
+> And if you like the project, but just don't have time to contribute, that's
+  fine. There are other easy ways to support the project and show your
+  appreciation, which we would also be very happy about:
+>
+> - Star the project
+> - Tweet about it
+> - Refer this project in your project's readme
+> - Mention the project at local meetups and tell your friends/colleagues
+
+## Table of Contents
+
+- [Code of Conduct](#code-of-conduct)
+- [I Have a Question](#i-have-a-question)
+- [I Want To Contribute](#i-want-to-contribute)
+  - [Reporting Bugs](#reporting-bugs)
+  - [Suggesting Enhancements](#suggesting-enhancements)
+- [Styleguides](#styleguides)
+  - [Commit Messages](#commit-messages)
+  - [Code style](#code-style)
+
+## Code of Conduct
+
+This project and everyone participating in it is governed by the
+[dotfiles Code of Conduct](https://github.com/CelticBoozer/dotfiles/blob/master/.github/CODE_OF_CONDUCT.md).
+By participating, you are expected to uphold this code. Please report
+unacceptable behavior to <[email protected]>.
+
+## I Have a Question
+
+Before you ask a question, it is best to search for existing [Issues](https://github.com/CelticBoozer/dotfiles/issues)
+and [Discussions](https://github.com/CelticBoozer/dotfiles/discussions)
+that might help you. In case you have found a suitable issue or discussion and
+still need clarification, you can write your question in this issue. It is also
+advisable to search the internet for answers first.
+
+If you then still feel the need to ask a question and need clarification, we
+recommend the following:
+
+- Open new or join existing an [Discussions](https://github.com/CelticBoozer/dotfiles/discussions).
+- Provide as much context as you can about what you're running into.
+- Provide project and platform versions (lua, neovim, etc), depending on what
+  seems relevant.
+
+We will then take care of the issue or discussion as soon as possible.
+
+## I Want To Contribute
+
+> ### Legal Notice
+>
+> When contributing to this project, you must agree that you have authored 100%
+  of the content, that you have the necessary rights to the content and that the
+  content you contribute may be provided under the project license.
+
+### Reporting Bugs
+
+#### Before Submitting a Bug Report
+
+A good bug report shouldn't leave others needing to chase you up for more
+information. Therefore, we ask you to investigate carefully, collect information
+and describe the issue in detail in your report. Please complete the following
+steps in advance to help us fix any potential bug as fast as possible.
+
+- Make sure that you are using the latest version.
+- Determine if your bug is really a bug and not an error on your side e.g. using
+  incompatible environment components/versions.
+- To see if other users have experienced (and potentially already solved) the same
+  issue you are having, check if there is not already a bug report existing for
+  your bug or error in the [bug tracker](https://github.com/CelticBoozer/dotfiles/issues?q=label%3Abug).
+- Also make sure to search the internet (including Stack Overflow) to see if users
+  outside of the GitHub community have discussed the issue.
+- Collect information about the bug:
+  - Stack trace (Traceback)
+  - Version of the interpreter, compiler, SDK, runtime environment, package
+    manager, depending on what seems relevant.
+  - Possibly your input and the output
+  - Can you reliably reproduce the issue? And can you also reproduce it with
+    older versions?
+
+#### How Do I Submit a Good Bug Report?
+
+> You must never report security related issues, vulnerabilities or bugs including
+  sensitive information to the issue tracker, or elsewhere in public. Instead
+  sensitive bugs must be sent by email to <[email protected]>.
+
+We use GitHub issues to track bugs and errors. If you run into an issue with
+the project:
+
+- Open an [Issue](https://github.com/CelticBoozer/dotfiles/issues/new).
+  (Since we can't be sure at this point whether it is a bug or not, we ask
+  you not to talk about a bug yet and not to label the issue.)
+- Explain the behavior you would expect and the actual behavior.
+- Please provide as much context as possible and describe the *reproduction steps*
+  that someone else can follow to recreate the issue on their own. This usually
+  includes your code. For good bug reports you should isolate the problem and
+  create a reduced test case.
+- Provide the information you collected in the previous section.
+
+Once it's filed:
+
+- The project team will label the issue accordingly.
+- A team member will try to reproduce the issue with your provided steps. If
+  there are no reproduction steps or no obvious way to reproduce the issue, the
+  team will ask you for those steps and mark the issue as `needs-repro`. Bugs
+  with the `needs-repro` tag will not be addressed until they are reproduced.
+
+### Suggesting Enhancements
+
+This section guides you through submitting an enhancement suggestion for
+dotfiles, **including completely new features and minor improvements to
+existing functionality**. Following these guidelines will help maintainers
+and the community to understand your suggestion and find related suggestions.
+
+#### Before Submitting an Enhancement
+
+- Make sure that you are using the latest version.
+- Read the [README](https://github.com/CelticBoozer/dotfiles/blob/master/.github/README.md)
+  carefully and find out if the functionality is already covered, maybe by an
+  individual configuration.
+- Perform a search in [Issues](https://github.com/CelticBoozer/dotfiles/issues)
+  and [Discussions](https://github.com/CelticBoozer/dotfiles/discussions)
+  to see if the enhancement has already been suggested. If it has, add a comment
+  to the existing issue instead of opening a new one.
+
+#### How Do I Submit a Good Enhancement Suggestion?
+
+Enhancement suggestions are tracked as [GitHub issues](https://github.com/CelticBoozer/dotfiles/issues)
+and [Discussions](https://github.com/CelticBoozer/dotfiles/discussions).
+
+- Use a **clear and descriptive title** for the issue to identify the suggestion.
+- Provide a **step-by-step description of the suggested enhancement** in as
+  many details as possible.
+- **Describe the current behavior** and **explain which behavior you expected
+  to see instead** and why. At this point you can also tell which alternatives
+  do not work for you.
+- You may want to **include screenshots and animated GIFs** which help you
+  demonstrate the steps or point out the part which the suggestion is related
+  to. You can use [this tool](https://www.cockos.com/licecap/) to record GIFs
+  on macOS and Windows, and [this tool](https://github.com/colinkeenan/silentcast)
+  or [this tool](https://github.com/GNOME/byzanz) on Linux.
+- **Explain why this enhancement would be useful** to most nvim-config users.
+  You may also want to point out the other projects that solved it better and
+  which could serve as inspiration.
+
+## Styleguides
+
+### Commit Messages
+
+1. Type (feat:): Indicates the type of change. Common types include:
+
+- revert: If the commit reverts a previous commit. In the body it should say:
+  `This reverts commit <hash>`.
+- build: Changes that affect the build system or external dependencies (example
+  scopes: gulp, broccoli, npm)
+- ci: Changes to our CI configuration files and scripts (example scopes: Circle,
+  GitHub Actions)
+- feat: A new feature
+- fix: A bug fix
+- docs: Documentation changes
+- style: Changes that do not affect the meaning of the code (white-space,
+  formatting, etc.)
+- refactor: Code changes that neither fix a bug nor add a feature
+- test: Adding or correcting tests
+- chore: Maintenance tasks
+
+<!-- markdownlint-disable-next-line MD029 -->
+2. Short Summary:
+
+- A brief description of what was done, ideally in 50 characters or less.
+
+<!-- markdownlint-disable-next-line MD029 -->
+3. Body:
+
+- Details: An optional section that can provide more context or details
+  about the change, such as what was changed, why it was changed, and how
+  it was done. Each bullet point starts with a verb to make it clear what
+  action was taken.
+
+Guidelines for Writing Good Commit Messages
+
+- Be Clear and Concise: Aim for clarity in your messages. The summary should
+  be brief but descriptive enough to understand the change at a glance.
+- Use the Imperative Mood: Write the summary as if you're giving a command,
+  e.g., "Add feature" instead of "Added feature" or "Adds feature."
+- Explain Why, Not Just What: If necessary, explain the reasoning behind the
+  change or what it accomplishes, especially if it's not immediately obvious.
+- Limit Line Length: Keep the summary line to around 50 characters if
+  possible. The body can be more flexible but should still be concise.
+- Separate Summary from Body with a Blank Line: This makes the message
+  easier to read.
+
+For the full guide, see [here](https://www.conventionalcommits.org/en/v1.0.0/).
+
+### Code style
+
+All code must be linted and formatted according to the rules. A list of linters,
+formatters and their configurations can be found in the [repository](https://github.com/CelticBoozer/lint-format-config).
+
+## Attribution
+
+This guide is based on the **contributing-gen**. [Make your own](https://github.com/bttger/contributing-gen)!