reorder sections

Signed-off-by: HarHarLinks <2803622+HarHarLinks@users.noreply.github.com>
This commit is contained in:
HarHarLinks 2025-11-07 01:17:28 +01:00 committed by Kim Brose
parent ba74018555
commit f0b558f228

View file

@ -2,7 +2,38 @@
Thank you for taking the time to contribute to Matrix!
This is the repository for the matrix.org website.
This is the repository for the matrix.org website, available at <https://matrix.org/>.
## What we are trying to achieve
One key mission of the Foundation is to make Matrix a mainstream protocol. For this, onboarding needs to be made easy for new users. The Matrix.org website is a critical step in this journey: this is where people land when they look up "what is Matrix chat" or "chatting on Matrix" in a search engine.
**The primary mission of the matrix.org website is to onboard various populations on Matrix, and turn them into supporters of the project.**
We identified 4 different kind of populations that we want to address with the Matrix.org website.
- **Everyday people** who want to use Matrix for instant messaging with family and friends. They are not tech savvy and just want simple steps to follow, and something that "just works™". They don't particularly care about Matrix. They could use WhatsApp or Signal.
- **Community managers** who want to find a platform for their community to talk on. They could use Slack or Discord.
- **Developers** who want to create clients, servers, bridges or bots. They are tech literate and are interested in how things work from a technical perspective. They are already convinced Matrix is useful and want either to create toys for it, or Matrix-based tools for production.
- **Entrepreneurs** who were told about Matrix and who need to see how it can bring value to them to create products based on Matrix.
## How we measure progress
The tools we have at our disposal are:
- Privacy-preserving analytics with Plausible.io ([rationale here](https://ergaster.org/posts/2024/01/24-tracking-what-works/)). They allow us to track which are the most popular pages, custom events (e.g. to track if a call to action is often clicked on or not), and funnels
- User feedback, which will necessarily suffer the survivor bias
## How we take decisions
We try to keep a paper trail for all the decisions and implementation:
- All of the changes on the website need to happen [through a Pull Request](https://github.com/matrix-org/matrix.org/pulls)
- The only exception to this rules are if we broke things preventing our usual workflow.
- Pull Requests which do changes to existing content or add content outside of the blog should fix a documented and accepted [issue](https://github.com/matrix-org/matrix.org/pulls)
- Issues are reviewed by the maintainers of the project (the [Website and Content Working Group](https://matrix.org/foundation/working-groups/)). Some discussion can happen in [#matrix.org-website:matrix.org](https://matrix.to/#/%23matrix.org-website:matrix.org) but all decisions are logged in the issues themselves.
We keep this paper trail to avoid having to review Pull Requests "fixing" things we don't need or want to be fixed. Of course we try to remain flexible where it makes sense, but want to stick to this process as much as possible.
## Sign off
@ -58,37 +89,6 @@ Signed-off-by: Your Name <your@email.example.org>
Git allows you to add this signoff automatically when using the `-s` flag to `git commit`, which uses the name and email set in your `user.name` and `user.email` git configs.
## What we are trying to achieve
One key mission of the Foundation is to make Matrix a mainstream protocol. For this, onboarding needs to be made easy for new users. The Matrix.org website is a critical step in this journey: this is where people land when they look up "what is Matrix chat" or "chatting on Matrix" in a search engine.
**The primary mission of the matrix.org website is to onboard various populations on Matrix, and turn them into supporters of the project.**
We identified 4 different kind of populations that we want to address with the Matrix.org website.
- **Everyday people** who want to use Matrix for instant messaging with family and friends. They are not tech savvy and just want simple steps to follow, and something that "just works™". They don't particularly care about Matrix. They could use WhatsApp or Signal.
- **Community managers** who want to find a platform for their community to talk on. They could use Slack or Discord.
- **Developers** who want to create clients, servers, bridges or bots. They are tech literate and are interested in how things work from a technical perspective. They are already convinced Matrix is useful and want either to create toys for it, or Matrix-based tools for production.
- **Entrepreneurs** who were told about Matrix and who need to see how it can bring value to them to create products based on Matrix.
## How we measure progress
The tools we have at our disposal are:
- Privacy-preserving analytics with Plausible.io ([rationale here](https://ergaster.org/posts/2024/01/24-tracking-what-works/)). They allow us to track which are the most popular pages, custom events (e.g. to track if a call to action is often clicked on or not), and funnels
- User feedback, which will necessarily suffer the survivor bias
## How we take decisions
We try to keep a paper trail for all the decisions and implementation:
- All of the changes on the website need to happen [through a Pull Request](https://github.com/matrix-org/matrix.org/pulls)
- The only exception to this rules are if we broke things preventing our usual workflow.
- Pull Requests which do changes to existing content or add content outside of the blog should fix a documented and accepted [issue](https://github.com/matrix-org/matrix.org/pulls)
- Issues are reviewed by the maintainers of the project (the [Website and Content Working Group](https://matrix.org/foundation/working-groups/)). Some discussion can happen in [#matrix.org-website:matrix.org](https://matrix.to/#/%23matrix.org-website:matrix.org) but all decisions are logged in the issues themselves.
We keep this paper trail to avoid having to review Pull Requests "fixing" things we don't need or want to be fixed. Of course we try to remain flexible where it makes sense, but want to stick to this process as much as possible.
## Review & Publishing Policy
This policy outlines the expectations by the Website and Content Working Group