You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
General correction of language, style, and wrong links (#436)
* correction of language style and wrong links
* revert changes based on review
* change based on ee7's review
* change url based on ee7's review
* Update pull-request-guide on erik's review
Co-authored-by: Erik Schierboom <[email protected]>
---------
Co-authored-by: Erik Schierboom <[email protected]>
Copy file name to clipboardexpand all lines: building/configlet/lint.md
+16-14
Original file line number
Diff line number
Diff line change
@@ -526,24 +526,26 @@ The `config.json` file should have the following checks:
526
526
527
527
## Glossary
528
528
529
-
1. Non-blank string: a string that contains at least one non-whitespace character.
530
-
2. kebab-case string: a string that contains only characters in the range `[a-z0-9]`, optionally separated by dashes (e.g. "two-fer"). It must match the regular expression: `^[a-z0-9]+(-[a-z0-9]+)*$`
531
-
3. Title Case string: a non-blank string that follows the below guidelines (from the Chicago Manual of Style, see https://en.wikipedia.org/wiki/Title_case):
532
-
> - Capitalize the first and last words of titles and subtitles.
533
-
> - Capitalize "major" words (nouns, pronouns, verbs, adjectives, adverbs, and some conjunctions).
534
-
> - Lowercase the conjunctions _and_, _but_, _for_, _or_, and _nor_.
535
-
> - Lowercase the articles _the_, _a_, and _an_.
536
-
> - Lowercase prepositions, regardless of length, except when they are stressed, are used adverbially or adjectivally, or are used as conjunctions.
537
-
> - Lowercase the words _to_ and _as_.
538
-
> - Lowercase the second part of Latin species names.
539
-
4. Sentence Case string: a non-blank string that follows the below guidelines (see https://en.wikipedia.org/wiki/Letter_case#Sentence_case):
540
-
> - Capitalize the first word of the sentence, as well as proper nouns and other words as required by a more specific rule.
541
-
5. Valid `"files"` pattern: A non-blank string¹ that specifies a location of a file used in an exercise, relative to the exercise's directory. A pattern may use one of the following placeholders:
529
+
1.**Non-blank string**: a string that contains at least one non-whitespace character.
530
+
2.**kebab-case string**: a string that contains only characters in the range `[a-z0-9]`, optionally separated by dashes (e.g. "two-fer"). It must match the regular expression: `^[a-z0-9]+(-[a-z0-9]+)*$`
531
+
3.**Title Case string**: a non-blank string that follows the below [guidelines from the Chicago Manual of Style](https://en.wikipedia.org/wiki/Title_case#Chicago_Manual_of_Style):
532
+
- Capitalize the first and last words of titles and subtitles.
533
+
- Capitalize "major" words (nouns, pronouns, verbs, adjectives, adverbs, and some conjunctions).
534
+
- Lowercase the conjunctions _and_, _but_, _for_, _or_, and _nor_.
535
+
- Lowercase the articles _the_, _a_, and _an_.
536
+
- Lowercase prepositions, regardless of length, except when they are stressed, are used adverbially or adjectivally, or are used as conjunctions.
537
+
- Lowercase the words _to_ and _as_.
538
+
- Lowercase the second part of Latin species names.
539
+
4.**Sentence Case string**: a non-blank string that follows the below [guidelines](https://en.wikipedia.org/wiki/Letter_case#Sentence_case):
540
+
- Capitalize the first word of the sentence, as well as proper nouns and other words as required by a more specific rule.
541
+
5.**Valid `files` pattern**: A non-blank string¹ that specifies a location of a file used in an exercise, relative to the exercise's directory. A pattern may use one of the following placeholders:
542
+
542
543
-`%{kebab_slug}`: the `kebab-case` exercise slug (e.g. `bit-manipulation`)
543
544
-`%{snake_slug}`: the `snake_case` exercise slug (e.g. `bit_manipulation`)
544
545
-`%{camel_slug}`: the `camelCase` exercise slug (e.g. `bitManipulation`)
545
546
-`%{pascal_slug}`: the `PascalCase` exercise slug (e.g. `BitManipulation`)
546
-
6. Unique version 4 UUID string: A string that satisfies all of these conditions:
547
+
6.**Unique version 4 UUID string**: A string that satisfies all of these conditions:
548
+
547
549
- It only exists once in the track-level `config.json` file of a given Exercism track
548
550
- It does not exist in the track-level `config.json` file of any other Exercism track
549
551
- It does not exist in any `canonical-data.json` file in https://github.com/exercism/problem-specifications
Copy file name to clipboardexpand all lines: building/github/contributors-pull-request-guide.md
+8-7
Original file line number
Diff line number
Diff line change
@@ -1,41 +1,42 @@
1
1
# The Contributors' Guide to Pull Requests
2
2
3
3
Thank you for wanting to contribute to Exercism!
4
-
Before creating a pull request, please read the [how to make a great Pull Request][how-to-make-a-great-pr] guide which aims to help you with the non-technical side of pull requests so that you have a great experience and help our maintaining team at the same time.
4
+
Before creating a pull request, please read the [how to make a great pull request][how-to-make-a-great-pr] guide which aims to help you with the non-technical side of pull requests so that you have a great experience and help our maintaining team at the same time.
5
5
6
6
This documents contains some additional, Exercism-specific guidelines for different types of pull requests.
7
7
8
8
## Exercise Pull Requests
9
9
10
10
Creating a pull request for a Concept Exercise or Practice Exercise can be daunting with the many rules around these types of exercises.
11
-
For this reason, it can take a maintainer 2 to 3 hours to review and can result in dozens of comments.
12
-
11
+
For this reason, it can take a maintainer two to three hours to review and can result in dozens of comments.
13
12
To help you, there'll be one primary reviewer commenting on your pull request.
14
13
15
14
Don't be discouraged by the number of review comments; it is perfectly normal for an exercise to go through several rewrites before arriving at something both you and the primary reviewer are happy with.
16
15
16
+
## Recommendations
17
+
17
18
Here are some recommendations to help streamline the process even more.
18
19
19
-
### Recommendation: read the documentation
20
+
### Read the documentation
20
21
21
22
Before creating a pull request for an exercise, be sure to read the [concept exercise documentation][concept-exercises] respectively [practice exercise documentation][practice-exercises].
22
23
Reading the documentation beforehand helps immensely, as reviews will have less comments and your pull request will be merged much sooner.
If the track has any existing exercises, take the time to study them a bit to discover what they look like and how they're structured.
27
28
28
29
## Practice Exercise Pull Requests
29
30
30
-
### Recommendation: consider whether the change actually belongs in problems-specifications
31
+
### Consider whether the change actually belongs in problems-specifications
31
32
32
33
Some of the contents of a Practice Exercise (such as its introduction) comes from its (shared) metadata as defined in the [problems-specifications repo][problem-specifications].
33
34
If you're intending to update such content, consider whether the change might benefit other tracks too.
34
35
If so, please open a pull request to the exercise's metadata in the [problems-specifications repo][problem-specifications] instead.
35
36
36
37
## General recommendations
37
38
38
-
### Recommendation: refrain from doing unsolicited reviews
39
+
### Refrain from doing unsolicited reviews
39
40
40
41
All pull request reviews are done by one (or more) maintainers of the track, as they are responsible for signing off all changes to the repository.
41
42
Maintainers doing the review also helps to avoid conflicting feedback for the pull request author.
Copy file name to clipboardexpand all lines: building/github/gha-best-practices.md
+15-9
Original file line number
Diff line number
Diff line change
@@ -3,15 +3,21 @@
3
3
This _working_ document serves as a collection of best practices for making use of GitHub Actions.
4
4
If you have any suggestions or additions, [please open a pull request on GitHub!](https://github.com/exercism/docs/edit/main/building/github/gha-best-practices.md)
5
5
6
-
-[Collection of Best Practices](#collection-of-best-practices)
7
-
-[Set timeouts for workflows](#set-timeouts-for-workflows)
8
-
-[Consider if (third-party) actions are really needed](#consider-if-third-party-actions-are-really-needed)
9
-
-[Limit scope of workflow token](#limit-scope-of-workflow-token)
10
-
-[Pin actions to SHAs](#pin-actions-to-shas)
11
-
-[Consider setting up a concurrency strategy](#consider-setting-up-a-concurrency-strategy)
12
-
-[Consider which triggers are really needed](#consider-which-triggers-are-really-needed)
13
-
-[Read the "Security hardening for GitHub Actions" guide](#read-the-security-hardening-for-github-actions-guide)
14
-
-[Workflow Checklist](#workflow-checklist)
6
+
-[GitHub Actions: Best Practices](#github-actions-best-practices)
7
+
-[Collection of Best Practices](#collection-of-best-practices)
8
+
-[Set timeouts for workflows](#set-timeouts-for-workflows)
9
+
-[Example](#example)
10
+
-[Consider if (third-party) actions are really needed](#consider-if-third-party-actions-are-really-needed)
11
+
-[Limit scope of workflow token](#limit-scope-of-workflow-token)
12
+
-[Example](#example-1)
13
+
-[Pin actions to SHAs](#pin-actions-to-shas)
14
+
-[Finding the commit SHA](#finding-the-commit-sha)
15
+
-[Example](#example-2)
16
+
-[Consider setting up a concurrency strategy](#consider-setting-up-a-concurrency-strategy)
17
+
-[Example](#example-3)
18
+
-[Consider which triggers are really needed](#consider-which-triggers-are-really-needed)
19
+
-[Read the "Security hardening for GitHub Actions" guide](#read-the-security-hardening-for-github-actions-guide)
Copy file name to clipboardexpand all lines: building/github/maintainers-pull-request-guide.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ This document contains some Exercism-specific pull request review guidelines.
6
6
## Reviewing Exercise Pull Requests
7
7
8
8
Reviewing a pull request for a Concept Exercise or Practice Exercise can be daunting with the many rules around these types of exercise.
9
-
For this reason, a first-pass review by a maintainer often take 2 to 3 hours and results in dozens of comments.
9
+
For this reason, a first-pass review by a maintainer often takes two to three hours and results in dozens of comments.
10
10
For Concept Exercises, there are also files with similar goals/contents (e.g. the exercise and concept introduction), where focusing on getting one of those perfect first is essential before branching out too far.
11
11
12
12
To help streamline this workflow, we've developed the following recommendations.
0 commit comments