Almad

That's from the good old days where truth mattered. Like how many action movies are about "getting the truth out" where that act in itself brings consequences, cut, happy ending?

Compare with now: revolution may be televised, but its spread not amplified and its authenticity denied. And if you have sufficient tribalism, it will not make a dent.

From what I know, politologists are analyzing the situation in US from a perspective of "mid intensity civil war".

So what you're writing is aligned with tactics you'd expect...?

So what are the sources for people driven insane by it?

(I have no opinion, but find it mildly suspicious given that I happen to sometimes drive through Germany, and the country seems to be currently less insane than, say, US)

> Gradle files (worst abomination of a build system ever)

Ant? Maven?

Not always. You may also end up with having incompatible set of ciphers (happened to me).

"Get off my Internet lawn if you can't be up to date" is what we're saying and I just do wonder whether we haven't exchanged too much of accessibility for too little of security.

Internet starts to have 1y memory retention.

Unless refreshed by active learning, aka someone doing the refresh job.

Or unless delegating the work to large players—either the memory or the hosting.

EDIT: This feels wrong, even when done for right reasons. And I wonder whether this would fly without LE and whether this means we are officially making LE THE critical part of Internet infrastructure.

I'd say quite the opposite. What you say is one of the myriad of considerations that should go into prioritization by the team, yet is super hard to capture by any hard attribute as I believe the "positive/negative mental health effect" is way more complicated than "bug/feature", yet known by the team.

One of the reasons I am delaying design is getting deeper into accessibility and readability research. And I have decided to write some content first ;)

If you mean how to prevent them, well, no bugs so no way to create them.

If you mean how they handle them, there is an incident procedure for that. If it's not really an incident but, well, I need this next week for Gartner Magic Quadrant...I have phone numbers of managers in my reporting chain.

In both companies I've been using that, it was a very simple RT/JIRA-SD-style system: "open a subject/text ticket, clock starts ticking, on call engineer gets a non-wake-up memo and will reply with high priority during work hours" and ticket will get closed ASAP and we do achieve inbox 0 regularly.

Yes, there are obvious issues and it requires two things to work:

1) If you actually have no clue about the product, you are respectfully told to fuck off to normal user support channel 2) If you keep misusing this for user support / slack channel, you get your access revoked.

...which are hard sells in large companies, of course—on the other hand, in BigCo I got success in getting an engineering headcount to accommodate that.

True. I think one of the issues is slapping an issue tracking system on a bunch of different problems.

As mentioned, this is true for versioned software, not for continuously deployed SaaS.

Thanks, this made me think. My first knee-jerk reaction was something about things and implicitness, but after some consideration:

* I am not sure "who reported the issue" is actually important, but rather "who is the contact person to get more information about this issue" and "who should be informed when this is done for verification", where "verification" means "satisfies expectations now" (as opposed to QA meaning of the word)

* Reported happening/expectation is a good point for any expectation mismatch report. I am not sure it should be there for all issues though as I find it can decrease clarity in the same way artificially requiring the "As X, I need to do Y in order to achieve Z" does

I completely agree and I hope I explicitly mentioned it in the article: it's not Jira, it's about how people/organizations often think about the problem.

"Season to taste" I totally agree with, no way to capture the whole world in a signel post ;)

> I agree that ultimately (and quickly) the bug needs to land with a single person, but the component matters in the routing step before that. Because you'll have frontline triage who can only vaguely figure out where the bug goes, second-line triage might get the team right, and then the team needs to decide where it goes.

I do agree it's about routing. My problem with components is alignment with teams and their stability over time and survival of existing tickets across those changes, which is why I think different routing mechanisms are better. But yeah, if it works...

> Same goes for priority - sometimes you do need it. That zero-day you're fixing is a "drop everything else" bug.

I call those "an incident" and in every environment I've been at, everybody knew which one it is very well without any labels ;)

> But that isn't correct. You can have a team pull from a single queue of tasks assigned to the team as a whole. There's no need to proactively assign them to individual team members.

Agreed. My point was more about that there has to be a single person responsible for making sure there are no leftovers.

> But the development team itself can do that, no problem.

Yup. To the domain point, I do think that collaboration on that boundary is needed.

> It's relevant to estimating velocity (...)

Fair, if you only define velocity as adding features and if you automatically prioritize bugs.

> We must recognise this as simply being an expression of the author's deletionist aesthetic preference, not a fact about the world.

I think this doesn't hold over long term. It is true as long as you do have an idea what's in the rest of the pile. But the moment you change the person responsible for managing the tickets and suddenly they have thousand tickets to go through and orient themselves in, it matters. And if they don't go through all of them, they don't actually do the prioritization against each other.

As the frontpage says, intentionally deferred :P

I actually never new about bugs being assigned to people as opposed to products, interesting to know.

I do agree it can totally suck to be on the receiving side.

Note: Author is Eastern Europian, so #totes

Fair, although, depends on scale again. As they say, at scale, every implementation detail is something customers rely on :)

Hmm, I communicated wrongly then. Because the separate system for issues is for a different team and a different purpose and no, it's definitely not a solution to the problem, but rather a prerequisite for the outlined system to have a chance at working at all.

The main problem I had with them is inability to sort them in a list, which is somewhat solvable with GH Projects now.

In my experience, the final sorting needs to be done by a collaboration between ticket manager and someone-who-understands-technology anyway. If the ticket manager doesn't have a clue, they can't make judgement calls necessary as for nontrivial software, it can be hard to say if this is one day or one year of work.

And that affects prioritization a lot.

Happy to, glad you like it

I'd agree with you if I would be only seeing the teams through my management reports and not from the trenches.

I am envious of the environment where you never saw somebody trying to bug feature request as a bug. I do think in a lot of cases, it's a judgement call...or a habit where problems perceived as bugs by customers are swung under the carpet as features as bug is only defined as "deviation from requirements".

Fair on distinction of severity by customer vs priority by team, although I am used to make a distinction between support ticket by customer and issue in engineering team's queue.

Lead implies either managerial or technological leadership and especially in mature organisations, I've seen both.

My experience with management by bug statistics is...very inconsistent as it motivates people to game the system...and boy I've seen that a lot. I do agree trend knowledge helps, but I am not sure it's worth the side-effects and work.

Of course, a flavor of this depends on context (and scale). It is very different if you have a single-instance SaaS, distributed system or images shipped to air-gapped systems.

Thanks!

Yeah, this is something worth a separate article (this one felt long already): ticket systems as reporting tools.

I do agree completely on "failed promise" and this is actually why I think the bug vs feature is flawed. I think "failed promise" is a great ticket type though ;)

There are obvious cases where I have nothing against what you say. But to use the analogies, "I thought the food would take differently and I don't like this one" is the more common type and it's the one that's murky to resolve.

The point here is that regardless of the reason, you want to tend to "customer is not happy" case.