> JIRA ticket - audit trail
The team I'm on prides itself in providing great service to our clients (other devs in the company). This includes responding to support requests even if the client isn't entirely sure how to ask or who to ask.
> not sure what to say on this one because I don't understand how _else_ you would address them - I've always addressed each one individually
What I mean is that it used to be enough for you to address PR tasks by changing the code and pushing the updates and marking the tasks as "resolved". Now in some projects at work you also need to reply to the comment explaining how the change you made addressed the task. The idea obviously is to stop LLM from just ticking tasks without actually doing the work, but it's onerous and based on distrust. Not trusting LLMs is warranted but those rules get applied to everyone.
> The team I'm on prides itself in providing great service to our clients (other devs in the company). This includes responding to support requests even if the client isn't entirely sure how to ask or who to ask.
So in that case, you would create the ticket on their behalf before getting to work, right? Because how would you track what you have been working on, if something has happened already in the past, if there is a pattern in support requests, or how well your team reacts to support requests?