Lacking of a contributing guide

[SweetSea-ButImNotSweet]

One of the rare issues where I actively choose not to use templates to write request and I know what I'm doing

Suggestion

Techmino currently lacks a common set of guidelines which sometimes leads to code contributors writing code in the wrong format or editing files they shouldn't be

How to fix it: create a set of rules and write them in a CONTRIBUTING.md file, then add a link to the README.md file

Draft:

Me:

• List any issues you want to close in your PR title or PR description, reference this: https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue
• Unless the issue is Action related or you are asked to, avoid editing ./github
• Follow the code format written in here: https://github.com/26F-Studio/Techmino/wiki/Coding-Standard
• Add placeholders to all translations, if possible
• Do not change the version number, MrZ will change it himself when a new version is released
• Avoid modifying git related files like .gitignore (unless you know what you are doing and you are trying to solve a git related issue that may occur to others, e.g. exclude the .neovim folder from being added)

Electra:

1. If you are looking for things to add, you can look through the issue page on GitHub for ideas.
2. Create a fork of Techmino on your own github account.
3. We recommend creating a separate branch on that for each change you're working on, so if you end up doing multiple things they can be separated. For instance your git should look like
   upstream (26FStudio/Techmino)
   <-
   origin (electraminer/Techmino) main
   <-
   featureBranch1, featureBranch2, ...
   (please do not copy and paste this, this is a really bad explanation just meant to get the point across, you should make this a decent explanation for someone who is new to open source stuff ideally)
4. Implement the features you want on your own branch. If you want to make a new gamemode, start by looking at the eventSets directory for existing examples. The modes folder generally will link specific eventSets with configurations for different variants of the same mode.
5. Test the features thoroughly. You don't need to write unit tests, but you should check that things work, and look for edge cases. If there's anything broad you changed like stuff in player.lua, you should probably test related modes to make sure nothing broke.
6. If you added any new text, you should do this by referring to text in the translation files rather than hardcoding it. Add placeholders for this text in all of the translation files, these can be filled in by translators later.
7. Merge upstream (26FStudio/techmino main) into your branch to make sure you have compatibility with the latest features.
8. Make sure that your version file (version.lua) is the exact same as the one on the upstream you just merged from. Even if your changes will constitue a major update, leave this the same and MrZ will increase the version number when accepting the PR.
9. Collect any GitHub issues you fixed. Even if you didn't purposefully fix any, search them to see if there are any that are similar to what you worked on.
10. Create a pull request. Mark any issues you wish to resolve this way as resolved.

Even this is way too not-specific in parts
But it gives the general flow of it
This should be a guide to help people new to this to know how they're supposed to set up their github and what to watch out for
especially if they're not like amazingly familiar with Git (i mean like... they know how to commit/push/pull but maybe don't understand exactly how they should set up a project or how pull requests work.)
not just a list of things we can complain about

[SweetSea-ButImNotSweet]

@MrZ626 ehm this must get your feedbacks so...

[ImpleLee]

Most importantly, change only the code that needs changing.