epage · epage · Jul 24, 2026 · Jun 20, 2026 · Jun 20, 2026 · Jun 20, 2026
diff --git a/blog/blog/kings-peak.md → blog/blog/2013-08-17-kings-peak.md b/blog/blog/kings-peak.md → blog/blog/2013-08-17-kings-peak.md
diff --git a/blog/blog/lone-star-hiking.md → blog/blog/2014-12-03-lone-star-hiking.md b/blog/blog/lone-star-hiking.md → blog/blog/2014-12-03-lone-star-hiking.md
diff --git a/blog/blog/shaky-start.md → blog/blog/2017-01-30-shaky-start.md b/blog/blog/shaky-start.md → blog/blog/2017-01-30-shaky-start.md
diff --git a/blog/blog/blog-transition.md → blog/blog/2018-01-17-blog-transition.md b/blog/blog/blog-transition.md → blog/blog/2018-01-17-blog-transition.md
diff --git a/blog/blog/crate-management.md → blog/blog/2018-01-26-crate-management.md b/blog/blog/crate-management.md → blog/blog/2018-01-26-crate-management.md
diff --git a/blog/blog/redefining-failure.md → blog/blog/2018-03-09-redefining-failure.md b/blog/blog/redefining-failure.md → blog/blog/2018-03-09-redefining-failure.md
diff --git a/blog/blog/pycon-2018.md → blog/blog/2018-05-18-pycon-2018.md b/blog/blog/pycon-2018.md → blog/blog/2018-05-18-pycon-2018.md
diff --git a/blog/blog/rustfest-2018.md → blog/blog/2018-06-04-rustfest-2018.md b/blog/blog/rustfest-2018.md → blog/blog/2018-06-04-rustfest-2018.md
diff --git a/...eeding-up-rust-builds-code-gen-edition.md → ...eeding-up-rust-builds-code-gen-edition.md b/...eeding-up-rust-builds-code-gen-edition.md → ...eeding-up-rust-builds-code-gen-edition.md
diff --git a/blog/blog/reflecting-on-errors-in-2019.md → ...019-11-26-reflecting-on-errors-in-2019.md b/blog/blog/reflecting-on-errors-in-2019.md → ...019-11-26-reflecting-on-errors-in-2019.md
diff --git a/blog/blog/liquid-v20.md → blog/blog/2020-03-16-liquid-v20.md b/blog/blog/liquid-v20.md → blog/blog/2020-03-16-liquid-v20.md
diff --git a/blog/blog/pushgen-experiment.md → blog/blog/2021-07-07-pushgen-experiment.md b/blog/blog/pushgen-experiment.md → blog/blog/2021-07-07-pushgen-experiment.md
diff --git a/blog/blog/learning-rust.md → blog/blog/2021-09-15-learning-rust.md b/blog/blog/learning-rust.md → blog/blog/2021-09-15-learning-rust.md
diff --git a/blog/blog/optimizing-toml_edit.md → blog/blog/2021-09-30-optimizing-toml_edit.md b/blog/blog/optimizing-toml_edit.md → blog/blog/2021-09-30-optimizing-toml_edit.md
diff --git a/blog/blog/clap3.md → blog/blog/2021-12-30-clap3.md b/blog/blog/clap3.md → blog/blog/2021-12-30-clap3.md
diff --git a/blog/blog/cobalt-getting-started.md b/blog/blog/cobalt-getting-started.md
diff --git a/blog/blog/developing-on-github.md b/blog/blog/developing-on-github.md
diff --git a/blog/blog/how-to-maintain-100-packages-without-going-insane.md b/blog/blog/how-to-maintain-100-packages-without-going-insane.md
@@ -100,11 +100,16 @@ of a focus area when you shouldn't.
 For me, I've found there is an implicit social pressure to merge PRs.
 Someone had a need and devoted their time to resolve it.
 Quickly reviewing and merging PRs encourages further contributions and use of your package.
