[carlisle_]

Is creating the ticket really adding value to the engineering process? In your example you already have the engineer making a PR (presumably peer reviewed) and a commit, what’s the ticket really needed for?

[mr-ron]

It can add value if done right. Just as you typically want to make a design doc / rfc before working on a project, you often want to describe what you are doing before you do it.

This can protect the engineer / team against scope creep, as well as determine the context of why work was done when you may need to understand more context (in the case of a bug for example).

Also it increases accountability and transparency. It is common that teams want to know what other engineers are working on and why.

[carlisle_]

We’re still talking about updating documentation right?

[treis]

It's not a lot of value but it's also not a lot of effort. At minimum it gives a little bit of visibility into what you're doing and why to the rest of the team. That's probably worth the 2 minutes it takes to create a ticket.

[mikevin]

I don't think it is. We're all professionals, if I'm doing something they need to know about then I'll inform them.

A ticket that takes 2 minutes to create is just distracting from tickets that provide real value to my colleagues. We're here to work together and improve something, not to babysit each other's schedules.

"Visibility into what I'm doing" as a reason to create a ticket is relevant for micromanagement, not for a team of professionals that trust each other's commitment to the job.

[carlisle_]

For updating internal documentation? I think we should be careful to ensure we’re actually adding value when we add friction, and not just hoping.