Engineer, 20+ years of project management, now tangled up in change management and AI. I share the mistakes behind the lessons: what I did, what broke, and the exact Ctrl+Z moment.

Blog: https://www.theundostack.org/ · Mastodon: @ctrlzee@mastodon.social

  • 0 Posts
  • 4 Comments
Joined 6 days ago
cake
Cake day: November 5th, 2026

help-circle

  • It’s an unfortunate news, burnout in open source was real even before AI. Now it has just exploded.

    Reviewing code has always been a bottleneck. AI made sending a patch nearly free, but reviewing one costs the same as ever, and it lands on a few volunteers.

    For code that millions run, someone has to understand every line, so the sender should do that work, not the maintainer. Otherwise you’re just moving the cost onto the people who can least afford it.

    There should be a simple rule: if you can’t explain your patch line by line, don’t send it. And maintainers should feel free to reject any patch by default when the sender can’t explain it.


  • Excellent advice, you don’t need anything complex, just install git and you’re good to go.

    Think of a commit as a save point before the boss fight. One rule is enough to start: commit every time something works, and always before trying something risky. Write the message as if for yourself in six months.

    The server can wait until you have something worth losing. Just remember git on one disk isn’t a backup: copy the folder somewhere else now and then.


  • I get the appeal of a self-hosted tool, but my suggestion is to do the important ones in person.

    When I ran a Linux group years ago, the decisions that mattered were settled around a table. For a big decision, the dialogue and the discussion that lead to a common agreement are the real work, and in my experience no software does that part for you.

    For small stuff, a simple poll (or no poll at all) is fine: the core team decides and shares it as information. Save people’s attention for the decisions that need it.