Update Engine & Interactive-UX Working Group Member lists

[kilasuit]

PR Summary

Adds Friedrich Weinmann @FriedrichWeinmann & Steven Bucher @StevenBucher98 to Interactive UX WG list
Adds Staffan Gustafsson @powercode to Engine WG

PR Context

Ensures doc containing the WG Member list is up to date

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and opened an issue in the relevant tool repository. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode
      (which runs in a different PS Host).
      • Issue filed:
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
      • Issue filed:
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
      • Issue filed:
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).
      • Issue filed:

[daxian-dbw]

@kilasuit Please resolve the failure in markdown-line CI.

[kilasuit]

@daxian-dbw I was looking into this & the tools used for linting as I disagree with the error raised. In my opinion this is something we should ignore being an issue as both bug fixes& bugfixesare acceptable terminology until I/others can work out how to silence this error which I couldn't work out exactly where to do this in looking yesterday due to mix of tooling & their differing configuration settings across them all being used here. But it's on my list of things to dig into further at some point in the not too distant future.

[kilasuit]

Also that error shouldn't really be an error but a warning as its a language preference thing vs it being something more like PowerShellvs powershell& is yet another reason why I disagree with it & think we should ignore it for now.

[kilasuit]

@daxian-dbw I could make the additional change to resolve the failure however I think that it's outside the scope of this PR so I don't think should be added especially for the reasons that I listed above, as such can we please merge this & I'll try and find where to update the tooling that throws the error to make it a warning instead which would be better suited for us going forward.

[iSazonov]

Will #20996 fix these markdown issues?

[kilasuit]

Will #20996 fix these markdown issues?

That'll only fix any checks for links, there is a linting issue caused by this line in textlint-rule-terminology which I raised this issue & hope the maintainer for that project will resolve that.

There is also what seems to be an ignoring of our .markdownlint.json in the super-linter task which is causing other incorrect errors to be thrown too & I've raised this issue to see if that will get fixed in a later release

[kilasuit]

I had attempted some changes as had been recommended in super-linter/super-linter#5101 however as they were still making the markdown-lint workflow fail I've reverted those changed. It may instead be better to replace super-linter with https://github.com/marketplace/actions/markdownlint-cli2-action (as we already make use of the vscode extension DavidAnson.vscode-markdownlint ) especially if we are only linting Markdown files. I feel that sort of change is out of scope for this PR though

GitHub

markdownlint-cli2-action - GitHub Marketplace

A GitHub Action to run the markdownlint-cli2 tool for linting Markdown/CommonMark files with the markdownlint library

[pull-request-quantifier-deprecated]

This PR has 17 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

---

Quantification details

Label      : Extra Small
Size       : +15 -2
Percentile : 6.8%

Total files changed: 3

Change summary by file extension:
.yml : +5 -2
.json : +8 -0
.md : +2 -0

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

• Fast and predictable releases to production:
  • Optimal size changes are more likely to be reviewed faster with fewer
    iterations.
  • Similarity in low PR complexity drives similar review times.
• Review quality is likely higher as complexity is lower:
  • Bugs are more likely to be detected.
  • Code inconsistencies are more likely to be detected.
• Knowledge sharing is improved within the participants:
  • Small portions can be assimilated better.
• Better engineering practices are exercised:
  • Solving big problems by dividing them in well contained, smaller problems.
  • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

• Use the PullRequestQuantifier to quantify your PR accurately
  • Create a context profile for your repo using the context generator
  • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
  • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
  • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
• Change your engineering behaviors
  • For PRs that fall outside of the desired spectrum, review the details and check if:
    • Your PR could be split in smaller, self-contained PRs instead
    • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

• One line was added: +1 -0
• One line was deleted: +0 -1
• One line was modified: +1 -1 (git diff doesn't know about modified, it will
  interpret that line like one addition plus one deletion)
• Change percentiles: Change characteristics (addition, deletion, modification)
  of this PR in relation to all other PRs within the repository.

---

Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

[kilasuit]

I had some additional feedback as possible changes to the workflow file & this then lead to noticing some additional items that could get resolved,
I don't think that I can get back to the latest build error until next week but if I can then I will do so

[StevenBucher98]

@kilasuit I created and merged a PR for updating all the additional WG memebers, it does NOT include the members you have here. I suggest rebasing as I fixed most of the linting issues in this PR: #21091

[pull-request-quantifier-deprecated]

This PR has 2 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

---

Quantification details

Label      : Extra Small
Size       : +2 -0
Percentile : 0.8%

Total files changed: 1

Change summary by file extension:
.md : +2 -0

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

• Fast and predictable releases to production:
  • Optimal size changes are more likely to be reviewed faster with fewer
    iterations.
  • Similarity in low PR complexity drives similar review times.
• Review quality is likely higher as complexity is lower:
  • Bugs are more likely to be detected.
  • Code inconsistencies are more likely to be detected.
• Knowledge sharing is improved within the participants:
  • Small portions can be assimilated better.
• Better engineering practices are exercised:
  • Solving big problems by dividing them in well contained, smaller problems.
  • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

• Use the PullRequestQuantifier to quantify your PR accurately
  • Create a context profile for your repo using the context generator
  • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
  • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
  • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
• Change your engineering behaviors
  • For PRs that fall outside of the desired spectrum, review the details and check if:
    • Your PR could be split in smaller, self-contained PRs instead
    • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

• One line was added: +1 -0
• One line was deleted: +0 -1
• One line was modified: +1 -1 (git diff doesn't know about modified, it will
  interpret that line like one addition plus one deletion)
• Change percentiles: Change characteristics (addition, deletion, modification)
  of this PR in relation to all other PRs within the repository.

---

Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

[kilasuit]

@StevenBucher98 / @daxian-dbw this is now ready for merging. Sorrry it took so long.

[microsoft-github-policy-service]

📣 Hey @kilasuit, how did we do? We would love to hear your feedback with the link below! 🗣️

🔗 https://aka.ms/PSRepoFeedback

Microsoft Forms