Document & Wiki Contribution Guidelines

[ZynthCode]

Should we draft a simple contribution guideline for both the documents (repo) and the wiki? For example, do we want to always use Pull Requests? It would be helpful to have an agreement in place to keep things organized and avoid ad-hoc changes.

[RakanHowls]

Personally, I think the wiki should be more open than the repo in general. It would be great if someone can draft a contribution guideline for us as a basis for discussions

[RustyBraze]

maybe something like this? It is a kinda of standard template.
Of course, it needs changes and refining!! (this is a conversation starter)

# Contribution Guidelines for Software Guidelines Proposals

Welcome! This repository serves as a collaborative space for shaping new software guidelines to be proposed for conventions. We encourage everyone to contribute their ideas, discuss improvements, and help shape the future of our standards.

To ensure a structured and productive contribution process, please follow the guidelines below.

---

## 📌 General Rules

1. **Be Respectful & Constructive** – Engage in discussions with professionalism and mutual respect.
2. **Ensure Clarity & Relevance** – Proposals should be well-documented, relevant to software standards, and aligned with our goals.
3. **Follow the Submission Format** – Use the structured format for all proposals to maintain consistency.
4. **Avoid Duplicates** – Check existing proposals before submitting a new one to prevent redundancy.
5. **Open Discussions** – Everyone is welcome to provide feedback. Major changes should be discussed before implementation.
6. **Decisions by the Board** – Proposals that gain traction will be reviewed and merged into official regulations by the board.

---

## 📝 How to Propose a New Software Guideline

To submit a new proposal, follow these steps:

1. **Fork the Repository** – Clone this repository and create a new branch for your proposal.
2. **Use the Proposal Template** – Create a new file in the `proposals/` directory and follow the structure below.
3. **Submit a Pull Request (PR)** – Open a PR with a clear title and summary of the proposed changes.
4. **Engage in Discussion** – Address feedback from contributors and reviewers.
5. **Approval & Merging** – If the board approves, your proposal will be merged into the official guidelines.

---

## 🏗️ Proposal Template

When submitting a proposal, copy and paste the following template into your new file: (at the end and github does not like cascating code blocks :D)

---

## 🚀 Reviewing & Approving Proposals

1. **Proposal Submission** – A contributor submits a proposal using the template above.
2. **Initial Review** – The community provides feedback, suggests improvements, and discusses the idea.
3. **Board Evaluation** – Once refined, the board reviews the proposal and votes on its approval.
4. **Merging & Adoption** – If approved, the guideline is merged into the official documentation.

---

## ❓ Questions & Support

For any questions or clarifications, feel free to open a **discussion thread** or reach out to a board member. Let's work together to build better software guidelines!

Happy contributing! 🚀

Template:

# Proposal: [Short Title of the Guideline]
**Author(s):** [Your Name]
**Date Submitted:** [YYYY-MM-DD]
**Status:** [Draft/In Review/Approved]

## 📌 Summary
[A short description of the proposed guideline and why it is needed.]

## 🔍 Problem Statement
[Explain the issue this guideline aims to solve, its relevance, and the impact of not having a guideline in place.]

## ✅ Proposed Solution
[Describe the proposed guideline, how it should be implemented, and any references to industry standards or best practices.]

## 📊 Examples & Use Cases
[Provide practical examples of how the guideline should be applied.]

## 🔄 Alternative Approaches
[List any alternative solutions considered and why they were not chosen.]

## 📢 Community Feedback
[Link to discussions, issues, or feedback from contributors.]

## 📅 Implementation Plan
[If applicable, outline steps for adopting this guideline, including transition plans and possible challenges.]

## 🏁 Conclusion
[A final summary and call to action for adoption.]

[ZynthCode]

maybe something like this? It is a kinda of standard template. Of course, it needs changes and refining!! (this is a conversation starter)

# Contribution Guidelines for Software Guidelines Proposals

Welcome! This repository serves as a collaborative space for shaping new software guidelines to be proposed for conventions. We encourage everyone to contribute their ideas, discuss improvements, and help shape the future of our standards.

To ensure a structured and productive contribution process, please follow the guidelines below.

---

## 📌 General Rules

