I find this whole back-and-forth fascinating, because it mirrors my experiences in the workplace. There are some people who really like process around everything an engineer does, and some people who really don't like it. They're almost two distinct personality types, and it's virtually impossible to get them to agree because it's like asking someone to change their personality.
I happen to be one of the types who dislikes heavy process-oriented project management, and reading mr-ron's responses is admittedly making my blood boil. But I bet he reads some of the responses to his remarks and probably has similar reactions.
Some people thrive with heavy process, and some people wither. Some people thrive with light-weight process, and some people wither. I don't know how to structure an organization to support both types of people in it, but it's not an easy problem to solve. That's why there are so many project management methodologies, with new ones popping up every few years and then inevitably disappearing in favor of something new and better.
I think the solution is to do everything you can to keep the heavy process people away from anything important for as long as possible, before you get too big and they manage to embed themselves anyway, where they will commence to expand the bureaucracy to meet the needs of the expanding bureaucracy.
What a great comment!
The whole, every change needs a ticket debate is interesting but without context. Some orgs require it and you can just create a ticket and move on. Fundamentally I don't view these tickets as useful, if asked "tell me the latest state of X", or "why was Y done", the tickets rarely help (and if they do, the proper places of commit history or the code itself skimp on these)
The tickets can often go on to be "for the devs we like and trust, they can cut tickets", but for the others we require they're prioritized. This creates a lot of chafing, that quick bug fix, is it worth context switching now to create a ticket, again later to explain it to the non-technical prioritizer of tickets, worth the argument of why a "business goal" should be deferred to prioritize this ticket, the tracking overhead to finally say you are selecting ticket X, and that final context switch to actually work on it? All that compared to just fixing it, switching branch and cutting a pull request a minute later
I found I liked tickets to identify product work, so maybe 5% of my commits actually reference tickets, the rest are supporting changes that enabled that 5% to be done cleanly or are just things that should be fixed or cleaned.
Coming back to it, tickets have their uses: documentation, discussion, prioritizing. But tickets can quickly turn into "this is how we keep our engineers from cleaning up the code, etc", "this is how we do programming by remote and control exactly what is worked on." Worst, it is the self inflicted burning the midnight oil, "hey, you said this was going to take a week, estimation is a skill of a senior engineer - will this be done as promised, or is your ability to estimate not there yet? Wink, the sprint is over on Monday.."
FWIW, I agree with timmytokyo's assessment of 'heavy process'. I actually worked in a place where PR's need to be tied to tickets and updating documentation is the perfect example of where it sucks. Imagine you're trying to debug a bug, looking through the stack trace and trying to reverse engineer what the heck is going on. You find a block comment explaining what should be happening, but it's not been updated in years and not technically relevant to the final bug fix.
You've got two choices, either you sneak the comment block change into your PR, despite it being irrelevant and make the documentation update blocked by the bugfix/feature. Or you need to open Jira, make a ticket etc etc. I know you say it's 30 seconds, but it's not. It's at least two minutes, but it's not even the time that makes it annoying. It's the fact that you're doing something that you(the people timmytokyo describes) think is entirely pointless.
I ended up writing a janky git hook that would check if the branch name I was pushing had a jira-id in it, and if it didn't it would use the Jira API to make the ticket, grab the id and push the branch again with the id in the branch name. The fact that the entire thing can be automated, makes the entire thing pointless in my mind.
The thread gives me very strong vim vs emacs vibes :).
So the main difference is that CI tests provide useful information, whereas automatically creating a ticket from a commit provides 0 useful information, it just duplicates data.
The other difference is that CI tests do actually run automatically. If you had to go into github and press "run tests" every time you make a PR, that is a waste of time.
But sure, if there was a server side hook that automatically created Jira tickets for PR's without tickets, then the entire thing is less annoying. I still think that's a net negative since it creates noise in Jira, but it's not as bad as forcing engineers to do automatable work.
I agree that my wording was not perfect, hopefully the extra explanation makes my point clearer.
It feels heavy to me, because you're asking for a process gate to be put in front of something that is so trivial. It feels utterly unnecessary and demotivating. If I see a minor problem in the documentation and decide to correct it, now I have to go through an extra step of creating a JIRA ticket describing the minor problem I'm trying to solve, doing the correction, updating the JIRA ticket status, and possibly monitoring the ticket for future issues. It's. all. so. bureaucratic. And sadly it will probably lead me to thinking the fix is not worth my time.
Instead of trying to convince everyone that they should feel the way you do, maybe try to understand why others feel the way they do.
I think the answer to all of this is 'it depends'.
Is there already a ticket and are you working to update the app? Then update the documentation. No ticket necessary.
Are you redoing the whole set of docs to make the steps for new engineers to create their stack? Then please lets have a ticket to define the scope and audience.
Trust me that I do understand that there are many orgs that have arbitrary hurdles in place, like who can create / prioritize a ticket. My experience is, if engineers are empowered / encouraged to create and prioritize their own tickets, then its not a hurdle at all.
> if engineers are empowered / encouraged to create and prioritize their own tickets, then its not a hurdle at all
Many people - now including me - are plainly telling you that it is a hurdle for them. No amount of reframing this is going to alter someone else's experience.
You seem to keep trying to change the subject to "should there be tickets in general?", which nobody is saying there shouldn't. The topic is "should there be a ticket required for every change, which requires tickets for updating typos in internal documentation, because that requires a change and you propose that a ticket be required for every change. That is stupid, to require a ticket for that. These other examples are not stupid to use tickets to track them. But they aren't the subject of the thread.
Nah, I can just make a task and make whatever UI tweaks I want. I mean, someone will probably complain about it eventually if I make some crazy change to the UI, but there's no process stopping me from doing so. Other than the handful of clicks it takes to make myself a task for the work.
It’s not really 30 seconds though is it, if everyone is making all these tickets to do trivial things, they are getting update emails on them whenever their micromanager gets around to acknowledging them. It’s generating all the work for people to look at all these trivial tickets. You already have a source of truth on what changed - the PR. Forcing a fellow human to make a ticket that is just a link to a PR is Kafkaesque regardless of whether you “empower” your engineer to open and then immediately close her pointless tickets on her own or not.
In my experience, there's a threshold where a ticket just generates net noise on the process, which is why I don't like tickets even for things like updating documentation in code.
If you multiple that "just 30 seconds" by several trivial things you encounter each day that aren't part of your assigned lot, it adds up. Those new tickets show up in your list of tickets, so now you have several line items that have to be walked through during sprint planning or daily standup so everyone knows what's going on.
It's true that perhaps other devs want to know about that ticket to update some documentation, but it may be such a minor change that it seems silly to have to do a song and dance about it during standup so everyone has full context. And often, not everyone needs to know about every little change that is made anyway.
Then, when you look at the work to be done, the large list of trivial tasks makes it hard to see the 1 or 2 really important tasks that you're really working on.
I think the dividing line here between pro-ticket vs. not is based on how much you trust your fellow devs to the right thing and how much trust you have overall in your team as an organization. If you have little trust that people will do the right thing, you'll probably want to create a ticket for everything to make sure it doesn't go astray. Unfortunately, for those with more experience and better judgment about what is the right thing to do, they'll just feel constrained by the whole thing as it removes agency.
... they are getting update emails on them whenever their micromanager gets around to acknowledging them ...
You just nailed the problem here. If the process is set up that an engineer cannot create / prioritize / close trivial tickets themselves, that is indeed true friction.
Those problems never come in isolation. If the developers need to do useless tasks for being through, the odds are really large that they also need to answer to them for management.
A ticket supposedly represents some worthwhile task that's worth specifying. If it takes just 30 seconds to create it can't possibly concern a task that's worth the cost of involving ceremony/process.
I happen to be one of the types who dislikes heavy process-oriented project management, and reading mr-ron's responses is admittedly making my blood boil. But I bet he reads some of the responses to his remarks and probably has similar reactions.
Some people thrive with heavy process, and some people wither. Some people thrive with light-weight process, and some people wither. I don't know how to structure an organization to support both types of people in it, but it's not an easy problem to solve. That's why there are so many project management methodologies, with new ones popping up every few years and then inevitably disappearing in favor of something new and better.