> Those ad-hoc doc updates are the exception vs the norm.
Where you work, maybe. Not where I do, or have. If I'm in something and see that I can make it better without losing my stack, I'll do it. I encourage my coworkers and, when managing, my reports (when they have proven that they won't rabbit-hole) to do the same.
What is often pejoratively called "boy-scouting" in a codebase is the only practical way by which many organizations will maintain that codebase beyond feature requests.
They are exceptional the harder it is to make them, and the result is documentation full of minor grammar mistakes or unclear things.
As an example for where it works great, I have made a small documentation fix PR to the Rust standard library 2 days ago and I didn't have to create a github issue for it or anything (but I had to notify a maintainer to review it because the PR fell through the cracks it seems). That maintainer told me they have reviewed 5 other similar pull requests that day. Over time, you get a really nice code base that way.
I think you just nailed it. With the PR that fell through the cracks.
The danger of having a ticketless fix is, you end up with PRs that are not on anyone's plate to fix.
The nice thing about tickets is that it creates a clear line of succession for adding value. If done properly, you will not have anything fall through the cracks. The cost for this is, you need to create tickets.
Reduce the friction to as close to 0 to create a ticket, and you can net all the benefits of tickets without a lot of cost.
The rustc repo has a system to assign PRs to reviewers automatically upon filing. On github, PRs and issues are very similar, and one can assign people to them.
There is a bot which checks which components the PR is modifying and based on that it assigns a reviewer to it. It predates github's builtin support for specifying component maintainers, so is a bit different than that.
However, as the Rust project is mostly made up of volunteers, sometimes a PR gets assigned to someone who is less active. This happened in my instance, where the PR got assigned to a reviewer whose last approval that ended up in a merge was in February 2022. The PRs assigned to these maintainers still get reviewed eventually, by other reviewers, or maybe them themselves. The assignment is more of a suggestion than a strict requirement and often maintainers with a desire to review some PR assign themselves. I just wanted to speed up the process so I talked to a maintainer who I knew likes to go through the list of open PRs and approve them if they are trivial. That's what I mean by "fell through the cracks".
Perhaps you've worked in notably functional organizations, but, with respect, your claims throughout this thread read like theorycrafting. I have been a Jira administrator, I have had extremely positive feedback from all parties based on the workflows, the automation opportunities, and the minimization of overhead involved when I did so, and it still required a context switch. And context switches always and without exception suck.
Ive both worked in and led highly functional, and highly non-functional organizations.
You are exactly right, that much of what Im pushing is the vision of what Agile / Scrum is supposed to facilitate, and what the benefits can look like if done correctly.
The best jobs I've had didn't have any of these control issues.
The worst ones required tickets linked to PRs with multiple layers of approvals, on and on. It could take days to get a few dozen lines of code merged. No thanks.
For me worst system that I had to fix and I had to save the company from losing only paying customer didn't have any of controls.
It was just bunch of freelancers doing what they wanted and paid in gold.
Right now as company is growing I consider leaving from time to time because people we now hired start creating bureaucracy that I would never go into.
Well I definitely introduced process into company - but as I see it there must be some absolute baseline tickets/repo/CI/CD for standards and at least weekly meeting.
I also agree that for a lot of software requiring unit testing (a lot of people writing bs tests just to pass review), requiring 2 or 3 people to sign off PR is just something I would not recommend.
It is also common to have controls in github, where its required for a jira ticket to be attached to a PR.
In that situation. Its literally impossible to merge into the codebase without a ticket.
Again it comes down to 'who can create the ticket' and 'what is the required scope of the ticket'