Move uncritical files into `etc/` (#350)

This is mainly just to reduce the amount of files in the project root.
The criteria of what gets into `etc/` are the following:

* The file should not be necessary for building nsxiv. This excludes the
  `icon/*` stuff since that's needed by `window.c`.
* The file shouldn't have any valid reason to stay in the project root.
  This excludes things like `README.md`, `.gitignore` etc.

Reviewed-on: https://codeberg.org/nsxiv/nsxiv/pulls/350
Reviewed-by: explosion-mental <explosion-mental@noreply.codeberg.org>

1 files changed, 0 insertions, 97 deletions

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
deleted file mode 100644
index 93e0552..0000000
--- a/CONTRIBUTING.md
+++ /dev/null
@@ -1,97 +0,0 @@
-Project Scope
--------------
-
-  * Bug fixes and maintenance
-  * Prioritize extensibility and simplicity
-  * Do not make the codebase more complex, keep it simple to hack on
-  * Do not add extra dependency (if we do, add compile time switch to disable it)
-  * New features may be added if it cannot be achieved (easily) via a shell script,
-    doesn't break backwards compatibility and doesn't violate any of the above rules.
-
-Note: Since we aim to be a drop-in replacement for sxiv, we intend to keep all
-sxiv's behaviors/features even in cases where removing them would make the
-code-base simpler.
-
-Also note that (n)sxiv uses `imlib2` for loading images. Thus any request or
-patches for adding support for new image formats should go into
-[imlib2's repo](https://git.enlightenment.org/old/legacy-imlib2) instead.
-
-
-Contribution Guideline
-----------------------
-
-When contributing, make sure:
-
-  * Your contribution falls under nsxiv's scope and aim
-  * You follow the existing code style (see [.editorconfig](.editorconfig))
-  * You open the pull request from a new branch, not from master
-  * To avoid using force pushes, especially for bigger patches. Only use them
-    when there's merge conflicts.
-
-If your contribution is not suitable for general use, it will not be included in nsxiv.
-For changes that are very much up to preference, such as changing values in config.h,
-please do not open a pull request unless you have an objective explanation.
-
-See the [open issues](https://codeberg.org/nsxiv/nsxiv/issues) to find something
-to work on. You can also filter the issues via label:
-
-* [Good first issue](https://codeberg.org/nsxiv/nsxiv/issues?labels=49698):
-  (Easy) Issues which do not require much if any experience.
-* [Up for grabs](https://codeberg.org/nsxiv/nsxiv/issues?labels=49705):
-  (Intermediate) Issues which are free for anyone who wants to pick it up.
-  Might require some experience.
-* [Help wanted](https://codeberg.org/nsxiv/nsxiv/issues?labels=49699):
-  (Intermediate/Experienced) Issues where we require some help.
-
-
-Development workflow for maintainers
-------------------------------------
-
-If we notice you contributing and/or showing interest in issues/pull requests,
-we may invite you to join the nsxiv org as a member. Being a member simply means
-you will be able to approve, disapprove and merge pull requests.
-
-Our workflow regarding pull requests is the following:
-
-  * Code related changes require two approvals, but documentation related
-    changes (e.g. typo) can be merged with just one.
-  * If a pull request has a single approval, no objections and has been open
-    for more than 7 days, then it may be force-merged.
-  * Always prefer squashing when merging. In the case a PR makes more than one
-    significant change, use the "don't squash" tag and rebase instead.
-  * When merging, make sure the commit message is cleaned up properly so that
-    it reflects the current intention of the PR.
-
-For releases, the process is the following:
-
-  * Tag the release with a "vN" tag, where N is the version number. Also set
-    the commit message and tag description for the release commit to "Release
-    version N". Make sure to use an annotated tag.
-  * Update `VERSION` macro in `config.mk`.
-  * Update the changelog (`CHANGELOG.md`):
-    * Include link to the release tarball and add the release date.
-    * Document only the changes or fixes between releases. Don't document
-      changes which never made it into a release.
-    * Use the "Changes" section to document behavior changes since the last
-      release, the "Added" section for new features, and the "Fixes" section
-      for fixed bugs or regressions.
-    * Include pull request IDs with reference style links.
-
-Mirroring to GitHub:
-
-Assuming `origin` is the name of the codeberg remote and `github` is the name
-of the github remote; run the following commands to mirror the codeberg repo to
-github:
-
-```console
-$ git fetch --prune origin
-$ git push --prune github '+refs/remotes/origin/*:refs/heads/*' '+refs/tags/*:refs/tags/*'
-```
-
-The first command updates the local repo and the second command pushes
-everything on `origin` without pushing any of the local branches.
-
-- - -
-
-For mundane development related talks which don't warrant their own issue, use
-the [general discussion](https://codeberg.org/nsxiv/nsxiv/issues/294) thread.