{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiddebn7mgidtfreypx4jmdxd6mpqj6rdtkdeti463oi2g6inkdlha",
    "uri": "at://did:plc:i7budt2wflrcfy6jtvfocbix/app.bsky.feed.post/3mfamem75cfu2"
  },
  "path": "/viewtopic.php?p=1278185#p1278185",
  "publishedAt": "2026-02-19T16:15:16.000Z",
  "site": "https://www.tt-forums.net",
  "tags": [
    "_dp_"
  ],
  "textContent": "> There's been a lot of focus on code quality in the \"official project\" in the past several years, I think the goal can be described like any accepted PR should at least not make the code quality/maintainability worse. Maybe it's not clear enough: When the maintainers engage with someone's PR and asks for stylistic changes or \"nitpicks\" it, I believe it's because they're seeing value in the content of the change, but just want it to fit into the rest of the project \"shape-wise\".\n> I'm pretty sure most of those situations you're describing \"stall out\" with a maintainer asking for some further minor changes, and the contributor disappears.\n> What kind of approach would help this, more explicit encouragement? (Comments a'la \"I think this is a good idea and we really want to get this in\"?) Or would you rather that maintainers quickly move to fix up the things on their own and merge it, instead of trying to help a perhaps less experienced developer train up their skills?\n\n\nNot making code quality worse is a perfectly reasonable goal. I’m fully on board with that. The issue isn’t the goal, it’s how it’s sometimes applied in practice.\n\nWhat’s frustrating isn’t stylistic feedback itself. It’s when:\n\n  * Changes that are trivial to fix generate long explanations instead of just being adjusted.\n  * Subjective style preferences are enforced as if they were objective quality improvements.\n  * Naming is criticized without concrete alternatives.\n  * Marginally related code is pulled into scope and turned into required refactoring.\n  * PRs are asked to be split in ways that don’t reflect logical boundaries.\n  * Already small PRs are asked to be split simply because they touch messy legacy code.\n  * “Too hard to review” reasoning is used in a way that effectively makes larger contributions from non-core developers unrealistic.\n\nAt that point, the review stops being about protecting quality and starts feeling like procedural gatekeeping.\n\nThe bigger issue, though, is uncertainty. There’s often no clear signal whether the core change is actually wanted. I’ve personally had a case where I was asked to refactor existing code, got that approved, and then the main functionality was rejected anyway. That makes it difficult to justify investing significant time into addressing review comments if the underlying idea may not even be accepted.\n\nWhat would genuinely help isn’t general encouragement - it’s decisiveness and clarity:\n\n\n  * Early confirmation - before the PR is opened - that the change is conceptually welcome, especially for larger changes.\n  * After it’s opened: early feedback on whether the overall direction is acceptable, before deep refactoring is requested.\n  * A strong signal that if review comments are addressed, the PR will be merged.\n\nAs for proactivity: personally, I care about getting the functionality in, not about authorship credit. If it’s faster for a maintainer to tweak or rewrite parts and merge it, I’d strongly prefer that over prolonged back-and-forth. Training contributors is valuable, but it shouldn’t override forward momentum, especially when the contributor didn’t ask to be coached.\n\nStatistics: Posted by _dp_ — 19 Feb 2026 16:15\n\n* * *",
  "title": "OpenTTD Problems • Re: Annoying changes in 15.0's new UI",
  "updatedAt": "2026-02-19T16:15:16.000Z"
}