Many, many years ago I used to have two Wyse50 terminals, running split screens each with two parts. I did a lot of support on remote systems (via modem!) and I would have a session on a customer system, source code and running on our test system and internal stuff. I didn't have space for a third terminal.
At another job I had an office with a "U" shaped desk. I would spread printouts across half the "U" and swivel around between the computer and the printouts.
My first experience with this food was in Halifax decades ago. The Halifax Donair is a unique thing.
And it's definitely Donair, not Doner.
I always thought of "Briton" in that last sense, while "Brit" has the meaning of anyone living in the UK (almost). But that's from an outsider's perspective.
As my English cousin corrected me, though, "I'm English, 'British' could be anything!". She wasn't, of course, talking about the difference between English and Welsh, or Scots.
I'm totally unqualified to comment on this, but something has always itched in my brain about dark matter. It smacks, to me, to be the aether of the 21st century.
Except this is Canada, and $7.50/hr is about as relevant as comparing it to child labour in a t-shirt factory in Bangladesh.
The workplace should have a zero tolerance policy about abuse of the staff. If the particular location is one where there is a significantly non-zero chance of such incidents happening, then there should be a big red button on the wall that sounds and alarm, and summons security and possibly triggers a police response.
Employees should be trained to hit the button at the first hint of abuse. The employer should support them.
I'm not sure a corvette has ever counted as "major" warship.
The "supposed to be...", is a really big problem.
First, it's factually wrong. Homosexuality occurs all through nature and it's not a mistake or random abberation. Presumably there's some advantage to having a percentage of any population not reproducing. Perhaps so that they aren't burdened with children and are free to fill other roles in their community, herd, flock or whatever. This increases the group survival/reproduction rate, even though they aren't reproducing themselves.
Secondly, "supposed to..." implies that there's something wrong with any non-heterosexual individual. It sounds like, at best, you'll accept their homosexuality as natural but, at the same time, you understand that they're actually defective. That attitude isn't going to lead to good things, and not something I would like to see widespread in society.
And finally, the fact that you would even say this points out the need for more education on this in schools, not less.
I never expected to see a compiler in this list, at least not in 2023.
Back in 1988 I realized how rubbish Microsoft was when I discovered Borland's Turbo Pascal and Turbo C compilers. I'd previously used the MS compilers and they were multipass, multi-minutes to finish a compile. The Borland ones were single pass and FAST.
Back then, compile times could be huge, and everyone was publishing benchmarks on compiled program performance, which mattered on the hardware of the day. I never even think about that stuff these days.
Calling customers, "guests". A customer is someone with a business relationship with someone/something else. They're exchanging money for goods and services and have a right to expect certain value for their money.
A guest is something else entirely. A guest has no implicit right to expect a certain any particular level or quality of services. They are dependent on the magnamity of the "host".
Calling a customer a "guest" robs them of status.
I always thought Timothy Zahn was an above average author, and to wrote more than a dozen of them.
For some reason, the wife decided to pull out all of the amigurumi critters that she's made since she started doing this at the beginning of the year.
So, here you go, the group shot:
She said that the pattern was awful and that she had fudge all kinds of stuff to make it work. The hat needed to be completely redesigned.
The wife has started to make these amigurumi creatures. Here's her latest two.
She uses worsted weight wool (she tells me) which generally results in bigger creatures.
I wanted one of these back in 1980 when I was 16. I remember that they were $1,200, but they might as well have been $1,200,000 as far as I was concerned.
Many years later I had the $$$ to buy one, and this one is a beauty. Koa, with Bill Lawrence pickups.
Look at all the knobs and switches!!!
In a way, this question itself is very "un-agile". Agile should be always forward-looking, "What can we do next?", "What can we get done in this short period of time?", "What should we do next?".
OK, so you found a possible "defect" in your system. Is it a defect, or did someone slide in a requirements change 3 months ago?
This reminds me of playing chess. Sometimes a player will make their move when their opponent is distracted. The opponent hears, "Your turn", and they look at the board. "Which piece did you move?". The first player just shrugs.
The point is that you shouldn't need to know which piece just moved. Every chess position is a "state" of its own, and your best move should depend on going forward from that state, not knowing how the board changed recently.
It's the same thing here. You have a situation. Does it really matter how, when, who or why it happened? It shouldn't, and here's why:
Just because it's a defect (if it is) doesn't automatically mean that correcting it moves to the top of your "to do" list.
It's going to take some non-zero amount of time to change it back to blue. And when you're doing that, you're not doing something else. There is always an opportunity cost to doing bug fixes and you shouldn't treat them in an ad-hoc way. Should you be spending that time, and who gets to decide if you do? It's not your decision. It's the PO's decision to make.
Maybe the PO doesn't care about the colour. Maybe they do care, but not if it means some other feature gets delayed. Maybe it's the most important aspect of the whole system, and there's no way you can launch with it green. So you cancel the current Sprint and start a new one dedicated to fixing this defect! Maybe they regret asking for it to be blue, and now they're happy that it's now green.
If it was me, I'd get a quick T-shirt size estimate on the work required to change it back to blue, then put it in the Product Backlog to be reviewed with the PO. Maybe have a quick chat with the PO, or send a memo about it. Maybe the PO will need to check with their SME to see if anyone remembers asking for it to be changed to green. Maybe not. In any event, it either makes its way into a Sprint Backlog or it doesn't.
Also, if you're doing Agile right, then your clients are getting constant, hands-on, experience with your system as it is being developed. To go 100 days without some kind of "release" that they can play with and give you feedback is an anti-pattern. If you are giving them the latest version every week or two and after almost three months they haven't noticed that the footer is green, then it's probably not important.
On to the actual question. Jira is a potential sand trap of administrative complexity. The answer is usually to keep everything smaller. Smaller features, and smaller Sprints. Smaller teams. A team of 5 or 6, working in one week Sprints, can only do so much per Sprint. If your fundamental unit of work - a story, or a feature, or a ticket - is set to take something like 1/2 day and forms the basis of your Sprint Backlog, then each programmer on the team can do at most 10 SB items (in a perfect world). Depending on the composition of your teams, you're probably going to have only about 3-4 programmers - which means 30-40 tickets per Sprint Backlog. And that's a blue-sky number that's practically impossible in a world with meetings. A team of 5 or 6 is going to complete closer to 20 Sprint Backlog items in 1 week Sprint in the real world.
The point being that 14 Sprints is your 100 days and each Sprint has about 20 easy-to-understand items in it. Whatever your management tools, it's a failure if you can't locate those 280 features in a matter of seconds. And it should be easy to eliminate 270 of them as not possible places where the change happened just from the description.
And when those SB items are small, as they should be, it's not an onerous task to document inside them the requirements that they are supposed to meet.
When you have 1 month Sprints with tickets that take 2 weeks to complete, then everything becomes a nightmare. It becomes a nightmare because it's virtually impossible to impose some kind of consistent organizational structure internally on free-form stuff that big. But it's almost trivial to do it with tiny tickets.
And the other thing that happens with big tickets is that there's tons of stuff that programmers do without thinking about it too much. If you've got two weeks to finish something, then there's a ton of latitude to over-reach and the time estimate was just a wild guess anyways. If you have 3 hours to do something, then you're going to make sure that what you need to do is clearly laid out - and then you have to stick to it or you won't get done in time.
Did somebody "fix" the inconsistent footer colour while doing some huge, 2 week, ticket? Good luck finding out. But that's not going to happen with tiny, well documented tickets.