Fixed wrong rendering and abandoned the purple template text

Author: janhalen

MAINTAINERS.md

@@ -0,0 +1,39 @@
+# Maintainers
+
+This document provides information about the maintainers of the project, their roles, and how to engage with them.
+
+## Current Maintainers
+
+| Name            | GitHub Username      | Role/Responsibilities                   | Contact Method          |
+|-----------------|----------------------|-----------------------------------------|-------------------------|
+| [Maintainer 1]  | [@username1](https://github.com/username1) | [Role/Responsibility]                  | [[email protected]]     |
+| [Maintainer 2]  | [@username2](https://github.com/username2) | [Role/Responsibility]                  | [[email protected]]     |
+| [Maintainer 3]  | [@username3](https://github.com/username3) | [Role/Responsibility]                  | [[email protected]]     |
+
+## Emeritus Maintainers
+
+| Name            | GitHub Username      | Role/Responsibilities                   | Contact Method          |
+|-----------------|----------------------|-----------------------------------------|-------------------------|
+| [Emeritus 1]    | [@emeritus1](https://github.com/emeritus1) | [Previous Role/Responsibility]         | [[email protected]]     |
+
+## Becoming a Maintainer
+
+To become a maintainer of this project, please follow these steps:
+
+1. **Contribute**: Actively contribute to the project by submitting pull requests and participating in discussions.
+2. **Engagement**: Engage with the community and maintainers through issues and discussions.
+3. **Request**: Once you feel ready, request maintainer status by opening an issue or contacting an existing maintainer.
+
+## Removal Process
+
+Maintainers may be removed or moved to emeritus status under the following circumstances:
+
+- Inactivity for an extended period (e.g., 6 months).
+- Failure to respond to issues or pull requests.
+- Request for removal by the maintainer.
+
+Maintainers can be removed through a consensus among current maintainers.
+
+---
+
+*For any questions or concerns regarding maintainership, please reach out to any of the current maintainers listed above.*

CONTRIBUTING.md renamed to PROJECT_CONTRIBUTING_TEMPLATE.md

@@ -4,21 +4,20 @@ Contributors to the documentation can be project managers, technical editors, de
 
 To ensure our documentation stays resilient and up-to-date, we employ the use of the open practice of [Docs As Code](https://openpracticelibrary.com/practice/docs-as-code/) and the open [Markdown](https://en.wikipedia.org/wiki/Markdown) format for ease of collaboration and quality control.
 
-To promote digital sovereignty, interoperability, reuse, transparency and resillience, we adhere to the [Standard for Public Code](https://standard.publiccode.net/), a framework maintained by the [Foundation for Public Code](https://publiccode.net/who-we-are/). 
-<br>
-<br>
+To promote digital sovereignty, interoperability, reuse, transparency and resillience, we adhere to the [Standard for Public Code](https://standard.publiccode.net/), a framework maintained by the [Foundation for Public Code](https://publiccode.net/who-we-are/).
+`<br>`
+`<br>`
 
 ## 🚀 Quick start
 
 1. Start by writing a README following the simple criteria in the above guides from Standard for Public Code. For at fast and simple way to accomplish this, you can fill out the placeholders in the PROJECT_README_TEMPLATE.md and [rename it](https://docs.github.com/en/repositories/working-with-files/managing-files/renaming-a-file) to README.md, replacing the Quick start guide for this template with your projects information.
 2. Follow the criteria from [Document the Code](https://standard.publiccode.net/criteria/document-the-code.html), [Document your codebase objectives](https://standard.publiccode.net/criteria/document-codebase-objectives.html) and [Document codebase Maturity]()
-in one or several text documents using the Markdown format.
+   in one or several text documents using the Markdown format.
 3. Document further suggestions and improvements by [raising issues](https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues) and describing what needs to be fixed, describe the user stories and potential delivered values.
 4. Participate in issue discussions to help reach the correct resolutions. If you have the required knowledge about a part of the project, suggest yourself as an [assignee to the issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/assigning-issues-and-pull-requests-to-other-github-users#about-issue-and-pull-request-assignees).
 5. Collaborate on documentation branches with issues assigned to you by the maintainers.
 
 > 📚 Read more about:
-> 
-> How to use [Markdown](https://www.writethedocs.org/guide/writing/markdown/) to collaborate on documentation  
+>
+> How to use [Markdown](https://www.writethedocs.org/guide/writing/markdown/) to collaborate on documentation
 > How [Just the Docs](https://just-the-docs.github.io/just-the-docs/) is used to generate a documentation site from your markdown files.
-

README.md

@@ -1,41 +1,42 @@
-> [!WARNING] Remove this section from your README.md after completing all setup tasks!
+> [!WARNING] 
+> *Remove this section from your README.md after completing all setup tasks!*
 > - [ ] Click the green "Use this template" button above.
 > - [ ] Name your new repository and create it.
-> - [ ] Replace all the purple placeholder texts with your project-specific information.
+> - [ ] Replace all the grey placeholder texts with your project-specific information.
 > - [ ] Add any additional relevant Markdown documents to your documentation.
 > - [ ] Configure a [publishing source for GitHub Pages](https://help.github.com/en/articles/configuring-a-publishing-source-for-github-pages).
 > - [ ] **Remove this setup section from your README.md.**
 >
-> That's it! You are now set up, and your documentation site is live!
+> *That's it! You are now set up, and your documentation site is live!*
 
 
 # [Replace with Project Title]
-> [!IMPORTANT] [Replace with a clear statement defining the mission and goals of your project in simple terms.]
+> Replace this subtitle section with a clear statement defining the mission and goals of your project in a few simple terms.
 
 [How It Works](#how-this-codebase-achieves-its-objectives) | [Project Architecture](#architecture) | [Installation](#installation) | [Usage](#usage) | [Contributing](#contributing) | [License](#license) | [Contact](#contact)
 
 
 ## 🧭 How It Works
-> [!IMPORTANT]Replace with a brief, clear explanation of how the codebase works to achieve the stated mission objectives.
+> Replace with a brief, clear explanation of how the codebase works to achieve the stated mission objectives.
 
 #### Architecture
 
-> [!IMPORTANT] Replace with a Brief introduction to the project's high-level architecture. Link to an ARCHITECTURE.MD diagram e.g. in mermaid syntax
+> Replace with a Brief introduction to the project's high-level architecture. Link to an ARCHITECTURE.MD diagram e.g. in mermaid syntax
 
 #### Key Features
 
-> [!IMPORTANT] Replace this with a brief explaination of the main features or functionalities of your project.]
+> Replace this with a brief explaination of the main features or functionalities of your project.]
 
 
 ## :arrow_heading_down: Installation
-> [!IMPORTANT] Replace with Step-by-step instructions on how to install the codebase. 
+> Replace with Step-by-step instructions on how to install the codebase. 
 
 ## ▶️ How to Run
-> [!IMPORTANT] Replace with clear, concise instructions on how to run and use the codebase.
+> Replace with clear, concise instructions on how to run and use the codebase.
 
 #### Examples
 
-> [!IMPORTANT] Replace with examples demonstrating key functionality, code-snippets such as command-line usage, API calls or if needed screendumps
+> Replace with examples demonstrating key functionality, code-snippets such as command-line usage, API calls or if needed screendumps
 
 ---