From 8be8a2d8f5dd3dc12196b612dd04304c66720455 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lars=20M=C3=BCller?= <34514239+appgurueu@users.noreply.github.com> Date: Sun, 23 Oct 2022 21:01:29 +0200 Subject: [PATCH 1/5] Add contributing guidelines --- CONTRIBUTING.md | 60 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 00000000..d0807fa1 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,60 @@ +# Contributing Guidelines + +## Legal + +Contributions must be all your own work; plagiarism is not allowed. +By submitting a pull request, you agree to license your contribution +under the [license of this repository](https://github.com/TheAlgorithms/Algorithms-Explanation/blob/master/LICENSE.md). + +## Translations + +Translations go in the appropriate folder named by the locale code. + +Do not change the structure or formatting of the original (English) explanation when translating or updating translations. +You may change number formatting to fit the locale +(`42.33` may be formatted as `42,33` in a german translation for instance) +as long as it doesn't create ambiguities +(e.g. `[42,33, 13]` in an array would be disallowed and should either remain `[42.33, 13]` or use a different delimiter `[42,33; 13]`). + +## Writing Explanations + +### Structure + +You should structure your explanations using headings. +The top-level heading should be the name of the algorithm or data structure to be explained + +Subsequent sub-headings may be: + +1. Problem solved by the algorithm +2. Design/approach of the algorithm +3. Detailed (yet not too technical) description of the algorithm +4. Analysis (best/worst/average cases, time & space complexity) +5. Walkthrough of how the algorithm processes example inputs +6. Further resources such as reference implementations, videos or other explanations + +### Capitalization + +* Use *Title Case* for headings. +* Start new sentences with a capital letter. + +### Typographical Conventions + +* Leave a space after punctuation such as `.`, `!`, `?`, `,`, `;` or `:`. +* Add a space before and after `-`. **Do not add a space before punctuation.** +* Add a space before an opening parenthesis `(`. Do not add a space before the closing parenthesis `)`. +* Add spaces around (but not inside) quotes. Use single quotes for quotes within quotes. + +### Markdown Conventions + +[GitHub-flavored Markdown is used](https://github.github.com/gfm/). Explanations should render well when viewed from GitHub. + +* **Do not add redundant formatting.** Formatting should always be meaningful. + If you apply a certain formatting to all elements of a certain kind (e.g. adding emphasis around all headings), you're doing something wrong. +* Use ATX-style "hashtag" headings: `#`, `##`, `###`, `####`, `#####`, `######` rather than Setext-style "underline" headings. + Leave blank lines around headings. +* Indent lists by two blanks. Prefer `*` over `-` for bulleted lists. Enumerate numbered lists correctly, starting at `1`. +* Use fenced code blocks (and specify the correct language) rather than using indented code blocks. + Format code inside fenced code blocks properly (prefer pseudocode over code though). Leave blank lines around fenced code blocks. +* Use named links `[name](link)` rather than relying on automatic link detection or using `<>`-links. + There are rarely good reasons to not give a link a descriptive name. +* Use HTML only if necessary (rarely - if ever - the case). Do not use HTML for unnecessary formatting. From a83da139fa96c3f1077d7b7ed7351e6f5d9c6a72 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lars=20M=C3=BCller?= <34514239+appgurueu@users.noreply.github.com> Date: Wed, 14 Dec 2022 20:14:19 +0100 Subject: [PATCH 2/5] Recommend dashes instead of asterisks for lists --- CONTRIBUTING.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index d0807fa1..ed484b0c 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -34,27 +34,27 @@ Subsequent sub-headings may be: ### Capitalization -* Use *Title Case* for headings. -* Start new sentences with a capital letter. +- Use *Title Case* for headings. +- Start new sentences with a capital letter. ### Typographical Conventions -* Leave a space after punctuation such as `.`, `!`, `?`, `,`, `;` or `:`. -* Add a space before and after `-`. **Do not add a space before punctuation.** -* Add a space before an opening parenthesis `(`. Do not add a space before the closing parenthesis `)`. -* Add spaces around (but not inside) quotes. Use single quotes for quotes within quotes. +- Leave a space after punctuation such as `.`, `!`, `?`, `,`, `;` or `:`. +- Add a space before and after `-`. **Do not add a space before punctuation.** +- Add a space before an opening parenthesis `(`. Do not add a space before the closing parenthesis `)`. +- Add spaces around (but not inside) quotes. Use single quotes for quotes within quotes. ### Markdown Conventions [GitHub-flavored Markdown is used](https://github.github.com/gfm/). Explanations should render well when viewed from GitHub. -* **Do not add redundant formatting.** Formatting should always be meaningful. +- **Do not add redundant formatting.** Formatting should always be meaningful. If you apply a certain formatting to all elements of a certain kind (e.g. adding emphasis around all headings), you're doing something wrong. -* Use ATX-style "hashtag" headings: `#`, `##`, `###`, `####`, `#####`, `######` rather than Setext-style "underline" headings. +- Use ATX-style "hashtag" headings: `#`, `##`, `###`, `####`, `#####`, `######` rather than Setext-style "underline" headings. Leave blank lines around headings. -* Indent lists by two blanks. Prefer `*` over `-` for bulleted lists. Enumerate numbered lists correctly, starting at `1`. -* Use fenced code blocks (and specify the correct language) rather than using indented code blocks. +- Indent lists by two blanks. Prefer `-` over `*` for bulleted lists. Enumerate numbered lists correctly, starting at `1`. +- Use fenced code blocks (and specify the correct language) rather than using indented code blocks. Format code inside fenced code blocks properly (prefer pseudocode over code though). Leave blank lines around fenced code blocks. -* Use named links `[name](link)` rather than relying on automatic link detection or using `<>`-links. +- Use named links `[name](link)` rather than relying on automatic link detection or using `<>`-links. There are rarely good reasons to not give a link a descriptive name. -* Use HTML only if necessary (rarely - if ever - the case). Do not use HTML for unnecessary formatting. +- Use HTML only if necessary (rarely - if ever - the case). Do not use HTML for unnecessary formatting. From f46751eb534954969bdcf0090f7bbfc876d4ad0f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lars=20M=C3=BCller?= <34514239+appgurueu@users.noreply.github.com> Date: Wed, 14 Dec 2022 20:16:18 +0100 Subject: [PATCH 3/5] Elaborate on heading hierarchy --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ed484b0c..bcfc44d8 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -51,7 +51,7 @@ Subsequent sub-headings may be: - **Do not add redundant formatting.** Formatting should always be meaningful. If you apply a certain formatting to all elements of a certain kind (e.g. adding emphasis around all headings), you're doing something wrong. - Use ATX-style "hashtag" headings: `#`, `##`, `###`, `####`, `#####`, `######` rather than Setext-style "underline" headings. - Leave blank lines around headings. + Leave blank lines around headings. The first heading should always be `# Title`. Subheadings must be exactly one level deeper than their parents. - Indent lists by two blanks. Prefer `-` over `*` for bulleted lists. Enumerate numbered lists correctly, starting at `1`. - Use fenced code blocks (and specify the correct language) rather than using indented code blocks. Format code inside fenced code blocks properly (prefer pseudocode over code though). Leave blank lines around fenced code blocks. From d5e4ef961f28c12aad186f3e78f42633c5a09212 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lars=20M=C3=BCller?= <34514239+appgurueu@users.noreply.github.com> Date: Sun, 15 Jan 2023 18:23:26 +0100 Subject: [PATCH 4/5] Elaborate on structure --- CONTRIBUTING.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index bcfc44d8..64fc2132 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -23,14 +23,15 @@ as long as it doesn't create ambiguities You should structure your explanations using headings. The top-level heading should be the name of the algorithm or data structure to be explained -Subsequent sub-headings may be: +Subsequent sub-headings *may* be: 1. Problem solved by the algorithm 2. Design/approach of the algorithm -3. Detailed (yet not too technical) description of the algorithm -4. Analysis (best/worst/average cases, time & space complexity) -5. Walkthrough of how the algorithm processes example inputs -6. Further resources such as reference implementations, videos or other explanations +3. Detailed (yet not too technical) description of the algorithm, usually including (pseudo)-code +4. Analysis (proof of correctness, best/worst/average cases, time & space complexity) +5. Walkthrough(s) of how the algorithm processes example input(s) +6. Application(s) of the algorithm +7. Further resources such as reference implementations, videos or other explanations ### Capitalization From 40e702b2949dd0b679339855709358ed16517cd9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lars=20M=C3=BCller?= <34514239+appgurueu@users.noreply.github.com> Date: Tue, 7 Mar 2023 15:22:38 +0100 Subject: [PATCH 5/5] Link to Euclidean Algo as example for good explanation --- CONTRIBUTING.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 64fc2132..91f50958 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -18,6 +18,9 @@ as long as it doesn't create ambiguities ## Writing Explanations +See the [explanation of the Euclidean Algorithm](en/Basic%20Math/Euclidean%20algorithm.md) +for an example of how a good explanation may look like. + ### Structure You should structure your explanations using headings.