chore: enforce consistent Markdown style for strong and emphasis (#37787)

This commit is contained in:
David Sanders 2023-04-03 04:20:10 -07:00 committed by GitHub
parent f7c6545eab
commit 4415b7638a
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
23 changed files with 66 additions and 68 deletions

View file

@ -8,8 +8,8 @@ Example Use Case:
* We need `VS15.9` and we have `VS15.7` installed; this would require us to update an Azure image.
1. Identify the image you wish to modify.
* In [appveyor.yml](https://github.com/electron/electron/blob/main/appveyor.yml), the image is identified by the property *image*.
* The names used correspond to the *"images"* defined for a build cloud, eg the [libcc-20 cloud](https://windows-ci.electronjs.org/build-clouds/8).
* In [appveyor.yml](https://github.com/electron/electron/blob/main/appveyor.yml), the image is identified by the property _image_.
* The names used correspond to the _"images"_ defined for a build cloud, eg the [libcc-20 cloud](https://windows-ci.electronjs.org/build-clouds/8).
* Find the image you wish to modify in the build cloud and make note of the **VHD Blob Path** for that image, which is the value for that corresponding key.
* You will need this URI path to copy into a new image.
* You will also need the storage account name which is labeled in AppVeyor as the **Disk Storage Account Name**

View file

@ -44,7 +44,7 @@ machine you can monitor compile jobs as they flow through the goma system.
For security and cost reasons, access to Electron's Goma cluster is currently restricted
to Electron Maintainers. If you want access please head to `#access-requests` in
Slack and ping `@goma-squad` to ask for access. Please be aware that being a
maintainer does not *automatically* grant access and access is determined on a
maintainer does not _automatically_ grant access and access is determined on a
case by case basis.
## Uptime / Support

View file

@ -57,7 +57,7 @@ unfriendly.
Contributors are encouraged to solve issues collaboratively and help one
another make progress. If you encounter an issue that you feel is invalid, or
which contains incorrect information, explain *why* you feel that way with
which contains incorrect information, explain _why_ you feel that way with
additional supporting context, and be willing to be convinced that you may
be wrong. By doing so, we can often reach the correct outcome faster.

View file

@ -219,7 +219,7 @@ of the area you modified in order to land. Whenever a maintainer reviews a pull
request they may request changes. These may be small, such as fixing a typo, or
may involve substantive changes. Such requests are intended to be helpful, but
at times may come across as abrupt or unhelpful, especially if they do not include
concrete suggestions on *how* to change them.
concrete suggestions on _how_ to change them.
Try not to be discouraged. If you feel that a review is unfair, say so or seek
the input of another project contributor. Often such comments are the result of