1. **Be Respectful & Constructive** – Engage in discussions with professionalism and mutual respect.
2. **Ensure Clarity & Relevance** – Proposals should be well-documented, relevant to software standards, and aligned with our goals.
3. **Follow the Submission Format** – Use the structured format for all proposals to maintain consistency.
4. **Avoid Duplicates** – Check existing proposals before submitting a new one to prevent redundancy.
5. **Open Discussions** – Everyone is welcome to provide feedback. Major changes should be discussed before implementation.
6. **Decisions by the Board** – Proposals that gain traction will be reviewed and merged into official regulations by the board.

---

## 📝 How to Propose a New Software Guideline

To submit a new proposal, follow these steps:

1. **Fork the Repository** – Clone this repository and create a new branch for your proposal.
2. **Use the Proposal Template** – Create a new file in the `proposals/` directory and follow the structure below.
3. **Submit a Pull Request (PR)** – Open a PR with a clear title and summary of the proposed changes.
4. **Engage in Discussion** – Address feedback from contributors and reviewers.
5. **Approval & Merging** – If the board approves, your proposal will be merged into the official guidelines.

---

## 🏗️ Proposal Template

When submitting a proposal, copy and paste the following template into your new file: (at the end and github does not like cascating code blocks :D)

---

## 🚀 Reviewing & Approving Proposals

1. **Proposal Submission** – A contributor submits a proposal using the template above.
2. **Initial Review** – The community provides feedback, suggests improvements, and discusses the idea.
3. **Board Evaluation** – Once refined, the board reviews the proposal and votes on its approval.
4. **Merging & Adoption** – If approved, the guideline is merged into the official documentation.

---

## ❓ Questions & Support

For any questions or clarifications, feel free to open a **discussion thread** or reach out to a board member. Let's work together to build better software guidelines!

Happy contributing! 🚀

Template:

# Proposal: [Short Title of the Guideline]
**Author(s):** [Your Name]
**Date Submitted:** [YYYY-MM-DD]
**Status:** [Draft/In Review/Approved]

## 📌 Summary
[A short description of the proposed guideline and why it is needed.]

## 🔍 Problem Statement
[Explain the issue this guideline aims to solve, its relevance, and the impact of not having a guideline in place.]

## ✅ Proposed Solution
[Describe the proposed guideline, how it should be implemented, and any references to industry standards or best practices.]

## 📊 Examples & Use Cases
[Provide practical examples of how the guideline should be applied.]

## 🔄 Alternative Approaches
[List any alternative solutions considered and why they were not chosen.]

## 📢 Community Feedback
[Link to discussions, issues, or feedback from contributors.]

## 📅 Implementation Plan
[If applicable, outline steps for adopting this guideline, including transition plans and possible challenges.]

## 🏁 Conclusion
[A final summary and call to action for adoption.]

There is a lot of good ideas to pull from this! 👍

For the purpose of this repository, I would almost suggest to simplify the guidelines to:

"Make a pull request".

Since we are working with text-based guidelines, this is the most efficient way to propose changes. For major overhauls, such as restructuring the entire documentation or rewording existing guidelines, opening an Issue first would help avoid unnecessary effort on something that may not be wanted. 😅

That being said, do we want to require PRs for all documentation and wiki changes?(Actually, can we even make PRs for the wiki? I have not tried)

[RustyBraze]

The wiki can be edited directly without the need to pull or create PRs. If we have several people generating PRs, it will be a nightmare.

You can create a repo, add a wiki and play with it to see how it works and see/have ideas of workflows

[ZynthCode]

The wiki can be edited directly without the need to pull or create PRs. If we have several people generating PRs, it will be a nightmare.

You can create a repo, add a wiki and play with it to see how it works and see/have ideas of workflows

Well, yes, we could set a guideline for that, but it might lead to disagreements, especially if people start modifying each other's text 😅

I am all for giving it a try! I have some documents I would like to add regarding meeting minutes, but I will wait for a consensus first.

[RakanHowls]

A proposal could first be created as a github discussion - and then moved to a PR when there is agreement

[RakanHowls]

As far as the PR is concerned, I think a PR should require at least 3 people taking part in the review (I think the threshold should be relatively small) - and if the simple majority is for it, it could be merged... We can always update the requirements later ofc - but that could be a start :P

I like the template - but for the discussion I think the options under ## ✅ Proposed Solution and ## 🔄 Alternative Approaches should just be listed under one heading "Proposals" - and only if the discussion converges, we can split them into these sections (we should definitely include the alternatives as well for documentation purposes)