Update Contribution Documentation

[codello]

What does this PR do?

This PR updates the documentation and tools to help people make better contributions to this project. This includes:

• Issue templates
• A CONTRIBUTING.md guide
• A Code of Conduct

Closes Issue(s)

None, but #85 is related.

Motivation

The subject of issue templates has come up in #73. In order to help new contributors understand the processes in this repo I also started to write a contribution guide.

Additional Notes

In the current state this PR contains changes that are still under active discussion in #85.

[marwin89]

@codello thanks for all the work. This is a really professional contribution.

I actually agree with all changes: Contribution Guide, Code of Conduct, ReadMe and Issue Templates ✅ If I remember where we started with the format project in 2023 this is definitely an improvement in many ways.

I hope that there will be soon enough discussion and feedback. I'd like to see this PR merged in May.

[Baklap4]

I’d like to propose that we keep the website in the main branch instead. Here’s why:

• 📚 The website is the official representation of the spec — it reflects the latest stable state and should live alongside the source of truth.

• 🔄 Easier to keep in sync — when the spec changes, updates to the site can be made and reviewed together in the same pull request.

• 👀 Clearer for contributors — main remains the go-to branch for both the spec and how it’s presented.

• ⚙️ Simplifies tooling and deployment — e.g., GitHub Pages or CI workflows often expect site content on main or in specific folders.

• 🕰️ Preserves context — commits show both content and presentation changes together, helping with historical traceability.

Open to refining the workflow further, but I think keeping the website on main is the most practical and transparent approach.

Personally, I think that if a decision has been made and it results in a new revision of the documents, any required changes to the website should be included in the same change. Preferably, the website won’t need updating at all and can just reference the correct version files — but that’s something to be addressed further in #41.

Happy to hear thoughts, but I think keeping everything on main offers the clearest and most maintainable workflow.

[codello]

I finally found the time to revisit this PR. I'm sorry for the delay. I'm marking this PR as ready for review now.

Those are very good points @Baklap4. Especially Clearer for contributors is very convincing. I have updated the PR accordingly.
The original reason for the separate branch was that I would like to have the option to make changes to the website without needing to publish all pending changes to the specification. I'm still unsure about the best way to do that but I agree that the separate branch gets too confusing.

The latest state of the PR includes a different proposal:

Non functional changes can be submitted via a PR that directly targets the main branch. The same set of changes should then be merged into the develop branch.

What do you think of that? This could be semi-automated via GitHub Actions by automatically creating a PR from main back to develop if something is merged into main from a different branch.

---

A somewhat related open question is that I would really like to be able to publish different versions of the spec independently of each other. I don't have a good solution for that yet, but maybe this isn't as much of a problem as I think