HN user

chelmertz

59 karma

https://iamnearlythere.com https://helmertz.com

Posts0
Comments14
View on HN
No posts found.

Try reading the GTD book. What could have been a flowchart, maybe bundled with some potential downsides/gotchas-and-how-to-avoid-them, somehow became this nonsense 300-page sleeping pill.

If the goal is to either reduce the number of open issues, or make it easy to find the most recently reported/recently active issues, it could be accomplished in other ways. What about:

- not having "TOTAL issues" as a counter, but "TOTAL RECENTLY ACTIVE issues", for some value of "recently" - defaulting to only showing the RECENTLY ACTIVE issues when searching for them (or finding them through other views) - displaying a warning such as "this issues is dusty, consider it not being prioritized highly"

As with all other bug reporting systems, having slices/views to work with seems to be preferred to closing issues. Someone supporting the product might really want to find the issues being "most reacted to" recently, the planning "product manager role" maybe only wants to see the high level "epics/initiatives/visions" in a certain order, etc.

I think much of this comes down to all issues being on the same "level" in a Github issue tracker, i.e. "tagging is enough", which some projects solves with a huge taxonomy, and some don't.

This is a really interesting problem area. Tests that fails sometimes are really annoying because of the "broken windows" analogy. Are you using the most unstable tests as input of what to redesign next? Is it kind of a "deal with it" situation, where you need to retry the test suite a couple of times per commit, until it becomes green?

OT: Just in case webdevs reads this: you might want to markup clickable things as clickable (<a>). If you need a datapoint: I'm using Vimium for Chrome.

Webwatch 11 years ago

I mean, a tool can be really useful (I write tools this size all the time) but some of them needs tweaks forever. I just think some 'tweaks' are already solved by other projects, that's why using already written tools that are somewhat UNIX-y sounds like a good idea to me. That's what I tried to say; of course I don't want you to write a 100% complete program in the first commit, that would make everything I write look really bad in comparison. Just be prepared for that pull request that lands basic auth in your project, and the next PR after that :)

Webwatch 11 years ago

By looking through the git history of your project, it doesn't seem you got it correct the first time either. I don't think gluing "UNIX tools" together biggest strength is "make it work fast & on the first try", but "have independent tools that does 'one thing' well".

In relation to your tool, I think curl provides very many more features that are easily accessible through command flags than the limited subset of HTTP capabilities you expose (for example, basic auth or different set of headers). The same argument goes for mailing, setting headers or such.

With that said, tools that does one thing and does it well are the ones that gets used, personally I'd just prefer it to be function in <your-shell> instead :)