-PRs can take a lot of time whether from not having consensus on the problem or
+However, PRs can take a lot of time, whether from not having consensus on the problem or
 requirements, to problems with the implementation, to just the work it takes to
 re-acquainting with some intricacies.
-I've seen some who dealt with this pressure by becoming apathetic to
-these users.
+When it comes to AI contributions,
+this can turn into a DoS on the maintainer.
+
+As I've seen it put, PRs are "free as in puppies": given by love but come with a cost.
+Some maintainers setup boundaries by emotionally cutting them off from their users,
+becoming apathetic.
+Others burn them out to satisfy their users.
 
 I'm trying to find a middle ground for this.
 So far, my approach is to [document](https://github.com/clap-rs/clap/blob/master/CONTRIBUTING.md#where-to-start)
@@ -132,6 +137,46 @@ Some highlights include:
 - Focus bugs on behavior differences
 - Call out use cases for features
 
+TODO https://www.jlowin.dev/blog/oss-maintainers-guide-to-saying-no
+
+## Streamline Issues
+
+Something I picked up from the Rust Project is useful ways to leverage tags to make it easier to work with Issues.
+
+Track the status: `S-` prefixed tags, including
+- `S-triage`: brand new issue. Use templates to set this on new issues.
+- `S-needs-info`: need reproduction steps, deeper exploration of use cases, etc
+- `S-needs-design`: needs someone to step through the use cases, requirements, prior art, etc and come with with solution options and suggest a specific
+- `S-blocked`: cannot move forward for some reason
+- `S-needs-mentor`: designed is accepted but no maintainer has committed the capacity to move this forward yet
+- `S-accepted`: reviewer available
+
+Tracking the area of the code base: `A-` prefixed tags.
+This can help in finding issues, find duplicates, or features to work on together.
+
+Tracking the issue's category: `C-` prefixed tags, including
+- `C-bug`
+- `C-enhancement`
+- `C-tracking`
+
+## Time boxing
+
+A focus area may grow beyond what you expected, taking all of your time, snuffing out other efforts of interest.
+Or you may feel there is a reason to make an exception to your focus area.
+
+Time boxing is the act of setting aside a fixed time.
+Establishing a time box can help keep you on track with your long term goals.
+
+Sometimes you might not feel you need a timebox.
+Be sure to reevaluate.
+I've been working to improve the MSRV experience in Rust and
+`cfg_rust_version` would be an important piece in this puzzle.
+In 2025, I had a lot on my plate but there seemed to be a lot of interest from `T-lang` in a design I had for `cfg_rust_version` to unblock it so I took some time to work on it.
+There ended up being an unexpected amount of disagreement among `T-lang` on my RFC.
+In considering the remaining work and stress in working to achieve conesus among `T-lang`,
+I realized I had exceeded the time and stress time box that I had never formalized but had intended and stepped away.
+While I care a lot, that care can lead to burnout and I have to set aside those feelings.
+
 ## Automating
 
 ### Multiplying effort across repos
@@ -161,16 +206,9 @@ The main downside I've seen to this is the error reporting; its common for it to
 - RenovateBot
 - cargo release
 
-https://www.jlowin.dev/blog/oss-maintainers-guide-to-saying-no
-
 snapbox
 
-tags
-
 templates to encourage the right behavior
 - typos
 
-time boxing
-- like my rust_version RFC
-
 Dealing with load shifts
diff --git a/blog/blog/learning_rust.md b/blog/blog/learning_rust.md
diff --git a/blog/blog/rust-ci.md b/blog/blog/rust-ci.md
diff --git a/blog/blog/rust-dev-env.md b/blog/blog/rust-dev-env.md
diff --git a/blog/blog/rust-notes.md b/blog/blog/rust-notes.md
diff --git a/blog/blog/serde-and-complex-configuration.md b/blog/blog/serde-and-complex-configuration.md