added some first contributing guidelines and changed the config skeleton

README.md

@@ -146,8 +146,7 @@ machine. The only technically required file in there is `configuration.nix`. So
 
 A good skeleton is probably:
 ```
-flake-inputs:
+{config, pkgs, lib, flake-inputs, ... }: {
-{config, pkgs, lib, ... }: {
 
 imports = [
   ./hardware-configuration.nix
@@ -170,6 +169,10 @@ In your hardware
 configuration you should basically only write you filesystem layout and your hostPlatform. The bootloading stuff
 is already taken care of by `../../roles`.
 
+The `flake-inputs` argument is optional, but you can use it if you need to get a hold of the flake inputs,
+else this is a complete normal nixos system configuration module (with a lot of settings already imorted
+from `../../roles`).
+
 As of moment of writing `network.nix` should contain ip, nameserver and default gateway setup. As parts of
 this is constant across all systems and will undergo refactor soon.
 
@@ -278,3 +281,29 @@ something like this:
 {lib, pkgs, config, ...} :
 <module code >
 ```
+
+# Contributing
+
+Like with all FS projects, you are welcome to contribute. Work is done usually by the person that is most annoyed
+by the circumstances or by the person that didn't run fast enough. So we are happy if we get help. That doesn't
+mean that we don't need to have some level of quality, people after us needs to work with it. It is live infrastructure
+and downtime hurts someone (and in the wrong moment even really bad (Matheball ticket sales for example).
+
+So here are some Guidelines.
+
+## Coding style and linting.
+If you run `nix check` there are automated checks in place, please make sure to pass them.
+There is also a code autoformatter (`alejandra`) incorporated into those. You can also install
+them into your local git repository as pre-commit hooks, and setting up a shell that has
+even more tooling by running `nix develop`. That will give you a bash in which you can run
+all the checks manually `pre-commit run -a`. This will also run the autoformatter.
+
+## Process for submitting changes
+
+1. If it is something bigger, please open an issue first describing what and why you want to do something.
+   If it is just something small, skip this step.
+2. Fork the repo and implement your changes in a branch on your fork. Afterwards open a pull request (possibly mentioning the issue).
+   Against the main branch.
+   - Your branch should be based on an up to date version of main, if it is not consider rebasing.
+3. You will need to find someone with the proper rights to approve of your changes, but most of the time there will be request
+   for changes first.