The alias for -Verbose is -vb and the alias for -Debug is -db ...

Should their respective Action and Variable short forms start with those prefixes?

That is, should -VerboseAction be -vba instead of -va, etc.?

I'm not sure. Certainly the InformationAction is the only one of the existing aliases that isn't a two-letter alias (and I don't actually know why), so there's good reason to stick with 2-letter initialisms.

I'm not sure either. Also, used three letters for the progress aliases (pra and prv) to differentiate them from the -PipelineVariable alias while maintaining "suffix" consistency between them and with the other aliases.

That is, should -VerboseAction be -vba instead of -va, etc.?

I don't think we want vba in PowerShell. 😝

Kidding of course. I'm not attached to anything I chose...I just picked what made sense at the time.

We should probably also make note that using -v as a shorthand for -Verbose is pretty common, especially in interactive cases.

If we're adding more parameters that by default conflict with that shorthand, we should probably add that as an explicit alias as well. :)

So here's an idea. These new parameters make the usefulness of -Verbose and -Debug questionable. Those are convenient, but not as capable as the new common parameters. What if -VerboseAction was defined as a Switchable<ActionPreference>, where Switchable<T> is a new generic type whose constructor accepts the true and false T values for the type, plus assignment operators for bool and T, and an implicit conversion operator to T. Switchable<T> would also need to be supported in the parser as a parameter with no value, of course. This is just thinking out loud, but I've been brainstorming some ideas on how I could obsolete old switches without breaking scripts, and with a proper alias plus the Switchable<T> type, this would allow switches like -Verbose and -Debug, and even -Information if we wanted it, to just work as if they were common switch parameters without even having them explicitly defined (-Warning, -Progress, and -Error would not be necessary since those messages are shown by default).

The benefit with this approach is to simplify and normalize the common parameters without losing muscle memory and without breaking existing scripts. This generic type would also provide a pattern that would allow for switch replacement in any other command, should the need for that arise.

Here is a screenshot that shows what ProgressRecord output looks like using the formatter:

Aside: That this screenshot demonstrates the problem identified in issue #10236 (many *Record types default format does not identify the actual type of message that is being conveyed, but they really should for logging/review/searching purposes).

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

This pull request has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 15 days. It will be closed if no further activity occurs within 10 days of this comment.

C'mon, guys. 1.5 years post PR submission, you finally move forward with some action on this, but then your attention wanes at the end when some important questions are put on the table, and then you let it go stale and be closed? Travis Plunk (@TravisEz13): How was this marked waiting on author when the author (me) had responded with questions back to Paul Higinbotham (@PaulHigin)?

It really is no wonder why I put my I put my interest in pushing PRs into this repo on hold until you all could catch up with the PRs that were already open and the discussions that were already started. I'm not all that surprised that this hasn't happened yet, but what does surprise me is that rather than properly managing what's there, you're allowing it get discarded. Such a waste.

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

I'm walking away from my open PRs. I'm not really involved in PowerShell much these days. Personally I spend very little time using it, and at this point I don't have the time nor the motivation to deal with PRs submitted over 18 months ago.

As a point of feedback, this community is stagnant and unhealthy to participate in. It takes far too much personal effort and lobbying like a politician to get anything moving. Ideas on how to help the community move forward take years, and years, and years to bear any fruit at all. In software development, there is a balance between driving software forward based on internal business and internal/external customer priorities, and driving features and functionality that are quality of life improvements for the community of users using a product. This community has been, and in my mind clearly still is, focused almost exclusively on the former, and only considers the latter when it is of benefit to their goals for the former. It is not balanced at all when it comes to community contributions. Glancing at the history of closed PRs, and who those PRs come from, is clear evidence of this, and it seems obvious where your focus is internally for team member MBOs.

Kirk Munro (@KirkMunro), I was going to say that we'll miss your contributions in all forms in this community.

But then I realized: there is no we.
But first, let's invite a few more people to the good-bye party: Steve Lee (@SteveL-MSFT), Joey Aiello (@joeyaiello), Bruce Payette (@bpayette), Rob Holt (@rjmholt), Sean Wheeler (@sdwheeler).

I share your assessment of what is problematic about this community; let me point to two particularly striking examples that I've personally expended a lot of energy on:

• Do not require { ... } (curly braces) around variable names for null-conditional member access #14025 (comment) (not requiring {...} around variable names for the null-conditional operators, ?. / ?[])
• Implement accommodations for Windows CLIs, notably batch files and misexec-style programs as part of experimental feature PSNativeCommandArgumentPassing #15143 (comment) (comprehensive solution to the perennial quoting headaches when calling native executables)

In my perception, these two issues (the specific comments tell the history) exemplify several problematic patterns:

• Fiat decisions handed down with little to no explanation, often indicative of unawareness of the specifics of a proposal / lack of sufficient subject-matter expertise, followed by unwillingness to explain or debate the decision.

  • Working groups were supposed to help with that, but in my personal experience it seems to be just more of the same.

• Many quality-of-life-improvement proposals either getting ignored altogether, being met with indignant pushback ("very much by design"), argument-less claims of lack of arguments ("I don't believe you've made the argument sufficiently"), followed by eternal silence when counterarguments are made.

• Vague promises of revisiting issues that never materialize.

I hope that the many talented people that still make up this community have the stamina to continue to contribute, as things - hopefully - improve, but personally I feel burned out and, save for perhaps filing the occasional bug report prompted by real-life use, I will cease my activities here and in the docs repo.