> the "stronger" road user is at fault unless proven otherwise
In general I agree with this, but a lot a lot depends on how "unless proven otherwise" is interpreted.
If a driver is typically at fault when a pedestrian or cyclist unexpectedly moves into their path then it seems like that practically restricts cars to speeds close to biking or walking in many cities.
Similarly, if a cyclist is typically at fault when a pedestrian unexpectedly moves into their path then it seems like that restricts bikes to speeds close to walking in many cities.
This effectively pedestrianizes car lanes and bike lanes which would be lovely in some areas, but it also restricts travel to walking speeds which also has downsides if enforced across an entire city.
> People cycling, riding a horse or driving a horse-drawn vehicle should respect the safety of people walking in these spaces, but people walking should also take care not to obstruct or endanger them.
Does your forever limit apply to names besides "Asimov"?
There are a lot of companies and projects that have used the names of real people without that person's involvement or approval: Einstein, Tesla, Edison (besides the ones related to his company), Darwin, Beethoven, Mozart, Newton, Kepler, Galileo, Copernicus, Archimedes, Socrates...
> Adding filters so that developers only look at actionable tickets would be much more sane.
That's a reasonable approach, but I don't understand how it's any more or less sane than autoclosing them with a stale label.
Whether these sorts of bugs are "open but stale" or "closed because stale" seems like it depends on whether the project defines "closed" as "no work planned" or "fixed", which both seem valid.
Either way these bugs will be hidden from developer dashboards but still available in the database so there's no practical difference, you just need to make sure everyone is on the same page about the meaning of "closed".
To some people "open" means "not fixed" whereas to others it means "more work planned". I've worked on projects with both interpretations and it's fine as long as everyone is on the same page.
> It costs nothing (except pride?) to leave "Issues (1)" if there is indeed an Issue.
In our case we omit bugs we couldn't reproduce from the issues list due to practicality, not pride -- our software has tens of thousands of unreproducible bugs and having them show up in reports would drown out planned work.
And it's not like anyone deleted or locked the unreproducible bugs, they are either tracked as "open but unreproducible" or "closed because unreproducible". Either way they're still in the database in case more information comes along, but still filtered out of the vast majority of dashboards.
Conversely, what's the harm in closing the bug? (As long as you don't lock or delete it, I agree that's bad.)
People focused on the work often interpret "open" to mean "requires work" and "closed" to mean "no planned work" in which case keeping an unreproducible bug open is dishonest because it falsely implies that someone might continue to work on it.
Whereas people focused on the problem often interpret "open" to mean "not fixed" and "closed" to mean "fixed" in which case closing an unreproducible bug is dishonest because it falsely implies that it's no longer a problem.
Neither seems right or wrong as long as everyone on the project agrees which interpretation you're using.
> If you want to do it, do it. If you don't, then don't.
Three of the "four ways to lose" described in the article are significant harms inflicted on parties besides the bettors themselves. One cannot avoid these harms by not directly gambling.
The doomsday preppers with a scarcity mindset and a bunker full of tin cans and military surplus make for good TV, but plenty of "preppers" don't look like that.
They also have a well-stocked pantry but focus more on strengthening the community to absorb shocks. Things like mutual aid networks, skill sharing, tool libraries, noodling with GMRS/HAM/LoRa comms, going on camping trips, helping each other out with kitchen gardens, and general community resilience. This approach doesn't cover every disaster scenario but it seems like a more pleasant (and realistic) option for the ones it does cover. And if nothing truly bad happens then at least they got to spend time doing things like gardening with their neighbors.
Being able to have offline Wikipedia, maps, and educational tools would be useful in either case but potentially even more so as a community resource because there are only so many skills each individual can learn.
I think another difference is that the Cambrian explosion of web apps vying for user attention meant that many web users had experience using both poorly-designed web apps as well as well-designed web apps and could gravitate towards the latter.
Whereas many Notes applications were internal so there was no "survival of the fittest" and the UI toolkit was passable at best. As a result, many Notes users never experienced a well-designed Notes app.
DARPA projects from more than a decade ago (VSAM/WAMI for arial platforms like Gorgon Stare) used arial imagery to capture ground shadows for gait tracking purposes.
From chatting with some of the researchers many years ago my understanding is that it usually wasn't accurate enough for unique identification and the gait shadow was dependent on shoe type and clothing, so a persistent gait shadow database wouldn't have been useful. But it could be correlated with ground-based surveillance for identification, for example person A and B were identified on a ground-based security camera entering a building, then gait tracking could be used to monitor where they went after they left the building even if they avoided ground-based security cameras after that point.
reply