chelmertz
The author also published a tool for PBT:nif web front ends which sounds interesting.
Do you really think the critique of Only Fans is aimed at the consumers' experience, rather than contributing to the norm that it's OK for men to pay women to do what the men want?
- 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.
git commit -v displays the patch below the message part you're writing, so that you can review the patch as you write the message.
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 :)
Very basic and easy to get used to, fixed options for screen estate.
$('#extras').append("<a href='"+$('#player').data('jPlayer').status.src+"'>Download</a>");