ndh2

When using bug trackers, I find the most frustrating aspect is the "non-linearity" of the workflow. By that I mean, how do I answer the question "What am I supposed to do next?". You can sort by project, or by priority, but what I typically end up with is a list of items that I already looked at a dozen times. And even though I don't want to look at them a second time, I haven't found a way for a bug tracker to do that for me. Ideally, I would want to look at each task at most two times: Once for triaging, and once for working on it. That's it.

So the way I understand it, you're trying to address this, at least partially. A task starts out as untriaged, then you tag it as triaged, and that means you only had to look at it once for triaging. Which is great, because it's a linear workflow.

Some tasks are obviously critical, and will end up in the next open release milestone. Some belong to a feature that is not released yet. But what about the stuff that ends up in the backlog? These smallish, nagging bugs that are not super-critical. That is the big, ugly pile that keeps growing and growing. How do you keep that big pile manageable? Ideally, that pile shouldn't become big in the first place, but how do you prevent that from happening?

I've only read half of it, but I liked it a lot. What about you? Did you like it? Why?

> @Airbus is almost finished with their A380 Christmas tree. Will they put a star on top?

4chan is like a pub without regulars. You can't go there to meet specific people.

Record 30 seconds without ums. If you failed, do it again. Then increase the time. Stop if you fail to much/can't concentrate, try again tomorrow. Recording yourself is the perfect opportunity to train.

They should have used only ms/ns for every timing/graph, not FPS or relative percentages of whatever that was.

These "questions" invariably come across as "this thing sucks because it's not the thing that I am used to".

Sorry if this brings up bad memories for you.

I use an old, discontinued app called Executor that I configure manually. It's not a whole lot better in terms of matching, but, because it can be configured, it is much better in terms of getting it to do what I want. It definitely can't track your packages, though.

http://www.executor.dk/

Why is it ok to design and build algorithms that make people unhappy?

Okay...

Does this guy have any articles on software bootcamp where drill sergeants scream at you to break you?

I believe the main problem is knowing which data to trust and which data to discard. Reflections (water, shiny surfaces), moving objects (leaves in the wind), over-exposure, and lens flares are already pretty hard to deal with. But with low resolution data, you make it even more difficult because there's more data to discard for being too inaccurate.

https://iapreview.ars.usda.gov/research/publications/publica...

> Despite greater total availability of energy, a feasible solution could not be identified, meaning that the yearly nutrient requirements of the U.S. population could not be met under the defined constraints. Deficiencies in vitamins (A, D, E, B12, and choline) and minerals (Ca) were the primary cause of this infeasibility. Although eliminating animals from the food production system may seem advantageous based on surface-level comparisons of system energetics, a more comprehensive analysis of the food production system highlights the unique and essential role of livestock products in the food production system. This suggests that substantial gains in environmental impact could be made by simply reducing daily intake, rather than affecting dramatic shifts in consumption pattern.

Two animal scientists had a silly hypothesis "is it a good idea to remove all farm animals", and proved the answer to be no.

Too bad they don't provide access to these studies. To me it looks like they just left it at that, and didn't investigate any further, e. g. the question of how many farm animals could be removed while still meeting all dietary requirements.