use headings instead of list items

this allows easier linking and a provides a bit more visual clarity

maintainers/README.md

@@ -42,12 +42,12 @@ The team meets twice a week:
 
 - Discussion meeting: [Fridays 13:00-14:00 CET](https://calendar.google.com/calendar/event?eid=MHNtOGVuNWtrZXNpZHR2bW1sM3QyN2ZjaGNfMjAyMjExMjVUMTIwMDAwWiBiOW81MmZvYnFqYWs4b3E4bGZraGczdDBxZ0Bn)
 
-  1. Triage issues and pull requests from the _No Status_ column (30 min)
+  1. Triage issues and pull requests from the [No Status](#no-status) column (30 min)
-  2. Discuss issues and pull requests from the _To discuss_ column (30 min)
+  2. Discuss issues and pull requests from the [To discuss](#to-discuss) column (30 min)
 
 - Work meeting: [Mondays 13:00-15:00 CET](https://calendar.google.com/calendar/event?eid=NTM1MG1wNGJnOGpmOTZhYms3bTB1bnY5cWxfMjAyMjExMjFUMTIwMDAwWiBiOW81MmZvYnFqYWs4b3E4bGZraGczdDBxZ0Bn)
 
-  1. Code review on pull requests from _In review_.
+  1. Code review on pull requests from [In review](#in-review).
   2. Other chores and tasks.
 
 Meeting notes are collected on a [collaborative scratchpad](https://pad.lassul.us/Cv7FpYx-Ri-4VjUykQOLAw), and published on Discourse under the [Nix category](https://discourse.nixos.org/c/dev/nix/50).
@@ -58,72 +58,74 @@ The team uses a [GitHub project board](https://github.com/orgs/NixOS/projects/19
 
 Items on the board progress through the following states:
 
-- No Status
+### No Status
 
-  During the discussion meeting, the team triages new items.
+During the discussion meeting, the team triages new items.
-  To be considered, issues and pull requests must have a high-level description to provide the whole team with the necessary context at a glance.
+To be considered, issues and pull requests must have a high-level description to provide the whole team with the necessary context at a glance.
 
-  On every meeting, at least one item from each of the following categories is inspected:
+On every meeting, at least one item from each of the following categories is inspected:
 
-  1. [critical](https://github.com/NixOS/nix/labels/critical)
+1. [critical](https://github.com/NixOS/nix/labels/critical)
-  2. [security](https://github.com/NixOS/nix/labels/security)
+2. [security](https://github.com/NixOS/nix/labels/security)
-  3. [regression](https://github.com/NixOS/nix/labels/regression)
+3. [regression](https://github.com/NixOS/nix/labels/regression)
-  4. [bug](https://github.com/NixOS/nix/issues?q=is%3Aopen+label%3Abug+sort%3Areactions-%2B1-desc)
+4. [bug](https://github.com/NixOS/nix/issues?q=is%3Aopen+label%3Abug+sort%3Areactions-%2B1-desc)
-  5. [tests of existing functionality](https://github.com/NixOS/nix/issues?q=is%3Aopen+label%3Atests+-label%3Afeature+sort%3Areactions-%2B1-desc)
+5. [tests of existing functionality](https://github.com/NixOS/nix/issues?q=is%3Aopen+label%3Atests+-label%3Afeature+sort%3Areactions-%2B1-desc)
 
-  - [oldest pull requests](https://github.com/NixOS/nix/pulls?q=is%3Apr+is%3Aopen+sort%3Acreated-asc)
+- [oldest pull requests](https://github.com/NixOS/nix/pulls?q=is%3Apr+is%3Aopen+sort%3Acreated-asc)
-  - [most popular pull requests](https://github.com/NixOS/nix/pulls?q=is%3Apr+is%3Aopen+sort%3Areactions-%2B1-desc)
+- [most popular pull requests](https://github.com/NixOS/nix/pulls?q=is%3Apr+is%3Aopen+sort%3Areactions-%2B1-desc)
-  - [oldest issues](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc)
+- [oldest issues](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc)
-  - [most popular issues](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc)
+- [most popular issues](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc)
 
-  Team members can also add pull requests or issues they would like the whole team to consider.
+Team members can also add pull requests or issues they would like the whole team to consider.
-  To ensure process quality and reliability, all non-trivial pull requests must be triaged before merging.
+To ensure process quality and reliability, all non-trivial pull requests must be triaged before merging.
 
-  If there is disagreement on the general idea behind an issue or pull request, it is moved to _To discuss_.
+If there is disagreement on the general idea behind an issue or pull request, it is moved to [To discuss](#to-discuss).
-  Otherwise, the issue or pull request in questions get the label [`idea approved`](https://github.com/NixOS/nix/labels/idea%20approved).
+Otherwise, the issue or pull request in questions get the label [`idea approved`](https://github.com/NixOS/nix/labels/idea%20approved).
-  For issues this means that an implementation is welcome and will be prioritised for review.
+For issues this means that an implementation is welcome and will be prioritised for review.
-  For pull requests this means that:
+For pull requests this means that:
-  - Unfinished work is encouraged to be continued.
+- Unfinished work is encouraged to be continued.
-  - A reviewer is assigned to take responsibility for getting the pull request merged.
+- A reviewer is assigned to take responsibility for getting the pull request merged.
-    The item is moved to the _Assigned_ column.
+  The item is moved to the [Assigned](#assigned) column.
-  - If needed, the team can decide to do a collarorative review.
+- If needed, the team can decide to do a collarorative review.
-    Then the item is moved to the _In review_ column, and review session is scheduled.
+  Then the item is moved to the [In review](#in-review) column, and review session is scheduled.
 
-  What constitutes a trivial pull request is up to maintainers' judgement.
+What constitutes a trivial pull request is up to maintainers' judgement.
 
-- To discuss
+### To discuss
 
-  Pull requests and issues that are deemed important and controversial are discussed by the team during discussion meetings.
+Pull requests and issues that are deemed important and controversial are discussed by the team during discussion meetings.
 
-  This may be where the merit of the change itself or the implementation strategy is contested by a team member.
+This may be where the merit of the change itself or the implementation strategy is contested by a team member.
 
-  As a general guideline, the order of items is determined as follows:
+As a general guideline, the order of items is determined as follows:
 
-  - Prioritise pull requests over issues
+- Prioritise pull requests over issues
 
   Contributors who took the time to implement concrete change proposals should not wait indefinitely.
 
-  - Prioritise fixing bugs and testing over documentation, improvements or new features
+- Prioritise fixing bugs and testing over documentation, improvements or new features
 
   The team values stability and accessibility higher than raw functionality.
 
-  - Interleave issues and PRs
+- Interleave issues and PRs
 
   This way issues without attempts at a solution get a chance to get addressed.
 
-- In review
+### In review
 
-  Pull requests in this column are reviewed together during work meetings.
+Pull requests in this column are reviewed together during work meetings.
-  This is both for spreading implementation knowledge and for establishing common values in code reviews.
+This is both for spreading implementation knowledge and for establishing common values in code reviews.
 
-  When the overall direction is agreed upon, even when further changes are required, the pull request is assigned to one team member.
+When the overall direction is agreed upon, even when further changes are required, the pull request is assigned to one team member.
 
-- Assigned
+### Assigned
 
-  One team member is assigned to each of these pull requests.
+One team member is assigned to each of these pull requests.
-  They will communicate with the authors, and make the final approval once all remaining issues are addressed.
+They will communicate with the authors, and make the final approval once all remaining issues are addressed.
 
-  If more substantive issues arise, the assignee can move the pull request back to _To discuss_ or _In review_ to involve the team again.
+If more substantive issues arise, the assignee can move the pull request back to [To discuss](#to-discuss) or [In review](#in-review) to involve the team again.
+
+### Flowchart
 
 The process is illustrated in the following diagram: