From a design standpoint I like to highlight one rule: A good design is one where the most common action your users will take is priorized. If you get there alo

From a design standpoint I like to highlight one rule: A good design is one where the most common action your users will take is priorized. If you get there alone, by basar, by comittee or whatever, doesn't change that. The problem with the latter variants is that decisions are not made on principles, they just happen. For example if the overwhelming majority of users use df to get an overview of how much disk space they are using and how much they have left, the default option should be giving you a easily digestable output of precisely that. I get that in terminal-land this can be a problem, as the default df command is now probably parsed by a thousand shell scripts and chaninging it breaks things. But that is also bad design: If there are hard reasons like that that could conceivable lock you into doing it a certain way, you should warn against it and offer a stable alternative (stderr: "The output of df -h is not meant to be machine readable, use df --machine instead"). Again frequency is the guide here. People will more often type df -h to manually check things than they have to write df --machine in a script. Same goes for the default output of ip a (which in my opinion should be more like ip -br -c a).