ATProto Browser

Record data

{
  "uri": "at://did:plc:sl3g3nhnad34sfhjnqdivbzd/sh.tangled.repo.issue.comment/3lkewmoff3x22",
  "cid": "bafyreibtnjr4qrdmxdzmp42y4ktdbcuvwskmuhu6p7tyg6lj2jnvurhgni",
  "value": {
    "body": "hi! @steveklabnik.com linked me to this thread :)\n\nFor context, I worked on Meta's source control team for ~6 years where we built out a state-of-the-art code review flow, inspired by mailing list workflows but brought forward into the 21st century with a modern web-based UI. I would love to see a workflow like that exist in a widely-used open tool.\n\nThe workflow involved:\n\n* focus on individual \"diffs\" as the unit of work rather than branches or PRs -- one diff = one commit that is proposed for inclusion\n* each diff is quite small, recommendation was around 300 lines or less -- again, similar to mailing list workflows where each patch is small, but scaled up a bit since diffs are reviewable on the web\n* amends and rebases locally, the idea being that you're writing your commit as you want it to appear in main. We built out extensive support in Sapling/Mercurial for doing this well, and Jujutsu does this even better while being Git-compatible)\n* first-class support for stacks of arbitrary depth -- it was common for devs to manage stacks of 10+, and it scaled well to 40-50+. (Think of how mailing list workflows often do PATCH [01/50] etc, except on the web.) Stacks were independent diffs, but there was a UI in each diff showing the full stack.\n* first-class support for merging stacks that have been accepted in code review via a \"Ship Stacked (N)\" button in the web UI -- this also worked with partial stacks for a \"pipelining\" workflow where you merge earlier parts of the stack while working on later parts.\n* all of this was API-driven and accessible via a command-line tool as well.\n\nFor all the years I worked on the team, the source control and review tooling received very high approval ratings in surveys (85%+) -- highest among all developer tools, and generally loved even as the outside world standardized on Git/GitHub and new folks coming in had no experience with any other flows.\n\nAt Meta we had a strong focus on trunk-based development so we didn't support long-lived branches, instead relying on feature flags. Some projects may want to support longer-lived branches, though. I don't have a strong opinion here but I think treating it as something different from patch-based code review makes a lot of sense. Personally I expect I would use patch-based tooling almost of the time.",
    "repo": "at://did:plc:wshs7t2adsemcrrd4snkeqli/sh.tangled.repo/3liuighjy2h22",
    "$type": "sh.tangled.repo.issue.comment",
    "issue": "at://did:plc:hwevmowznbiukdf6uk5dwrrq/sh.tangled.repo.issue/3lkeinu32es22",
    "owner": "did:plc:sl3g3nhnad34sfhjnqdivbzd",
    "commentId": 181192,
    "createdAt": "2025-03-15T01:05:05Z"
  }
}