Incorrect and error riddled instructions.

[hunterhogan]

Patently incorrect grammar

vscode-pull-request-github/package.nls.json

Line 15 in 5f48d91

"githubPullRequests.logLevel.description": "Logging for GitHub Pull Request extension. The log is emitted to the output channel named as GitHub Pull Request.",

Incomplete sentences

vscode-pull-request-github/package.nls.json

Line 81 in 5f48d91

"githubPullRequests.pullPullRequestBranchBeforeCheckout.description": "Controls whether the pull request branch is pulled before checkout. Can also be set to additionally merge updates from the base branch.",

Incorrect handling of proper nouns

vscode-pull-request-github/package.nls.json

Line 98 in 5f48d91

"githubIssues.ignoreMilestones.description": "An array of milestones titles to never show issues from.",

Lack of humility

#7355 (review)

Impact on AI assistants

The unacceptably poor writing in Microsoft documentation negatively impacts the performance of Copilot: a product I pay for. Microsoft refuses to pay for professional writing, and the results are predictable. #7355 was not an altruistic act. I was trying to mitigate the effects of crappy writing on the responses I get from Copilot.

Competent writing

Until Microsoft implements basic checks to prevent incompetent writing, Microsoft should learn to recognize competent writing and graciously accept free labor from an experienced and highly trained writer.

Litmus test

1. Can the inclusion or omission of a full stop affect the performance of machine natural language processing?
2. If so, in which situations should one include or omit a full stop?

A writer who does not know the answers to these questions and many related questions is incapable of consistently drafting competent copy.

[alexr00]

@hunterhogan I would recommend creating the issue before creating the PR and linking the issue in your PR In the future. The PR description did not give me an idea of why you created the PR and thus didn't give me a reason to accept the PR.

[hunterhogan]

@hunterhogan I would recommend creating the issue before creating the PR and linking the issue in your PR In the future. The PR description did not give me an idea of why you created the PR and thus didn't give me a reason to accept the PR.

I asked my question before I read this.

How can we make this work "at scale"? While reading and learning about Redis, for example, I ultimately opened four pull requests. My "workflow" for editing is pretty simple:

1. See an error.
2. If I have time, edit the file on GitHub because GitHub will automatically manage the fork, the commit, and the Pull Request.
3. There is no step three.

Furthermore, I don't want to call out programmers for having typos in their documentation: I just want to correct the typo. I feel like creating an "Issue" is confrontational, but I could be completely wrong.

You have already improved my understanding of this situation, and I hope I am able to learn more from you.

[alexr00]

I'm sure it depends on the project, but here issues are not considered to be confrontational.