[sanderjd]

Can you give me example regulatory language that would require a Jira ticket in order to change internal documentation? (That is the only thing we are discussing in this thread, despite many attempts to broaden it.)

An internal engineering documentation change is not something that needs visibility in this grand project management effort. Project managers that are tracking such things are doing busywork that is not adding any value.

I recognize that all of this is very common, but it's not actually valuable. I have absolutely zero problem abiding by rules that are not good, but what I see a lot of here is learned helplessness and rationalization. It is not necessary to convince oneself "actually this is all good" in order to merely abide by rules that it is not your responsibility to change. You can merrily follow the rules and then also, if anybody asks you, you can say "these processes are not valuable for the following reasons".

[rleigh]

The documentation itself can be regulated, and changing it requires more than a PR code review by another software developer. As an example, the instructions for building and releasing the software could come under the controlled SDLC process.

I see where you're coming from, but you're not correct that this is misguided, nor that this is just busywork for project managers. If you're doing safety-critical stuff in the automotive, aviation or medical industries then process faults mean lives could be put at risk. A drive-by PR to update a document could have serious implications, and that's why change management processes are in place. They are a safety-net above the level of the code review and activity in the VCS, because you have a different set of eyes on what's going on.

[sanderjd]

I know there is some fallacy or something around asking for evidence (is it "sealioning"?), but are you aware of anything that demonstrates that this kind of change control process successfully reduces risk in life-critical systems? I'm very skeptical that requiring a ticket requesting an internal documentation change in order to improve that documentation is saving any lives. You might say "well it can't hurt", but I don't think that's obviously true; I think it creates a perverse incentive to leave documentation as is rather than improving it, which I think is more likely to be negative sum than it is to be valuable. That is why I think it is misguided; I think it is more likely to result in poorer documentation, for no gain.

Please understand that I really am just talking about this one case; I see no reason to question a requirement like this for changes to code or configuration or interface documentation or specifications or anything else.

[relaxing]

An example is when all hours spent need to be traced back to a requirement that has been signed off on by stakeholders. There needs to be a recordkeeping system to support this requirements traceability, so Jira it is.

[sanderjd]

Is that a regulation? It sounds like either an internal process choice or a contract requirement.

Edit: But point taken. I can see where this would be a (misguided, counterproductive) requirement in a probably-government contract. I would just suggest recognizing that it is a necessary evil when doing that kind of work, but not a good practice.