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.
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)
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.
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.
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.
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.