Stderr Feedback Verbosity

[amydevs]

Specification

Since our feedback messages have been changed to be written to stdout, we haven't implemented verbosity options for these feedback messages.

How we should control the verbosity of the messages is still TBD...

I had discussed supplying a -q/--quiet option rather than changing our verbosity options. Has the default verbosity level is 0, and it doesn't seem like a good idea to change our verbosity levels to no longer match to the js-logger values.

Additional context

#56

Tasks

1. ...
2. ...
3. ...

[linear]

ENG-34 Stderr Feedback Verbosity

[CMCDragonkai]

Since our feedback messages have been changed to be written to stdout

That's not true, feedback goes to STDERR.

I think you mean command output (or command result).

Plus we are looking at this again in #17.

Actually I think #17 is better issue than this. I don't really see where this is relevant.

There are primarily 3 kinds of verbosity here:

1. Verbosity of Exception/Error Reporting that goes to STDERR
2. Verbosity of Log Messages that goes to STDERR
3. Verbosity of Status Updates that also goes to STDERR

Previously I understood 2. and 3. to be the same thing... but they are slightly different. the PK CLI outside of the agent start operation doesn't tend to use logger at all. But actually if it did use logger, its messages would be classified under 3.

Verbosity should not affect STDOUT output/result of a command. That should also be based on the output formatter.

@aryanjassal may find it useful to review #56. We really need an automatic context tracker when creating issues, like when people create questions on stackoverflow. I think tracking that as part of the project graph will be important, and creating the appropriate GH bot to do this would be useful.

[CMCDragonkai]

Closing in favour of #17.