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
@@ -173,7 +173,7 @@ For feature enhancement proposals to be accepted they must be approved by at lea
173
173
174
174
This template should be used if you wish to propose a new feature to be added to p5.js. For example to add support for drawing native HTML `<table>` elements with a new `createTable` function. Some proposals may overlap with existing feature enhancement proposals, in these cases you should just choose whichever template you feel is most appropriate.
175
175
176
-
Accordingly, the template form fields are nearly identical to the field of the "Existing Feature Enhancement." As such please see the [previous section](#existing-feature-enchancement) for details about how to fill in each field.
176
+
Accordingly, the template form fields are nearly identical to the field of the "Existing Feature Enhancement." As such please see the [previous section](#existing-feature-enhancement) for details about how to fill in each field.
177
177
178
178
For new feature request proposals to be accepted, they must be approved by at least 2 [area stewards or maintainers](https://github.com/processing/p5.js#stewards) before work can begin on a pull request.
179
179
@@ -213,7 +213,7 @@ Similarly, you should work at your own pace and be confident that there is no ha
213
213
214
214
## Quick Get Started For Developers
215
215
216
-
If you want to work/contribute to p5.js'🌸 codebase as a developer, either directly for improving p5.js or for improving its sub-projects like [Friendly Error Systems](https://github.com/processing/p5.js/blob/main/contributor_docs/friendly_error_system.md), you can follow the following steps:
216
+
If you want to work/contribute to p5.js'🌸 codebase as a developer, either directly for improving p5.js or for improving its sub-projects like [Friendly Error Systems](./friendly_error_system.md), you can follow the following steps:
217
217
218
218
1.[Create a fork of p5.js.](https://docs.github.com/en/get-started/quickstart/fork-a-repo)
219
219
2.[Clone your created fork to your computer.](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository)
@@ -406,7 +406,7 @@ If you are going to work on unit tests, please see [here](./unit_testing.md). No
406
406
407
407
### Inline documentation
408
408
409
-
If you are going to work on the inline documentation, as known as p5.js reference, please see [here](./contributing_to_the_p5.js_reference.md).
409
+
If you are going to work on the inline documentation, as known as p5.js reference, please see [here](./contributing_to_the_p5js_reference.md).
Copy file name to clipboardExpand all lines: contributor_docs/documentation_style_guide.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -49,7 +49,7 @@ We use YUIDoc to generate the p5.js API documentation. To generate the docs, nav
49
49
$ npm run grunt yui:dev
50
50
```
51
51
52
-
The output will appear in docs/reference. Refer to the [inline documentation guide](https://github.com/processing/p5.js/blob/main/contributor_docs/contributing_to_the_p5.js_reference.md) for more information.
52
+
The output will appear in docs/reference. Refer to the [inline documentation guide](./contributing_to_the_p5js_reference.md) for more information.
Copy file name to clipboardExpand all lines: contributor_docs/how-to-add-friendly-error-messages.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -28,7 +28,7 @@ Before we begin, identify which one of the following cases describes your case b
28
28
29
29
### Step 1 – Double-check your inline documentation
30
30
31
-
First, ensure your method has [inline documentation](https://github.com/processing/p5.js/blob/main/contributor_docs/contributing_to_the_p5.js_reference.md) with the full list of your parameters.
31
+
First, ensure your method has [inline documentation](./contributing_to_the_p5js_reference.md) with the full list of your parameters.
32
32
33
33
For example, the `circle()` method has the following inline documentation that starts with a description of the method, followed by a parameter list, and then code for an example:
34
34
@@ -283,7 +283,7 @@ The above parameter validation message will be shown in Korean if the browser is
283
283
Please consider adding unit tests for your new FE messages to detect bugs early and to ensure your code is delivering intended messages to our users. Also, unit tests are a good way to make sure other contributor’s new code does not accidentally break or interfere with the functionality of your code. Here are a few good guides on unit testing:
284
284
285
285
-[Unit Testing and Test Driven Development](https://docs.google.com/document/d/1iw60L1abRJZDn1zUViO9A0j6Fco4yFoQ9LXIlEEroN8/edit?usp=sharing) by Andy Timmons
286
-
-[Contributors Doc: Unit Testing](https://github.com/processing/p5.js/blob/main/contributor_docs/unit_testing.md)
286
+
-[Contributors Doc: Unit Testing](./unit_testing.md)
287
287
288
288
289
289
@@ -313,4 +313,4 @@ Additionally, we are excited to share insights from our community through the FE
- [21-22 FES Survey Full Report](https://observablehq.com/@almchung/p5-fes-21-survey)
315
315
316
-
For more in-depth information about the design and technical aspects of FES, please refer to the [FES README document](https://github.com/processing/p5.js/blob/main/contributor_docs/friendly_error_system.md). This document provides detailed explanations and development notes, which are beneficial for those seeking a deeper understanding of FES.
316
+
For more in-depth information about the design and technical aspects of FES, please refer to the [FES README document](./friendly_error_system.md). This document provides detailed explanations and development notes, which are beneficial for those seeking a deeper understanding of FES.
@@ -89,7 +89,7 @@ Feature request issues should use the "New Feature Request" issue template. The
89
89
90
90
Feature enhancement issues should use the "Existing Feature Enhancement" issue template. The process is very similar to new feature requests. The difference between a new feature request and feature enhancement can be blurry sometimes. Feature enhancement mainly deals with existing functions of p5.js while a new feature request could be requesting entirely new functions to be added.
91
91
92
-
1. Similar to new feature requests, feature enhancement should only be accepted if they increase access to p5.js. Please see point 1 of [section above](steward_guidelines.md#feature-request).
92
+
1. Similar to new feature requests, feature enhancement should only be accepted if they increase access to p5.js. Please see point 1 of [section above](#feature-request).
93
93
2. Inclusion criteria for feature enhancements are similar to those for feature requests, but particular attention should be paid to potential breaking changes.
94
94
- If modifying existing functions, all previous valid and documented function signatures must behave in the same way.
95
95
3. Feature enhancements must be approved by at least one steward or maintainer before work should begin toward a PR. The PR review process for feature enhancement is documented below.
@@ -111,7 +111,7 @@ This type of issue has a minimal template ("Discussion") and should be used to g
111
111
Almost all code contributions to the p5.js repositories happen through pull requests. Stewards and maintainers may have push access to the repositories but are still encouraged to follow the same issue > PR > review process when contributing code. Here are the steps to review a PR:
112
112
113
113
- Pull request template can be found [here](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md).
114
-
- Almost all pull requests must have associated issues opened and discussed first, meaning the relevant [issue workflow](steward_guidelines.md#issues) must have been followed first before a PR should be reviewed by any steward or maintainer.
114
+
- Almost all pull requests must have associated issues opened and discussed first, meaning the relevant [issue workflow](#issues) must have been followed first before a PR should be reviewed by any steward or maintainer.
115
115
- The only instances where this does not apply are very minor typo fixes, which do not require an open issue and can be merged by anyone with merge access to the repo, even if they are not stewards of a particular area.
116
116
- While this exception exists, we will apply it in practice only while contributors are still encouraged to open new issues first. In other words, if in doubt about whether this exception applies, just open an issue anyway.
117
117
- If a pull request does not fully solve the referenced issue, you can edit the original post and change "Resolves #OOOO" to "Addresses #OOOO" so that it does not automatically close the original issue when the PR is merged.
@@ -130,7 +130,7 @@ Simple fixes, such as a small typo fix, can be merged directly by anyone with me
130
130
131
131
1. Bug fixes should be reviewed by the relevant area steward, ideally the same one that approved the referenced issue for fixing.
132
132
2. The PR "Files Changed" tab can be used to initially review whether the fix is implemented as described in the issue discussion.
133
-
3. The PR should be tested locally whenever possible and relevant. The GitHub CLI can help streamline some of the process. (See more below in [Tips & Tricks](steward_guidelines.md#tips-tricks)).
133
+
3. The PR should be tested locally whenever possible and relevant. The GitHub CLI can help streamline some of the process. (See more below in [Tips & Tricks](#tips-tricks)).
134
134
-[ ] The fix should address the original issue sufficiently.
135
135
-[ ] The fix should not change any existing behaviors unless agreed upon in the original issue.
136
136
-[ ] The fix should not have a significant performance impact on p5.js.
@@ -336,14 +336,14 @@ Below are some of the Saved Replies that are being used by p5.js maintainers. Yo
336
336
337
337
##### Closing: Access
338
338
339
-
> I'm not seeing a lot of interest in this feature, and we don't have a clear explanation of how it [expands access](access.md), so I will close this for now. If an access statement can be added to the issue request, please feel welcome to reopen.
339
+
> I'm not seeing a lot of interest in this feature, and we don't have a clear explanation of how it [expands access](./access.md), so I will close this for now. If an access statement can be added to the issue request, please feel welcome to reopen.
340
340
341
-
> We do not see a further explanation of how this issue [expands access](access.md), so I will close this issue for now. If a more detailed access statement can be added to the feature request, please feel welcome to reopen it. Thank you!
341
+
> We do not see a further explanation of how this issue [expands access](./access.md), so I will close this issue for now. If a more detailed access statement can be added to the feature request, please feel welcome to reopen it. Thank you!
342
342
343
343
344
344
##### Closing: Addon
345
345
346
-
> I think this function is beyond the scope of the p5.js API (we try to keep it as minimal as possible), but it could be a great starting point for an addon library. See the docs here for how to create an addon: [https://github.com/processing/p5.js/blob/main/contributor\_docs/creating\_libraries.md](creating_libraries.md)
346
+
> I think this function is beyond the scope of the p5.js API (we try to keep it as minimal as possible), but it could be a great starting point for an addon library. See the docs here for how to create an addon: [Creating an Addon Library](./creating_libraries.md)
0 commit comments