chore: enforce consistent Markdown style for strong and emphasis (#37787)
This commit is contained in:
parent
f7c6545eab
commit
4415b7638a
23 changed files with 66 additions and 68 deletions
|
@ -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**
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue