Switch away from Title Casing in our Markdown headers (rerun-io#5779)

### What
For consistency!

This can be fixed with `pixi run lint-rerun --fix --extra`, but because
of too many false positives I decided not to run the lint normally
(hence the new `--extra` flag)

### Checklist
* [x] I have read and agree to [Contributor
Guide](https://github.com/rerun-io/rerun/blob/main/CONTRIBUTING.md) and
the [Code of
Conduct](https://github.com/rerun-io/rerun/blob/main/CODE_OF_CONDUCT.md)
* [x] I've included a screenshot or gif (if applicable)
* [x] I have tested the web demo (if applicable):
* Using newly built examples:
[rerun.io/viewer](https://rerun.io/viewer/pr/5779)
* Using examples from latest `main` build:
[rerun.io/viewer](https://rerun.io/viewer/pr/5779?manifest_url=https://app.rerun.io/version/main/examples_manifest.json)
* Using full set of examples from `nightly` build:
[rerun.io/viewer](https://rerun.io/viewer/pr/5779?manifest_url=https://app.rerun.io/version/nightly/examples_manifest.json)
* [x] The PR title and labels are set such as to maximize their
usefulness for the next release's CHANGELOG
* [x] If applicable, add a new check to the [release
checklist](https://github.com/rerun-io/rerun/blob/main/tests/python/release_checklist)!

- [PR Build Summary](https://build.rerun.io/pr/5779)
- [Docs
preview](https://rerun.io/preview/af4b618dc75653fc8e47b82f91bd5197730287c9/docs)
<!--DOCS-PREVIEW-->
- [Examples
preview](https://rerun.io/preview/af4b618dc75653fc8e47b82f91bd5197730287c9/examples)
<!--EXAMPLES-PREVIEW-->
- [Recent benchmark results](https://build.rerun.io/graphs/crates.html)
- [Wasm size tracking](https://build.rerun.io/graphs/sizes.html)

.github/workflows/README.md

@@ -15,7 +15,7 @@ If you are going to be doing any editing of workflows, the
 [VS Code extension](https://marketplace.visualstudio.com/items?itemName=cschleiden.vscode-github-actions)
 for GitHub Actions is highly recommended.
 
-## Reusable Workflows
+## Reusable workflows
 
 -   [reusable_checks.yml](reusable_checks.yml) - These are all the checks that run to ensure the code is formatted,
     linted, and tested. This job produces no artifacts other than a pass/fail criteria for the build.
@@ -66,7 +66,7 @@ for GitHub Actions is highly recommended.
     -   `PR_NUMBER` - The PR number to update. This will generally be set by the `on_pull_request.yml` workflow using:
         `${{github.event.pull_request.number}}`
 
-## Manual Workflows
+## Manual workflows
 
 -   [manual_dispatch](manual_dispatch.yml) - This workflow is used to manually trigger the assorted reusable workflows for
     testing.

BUILD.md

@@ -117,7 +117,7 @@ High-level documentation for rerun can be found at [http://rerun.io/docs](http:/
 - 🐍 [Python API docs](https://ref.rerun.io/docs/python) are built via `mkdocs` and hosted on GitHub. For details on the python doc-system, see [Writing Docs](https://github.com/rerun-io/rerun/blob/main/rerun_py/docs/writing_docs.md).
 - 🦀 [Rust API docs](https://docs.rs/rerun/) are hosted on  <https://docs.rs/rerun/>. You can build them locally with: `cargo doc --all-features --no-deps --open`.
 
-## Building for the Web
+## Building for the web
 
 If you want to build a standalone rerun executable that contains the web-viewer and a websocket server,
 you need to install the `wasm32-unknown-unknown` rust target and ensure the `web_viewer` feature flag is set when building rerun.

CONTRIBUTING.md

@@ -17,7 +17,7 @@ This is written for anyone who wants to contribute to the Rerun repository.
 
 You can also look at our [`good first issue` tag](https://github.com/rerun-io/rerun/labels/good%20first%20issue).
 
-## Pull Requests
+## Pull requests
 We use [Trunk Based Development](https://trunkbaseddevelopment.com/), which means we encourage small, short-lived branches. Open draft PR:s to get some early feedback on your work.
 
 All PR:s are merged with [`Squash and Merge`](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#squash-and-merge-your-commits), meaning they all get squashed to just one commit on the `main` branch. This means you don't need to keep a clean commit history on your feature branches. In fact, it is preferable to add new commits to a branch rather than rebasing or squashing. For one, it makes it easier to track progress on a branch, but rebasing and force-pushing also discourages collaboration on a branch.

README.md

@@ -85,7 +85,7 @@ In the future, Rerun will offer a commercial product that builds on top of the c
 The Rerun open source project targets the needs of individual developers.
 The commercial product targets the needs specific to teams that build and run computer vision and robotics products.
 
-## How to Cite Rerun
+## How to cite Rerun
 
 When using Rerun in your research, please cite it to acknowledge its contribution to your work. This can be done by
 including a reference to Rerun in the software or methods section of your paper.

RELEASES.md

@@ -10,7 +10,7 @@ This document describes the current release and versioning strategy. This strate
 * [`CONTRIBUTING.md`](CONTRIBUTING.md)
 
 
-## Release Cadence
+## Release cadence
 New Rerun versions are released every four weeks. Sometimes we do out-of-schedule patch releases.
 
 

crates/re_data_store/README.md

@@ -1,4 +1,4 @@
-# Rerun Data Store
+# Rerun data store
 
 Part of the [`rerun`](https://github.com/rerun-io/rerun) family of crates.
 

crates/re_types/definitions/rerun/archetypes/arrows2d.fbs

@@ -11,7 +11,7 @@ namespace rerun.archetypes;
 
 /// 2D arrows with optional colors, radii, labels, etc.
 ///
-/// \example arrow2d_simple title="Simple batch of 2D Arrows" image="https://static.rerun.io/arrow2d_simple/59f044ccc03f7bc66ee802288f75706618b29a6e/1200w.png"
+/// \example arrow2d_simple title="Simple batch of 2D arrows" image="https://static.rerun.io/arrow2d_simple/59f044ccc03f7bc66ee802288f75706618b29a6e/1200w.png"
 table Arrows2D (
   "attr.rust.derive": "PartialEq",
   "attr.rust.new_pub_crate",

crates/re_types/definitions/rerun/archetypes/arrows3d.fbs

@@ -11,7 +11,7 @@ namespace rerun.archetypes;
 
 /// 3D arrows with optional colors, radii, labels, etc.
 ///
-/// \example arrow3d_simple title="Simple batch of 3D Arrows" image="https://static.rerun.io/arrow3d_simple/55e2f794a520bbf7527d7b828b0264732146c5d0/1200w.png"
+/// \example arrow3d_simple title="Simple batch of 3D arrows" image="https://static.rerun.io/arrow3d_simple/55e2f794a520bbf7527d7b828b0264732146c5d0/1200w.png"
 table Arrows3D (
   "attr.rust.derive": "PartialEq",
   "attr.rust.new_pub_crate",

crates/re_types/definitions/rerun/archetypes/pinhole.fbs

@@ -8,8 +8,8 @@ namespace rerun.archetypes;
 
 /// Camera perspective projection (a.k.a. intrinsics).
 ///
-/// \example pinhole_simple title="Simple Pinhole Camera" image="https://static.rerun.io/pinhole_simple/9af9441a94bcd9fd54e1fea44fb0c59ff381a7f2/1200w.png"
-/// \example pinhole_perspective title="Perspective Pinhole Camera" image="https://static.rerun.io/pinhole_perspective/d0bd02a0cf354a5c8eafb79a84fe8674335cab98/1200w.png"
+/// \example pinhole_simple title="Simple pinhole camera" image="https://static.rerun.io/pinhole_simple/9af9441a94bcd9fd54e1fea44fb0c59ff381a7f2/1200w.png"
+/// \example pinhole_perspective title="Perspective pinhole camera" image="https://static.rerun.io/pinhole_perspective/d0bd02a0cf354a5c8eafb79a84fe8674335cab98/1200w.png"
 table Pinhole (
   "attr.rust.derive": "PartialEq"
 ) {

crates/re_types/definitions/rerun/archetypes/series_line.fbs

@@ -17,7 +17,7 @@ namespace rerun.archetypes;
 /// \rs See [`Scalar`][crate::archetypes.Scalar]
 /// \cpp See `rerun::archetypes::Scalar`
 ///
-/// \example series_line_style title="Series Line" image="https://static.rerun.io/series_line_style/d2616d98b1e46bdb85849b8669154fdf058e3453/1200w.png"
+/// \example series_line_style title="Line series" image="https://static.rerun.io/series_line_style/d2616d98b1e46bdb85849b8669154fdf058e3453/1200w.png"
 table SeriesLine {
     // --- Required ---
 

crates/re_types/definitions/rerun/archetypes/series_point.fbs

@@ -17,7 +17,7 @@ namespace rerun.archetypes;
 /// \rs See [`Scalar`][crate::archetypes.Scalar]
 /// \cpp See `rerun::archetypes::Scalar`
 ///
-/// \example series_point_style title="Series Point" image="https://static.rerun.io/series_point_style/82207a705da6c086b28ce161db1db9e8b12258b7/1200w.png"
+/// \example series_point_style title="Point series" image="https://static.rerun.io/series_point_style/82207a705da6c086b28ce161db1db9e8b12258b7/1200w.png"
 table SeriesPoint {
     // --- Required ---
 

crates/re_types/definitions/rerun/archetypes/tensor.fbs

@@ -12,7 +12,7 @@ namespace rerun.archetypes;
 /// \cpp data can be passed in without a copy from raw pointers or by reference from `std::vector`/`std::array`/c-arrays.
 /// \cpp If needed, this "borrow-behavior" can be extended by defining your own `rerun::CollectionAdapter`.
 ///
-/// \example tensor_simple title="Simple Tensor" image="https://static.rerun.io/tensor_simple/baacb07712f7b706e3c80e696f70616c6c20b367/1200w.png"
+/// \example tensor_simple title="Simple tensor" image="https://static.rerun.io/tensor_simple/baacb07712f7b706e3c80e696f70616c6c20b367/1200w.png"
 table Tensor (
   "attr.rust.derive": "PartialEq"
 ) {

crates/re_viewer/data/quick_start_guides/cpp_connect.md

@@ -1,4 +1,4 @@
-# C++ Quick Start
+# C++ quick start
 
 ## Installing the Rerun viewer
 The Rerun C++ SDK works by connecting to an awaiting Rerun Viewer over TCP.

crates/re_viewer/data/quick_start_guides/cpp_spawn.md

@@ -1,4 +1,4 @@
-# C++ Quick Start
+# C++ quick start
 
 ## Installing the Rerun viewer
 The Rerun C++ SDK works by connecting to an awaiting Rerun Viewer over TCP.

crates/re_viewer/data/quick_start_guides/python_connect.md

@@ -1,4 +1,4 @@
-# Python Quick Start
+# Python quick start
 
 ## Installing the Rerun SDK
 

crates/re_viewer/data/quick_start_guides/python_spawn.md

@@ -1,4 +1,4 @@
-# Python Quick Start
+# Python quick start
 
 ## Installing the Rerun SDK
 

crates/re_viewer/data/quick_start_guides/rust_connect.md

@@ -1,4 +1,4 @@
-# Rust Quick Start
+# Rust quick start
 
 ## Installing Rerun
 

crates/re_viewer/data/quick_start_guides/rust_spawn.md

@@ -1,4 +1,4 @@
-# Rust Quick Start
+# Rust quick start
 
 ## Installing Rerun
 

design/batching.md

@@ -349,7 +349,7 @@ While range queries have some surprisingly tricky semantics (especially around t
 However, the fact that we return row numbers instead of the actual data itself can have significant performance implications when it comes to range queries.
 For example, if you need to iterate through 100k values, you would need to run 100k `get` requests, which would require 100k binsearches in the component tables. This can be extremely costly and is a major reason why our ranged query scenes quickly become unusable as the dataset grows.
 
-### Garbage Collection
+### Garbage collection
 
 The current garbage collection mechanism was put together as a quick fix for the `MsgId`-mismatch issue, and it is largely unreliable.
 
@@ -783,7 +783,7 @@ Nothing specific to add to the above.
 
 Nothing specific to add to the above.
 
-### Garbage Collection
+### Garbage collection
 
 The garbage collector is the system undergoing the most changes.
 

design/blueprint_store.md

@@ -1,4 +1,4 @@
-# Blueprint Operation: APIs and Datastore
+# Blueprint operation: APIs and datastore
 Status: proposal
 
 ## Intro
@@ -27,7 +27,7 @@ give users explicit control over the details of how data is displayed in the vie
 
 ## Proposal
 
-### Blueprint Lifecycle
+### Blueprint lifecycle
 In order to simplify many edge cases, custom blueprints will only be able to be sent to the viewer in their entirety as
 part of viewer startup. This limits blueprint control to: `rr.spawn()` (launch a native app), `rr.serve()` (launch a
 hosted web-app), and `rr.show()` (embed a viewer in a notebook). Additionally a blueprint file will be able to be
@@ -131,20 +131,20 @@ particular:
 
 This means a trivial expression like: `rr.show(rrb.Points3D("points"))` is still a valid Blueprint.
 
-## Blueprint-Static Data
+## Blueprint-Static data
 
 As a further simplification, the Blueprint will allow for the direct inclusion of static data, allowing users to bypass
 the data-logging APIs entirely for simple use-cases that don't require temporal information. This will be accomplished
 by allowing `rrb.Data` objects to be constructed from any Rerun-loggable object.
 
 Data that is a *query* from the recording store references an entity path used separately by the logging APIs:
 ```python
-# Log Data
+# Log data
 for t in range(100):
     rr.set_time('step', t)
     rr.log("world/points", rr.Points3D(points))
 …
-# Construct Blueprint
+# Construct blueprint
 rrb.Auto("/world/points")
 ```
 While static data skips the logging step all together, but only allows for a single element:
@@ -166,7 +166,7 @@ grid = rrd.GridLayout(cols=3, [rr.Image(img) for img in images])
 Note the usage of `rr.Image` (the loggable) vs `rrb.Image` (the blueprint template).
 
 
-## Blueprint Store
+## Blueprint store
 
 Behind the APIs, the blueprint is implemented using a “blueprint store” that leverages the same code as the existing
 data-store. We will therefore have both “data entities” and “blueprint entities”.

design/space_views.md

@@ -1,14 +1,14 @@
-# Space Views
+# Space views
 Status: Mostly implemented.
 
 
-## What are Space Views
+## What are space views
 Space Views visualize a Data Blueprint, i.e. a set of entities with given properties.
 They are represented as freely arrangeable tiles in the Viewport.
 Most Space Views are interactive, allowing their data to be explored freely.
 
 
-## Properties of a Space View
+## Properties of a space view
 All properties are saved as part of the blueprint.
 
 Changing discards Space View State:
@@ -27,22 +27,22 @@ Freely mutable:
 * available at various stages of ui drawing & system execution build-up (see below)
 
 
-## Space View State
+## Space view state
 In addition to blueprint stored data, a space view has a class specific `SpaceViewState`
 which stored ephemeral state that is not persisted as part of the blueprint.
 This is typically used for animation/transition state.
 
 ⚠️ As of writing, we're using this also for state that *should* be persisted and needs to be moved to
 blueprint components.
 
-## Space View Class
+## Space view class
 Each Space View refers to an immutable Space View Class, implemented by `SpaceViewClass`.
 It defines:
 * which data it can display and how it is displayed
 * how it is interacted with
 * what properties are read from the blueprint store and how they are exposed in the ui
 
-### What Space View Classes are there?
+### What space view classes are there?
 Space View differ only in class when they are **fundamentally different** in the way they display data.
 Naturally, this means that there are only ever very few distinct Space View classes.
 
@@ -54,7 +54,7 @@ As of writing we have:
 * Text Document
 * Time Series
 
-#### Future Space View Class distinction
+#### Future space view class distinction
 
 The fundamental difference between different space views lies in the kinds of axes a view has.
 - Data Table (currently text views) have rows and columns with text
@@ -64,7 +64,7 @@ The fundamental difference between different space views lies in the kinds of ax
 - Time Series has one time axis and one numeric axis
 - Rich Text is a rich text document (linear in top to bottom with wraparound in horizontal)
 
-##### On merging Bar Chart with Spatial 2D
+##### On merging bar chart with spatial 2D
 It might take some time to get the Archetype Queries + defaults expressive and easy to use enough that it makes sense to merge bar chart with spatial 2D. Right now we have the state that the bar chart space view takes a single 1-D tensor and draws a bar chart with x-axis = tensor indices and y-axis = tensor values. It draws boxes with width 1, centered on integers in x, y-min = 0 and y-max = tensor value.
 
 With the right set of primitives a user should be able to manually build a bar chart in a spatial 2D view. For example they might want a stacked bar chart. Talking about bringing in 3D into a bar chart doesn't likely make sense since there probably doesn't exist a camera projection that maps between 3D and the tensor indices axis (x).
@@ -135,7 +135,7 @@ Registration is done via `SpaceViewSystemRegistry` which `SpaceViewClassRegistry
 Space view classes can register their built-in systems upon their own registration via their `on_register` method.
 As with space view classes themselves, new systems may be added at runtime.
 
-### Frame Lifecycle
+### Frame lifecycle
 * `SpaceViewClass::prepare_ui`
 * default create all registered `ViewContextSystem` into a `ViewContextCollection`
 * execute all `ViewContextSystem`
@@ -147,7 +147,7 @@ As with space view classes themselves, new systems may be added at runtime.
     * this typically requires iterating over all `ViewPartSystem` and extract some data either in a generic fashion via `ViewPartSystem::data` or with knowledge of the concrete `ViewPartSystem` types
   * currently, we also pass in all `re_renderer` data since the build up of the `re_renderer` view via `ViewBuilder` is not (yet?) unified
 
-### Space View Class Registry
+### Space view class registry
 Despite being few in numbers, Space Views Classes are registered on startup.
 This is desirable since:
 * forces decoupling from other aspects of the Viewer (Viewer should be composable)
@@ -157,7 +157,7 @@ This is desirable since:
 ![Overview diagram of how the basic traits related to each other](https://github.com/rerun-io/rerun/assets/1220815/ffdb1cdf-7efe-47a0-ac38-30262d770e69)
 
 
-#### User defined Space View Classes
+#### User defined space view classes
 Rust developers can use the Class Registry to register their own Space View types.
 We do *not* expect this to be a common workflow, but more of a last resort / highest level
 extensibility hooks.

design/spatial_transforms.md

@@ -1,4 +1,4 @@
-# Spatial Transforms
+# Spatial transforms
 
 Spatial transforms are transforms that apply the spatial 2D & 3D space views.
 This includes affine 2D/3D transforms as well as camera projections.