From db871441734c160c36984a025eb534be7a3404ed Mon Sep 17 00:00:00 2001 From: Orwiss <7181108+Orwiss@users.noreply.github.com> Date: Thu, 14 Mar 2024 16:28:30 +0900 Subject: [PATCH 01/12] Create steward_guidelines.md --- contributor_docs/ko/steward_guidelines.md | 1 + 1 file changed, 1 insertion(+) create mode 100644 contributor_docs/ko/steward_guidelines.md diff --git a/contributor_docs/ko/steward_guidelines.md b/contributor_docs/ko/steward_guidelines.md new file mode 100644 index 0000000000..8b13789179 --- /dev/null +++ b/contributor_docs/ko/steward_guidelines.md @@ -0,0 +1 @@ + From bfe570c8516f8fbcaf7fe32bd100372e3bfad84a Mon Sep 17 00:00:00 2001 From: Orwiss <7181108+Orwiss@users.noreply.github.com> Date: Thu, 14 Mar 2024 16:54:45 +0900 Subject: [PATCH 02/12] Update steward_guidelines.md --- contributor_docs/ko/steward_guidelines.md | 380 ++++++++++++++++++++++ 1 file changed, 380 insertions(+) diff --git a/contributor_docs/ko/steward_guidelines.md b/contributor_docs/ko/steward_guidelines.md index 8b13789179..87d1f89631 100644 --- a/contributor_docs/ko/steward_guidelines.md +++ b/contributor_docs/ko/steward_guidelines.md @@ -1 +1,381 @@ +# Steward Guidelines +Whether you have just joined us as a steward, are a seasoned maintainer of p5.js, or are somewhere in between, this guide contains information as well as tips and tricks that will help you effectively contribute to p5.js. Most of what is written here are guidelines unless otherwise stated, which means you can adapt the practices shown here to suit your workflow. + + +## Table of Contents + +- [Issues](steward_guidelines.md#issues) + - [Bug report](steward_guidelines.md#bug-report) + - [Feature request](steward_guidelines.md#feature-request) + - [Feature enhancement](steward_guidelines.md#feature-enhancement) + - [Discussion](steward_guidelines.md#discussion) +- [Pull Requests](steward_guidelines.md#pull-requests) + - [Simple fix](steward_guidelines.md#simple-fix) + - [Bug fix](steward_guidelines.md#bug-fix) + - [New feature/feature enhancement](steward_guidelines.md#new-feature-feature-enhancement) + - [Dependabot](steward_guidelines.md#dependabot) +- [Build Process](steward_guidelines.md#build-process) + - [Main build task](steward_guidelines.md#main-build-task) + - [Miscellaneous tasks](steward_guidelines.md#miscellaneous-tasks) +- [Release Process](steward_guidelines.md#release-process) +- [Tips & Tricks](steward_guidelines.md#tips--tricks) + - [Reply templates](steward_guidelines.md#reply-templates) + - [GitHub CLI](steward_guidelines.md#github-cli) + - [Managing notifications](steward_guidelines.md#managing-notifications) + +--- + + +## Issues + +We encourage most source code contributions to start with an issue, and as such, issues are the place where most of the discussions will take place. The steps to take when reviewing an issue will depend on what kind of issue it is. The repo uses [GitHub issue templates](https://github.com/processing/p5.js/blob/main/.github/ISSUE_TEMPLATE) in order to better organize different kinds of issues and encourage issue authors to provide all relevant information about their problems. The first step in reviewing the issue will often be looking through the filled-out template and determining if you need additional information (e.g., because some fields weren't filled in or the incorrect template was used). + + +### Bug report + +Bug report issues should use the "Found a bug" issue template. The following workflow is typical for addressing bug reports: + +1. Replicate the bug + - The goal of the template is to provide enough information for a reviewer to attempt to replicate the bug in question. + - If the reported bug is not relevant to the repo it is opened in (p5.js, p5.js-website, or otherwise): + - Transfer the issue to the relevant repo if you have access to it. + - Otherwise, leave a comment about where the bug report should be filed (with a direct link provided) and close the issue. + - The first step in reviewing a bug report is to see if enough information is provided for a bug replication, and if so, attempt to replicate the bug as described. +2. If the bug can be replicated: + - Some discussion may be required to determine the best way to fix a particular bug. Sometimes, it may be straightforward; sometimes, it may be tricky. Please refer to [p5.js' design principles](design_principles.md) when making this decision on a case-by-case basis. + - If the issue author indicated in the issue they are willing to contribute a fix: + - Approve the issue for fixing by the issue author by leaving a comment and assigning them to the issue. Use the cog button on the right side next to "Assignee". + - If the issue author does not wish to contribute a fix: + - Leave a comment recognizing the bug is replicable. + - Attempt to fix yourself or add the `help wanted` label to signal an issue needing a fix. +3. If the bug cannot be replicated: + - Ask for additional info if not already provided in the template (p5.js version, browser version, OS version, etc.). + - If your testing environment differs from what is reported in the issue (e.g., a different browser or OS): + - Leave a comment saying you are not able to replicate in your specific environment. + - Add a `help wanted` label to the issue and ask for someone else with the setup specified in the issue to try to replicate the bug. + - Sometimes, bugs only occur when using the web editor and not when testing locally. In this case, the issue should be redirected to the [web editor repo](https://github.com/processing/p5.js-web-editor). + - If replication is possible later, go back to step 2. +4. If the bug stems from the code the user provided in the bug report and not p5.js' behavior: + - Determine if p5.js' documentation, code implementation, or friendly error system can be improved to prevent the same mistake from being made. + - Kindly redirect any further questions to the [forum](https://discourse.processing.org/) or [Discord](https://discord.com/invite/SHQ8dH25r9) and close the issue if no further changes are to be made to p5.js. + + +### Feature request + +Feature request issues should use the "New Feature Request" issue template. The following workflow is typical for addressing feature requests: + +1. As part of p5.js' commitment to increase access, a feature request must make a case for how it increases access of p5.js to communities that are historically marginalized in the field. More details are available [here](access.md). + - If a feature request does not have the "Increasing Access" field sufficiently filled out, you can ask the issue author how the feature increases access. + - The access statement of a feature can be provided by a different member of the community, including the issue reviewers. +2. The new feature request can be assessed for inclusion based on the following criteria. + - Does the feature fit into the project scope and [design principles](design_principles.md) of p5.js? + - For example, a request to add a new drawing primitive shape may be considered, but a request to adopt a browser-based IOT protocol will likely be out of scope. + - Overall, the scope of p5.js should be relatively narrow in order to avoid excessive bloat from rarely used features. + - If a feature does not fit into the scope of p5.js, suggest that the issue author implement the feature as as an addon library. + - If it is unclear whether or not it fits, it can be a good idea to suggest making an addon library as a proof-of-concept. This helps give users a way to use the feature, provides a much more concrete example of its usage and importance, and does not necessarily need to be as complete of a solution as a fully integrated feature. It can be integrated into the core of p5.js later if appropriate. + - Is the feature likely to cause a breaking change? + - Will it conflict with existing p5.js functions and variables? + - Will it conflict with typical sketches already written for p5.js? + - Features that are likely to cause conflicts such as  the ones above  are  considered breaking changes. Without a [major version release](https://docs.npmjs.com/about-semantic-versioning), we should not make breaking changes to p5.js. + - Can the proposed new feature be achieved using existing functionalities already in p5.js, relatively simple native JavaScript code, or existing easy-to-use libraries? + - For example, instead of providing a p5.js function to join an array of strings such as `join(["Hello", "world!"])`, the native JavaScript `["Hello", "world!"].join()` should be preferred instead. +3. If the access requirement and other considerations have been fulfilled, at least two stewards or maintainers must approve the new feature request before work should begin toward a PR. The PR review process for new features is documented below. + + +### Feature enhancement + +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. + +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). +2. Inclusion criteria for feature enhancements are similar to those for feature requests, but particular attention should be paid to potential breaking changes. + - If modifying existing functions, all previous valid and documented function signatures must behave in the same way. +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. + + +### Discussion + +This type of issue has a minimal template ("Discussion") and should be used to gather feedback around a topic in general before coalescing it into something more specific, like a feature request. These sorts of discussion issues can be closed when the conversation finishes and the resulting more specific issues have been created:  + +- If an issue is opened as a discussion but should be, for example, a bug report, the correct label should be applied and the "discussion" label removed. Additional info about the bug should also be requested from the author if not already included. +- If an issue is opened as a discussion but isn't relevant to source code contribution or otherwise relevant to the GitHub repositories/contribution process/contribution community, they should be redirected to the forum or Discord and the issue closed. +- If relevant, additional labels should be added to discussion issues to further signal what type of discussion it is at a glance. + +--- + + +## Pull Requests + +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: + +- Pull request template can be found [here](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md). +- 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. + - 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. + - 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. +- 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. + + +### Simple fix + +Simple fixes, such as a small typo fix, can be merged directly by anyone with merge access.  Check on the PR "Files Changed" tab to ensure  that the automated CI test passes. + +![The "files changed" tab when viewing a pull request on GitHub](images/files-changed.png) + +![The "All checks have passed" indicator on a GitHub pull request, highlighted above the merge button](images/all-checks-passed.png) + + +### Bug fix + +1. Bug fixes should be reviewed by the relevant area steward, ideally the same one that approved the referenced issue for fixing. +2. The PR "Files Changed" tab can be used to initially review whether the fix is implemented as described in the issue discussion. +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)). + - [ ] The fix should address the original issue sufficiently. + - [ ] The fix should not change any existing behaviors unless agreed upon in the original issue. + - [ ] The fix should not have a significant performance impact on p5.js. + - [ ] The fix should not have any impact on p5.js' accessibility. + - [ ] The fix should use the modern standard of JavaScript coding. + - [ ] The fix should pass all automated tests and include new tests if relevant. +4. If any additional changes are required, line comments should be added to the relevant lines as described [here](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request#adding-line-comments-to-a-pull-request). + - A suggestion block can also be used to suggest specific changes:\ + ![The Suggest Change button while writing a comment on code in a GitHub pull request](images/suggest-change.png)\ + ![A suggested change appearing within code fences with the "suggestion" tag](images/suggested-value-change.png)\ + ![A suggested change previewed as a diff](images/suggestion-preview.png) + - If multiple changes are required, don’t add single-line comments many times. Instead, follow the procedure documented [here](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request) to make multiple-line comments and a single request for changes. + - If line comments are just for clarification or discussion, choose “Comment” instead of "Request changes":\ + ![The "comment" option circled within the GitHub Finish Review menu](images/comment-review.png) +5. Once the PR has been reviewed and no additional changes are required, a steward can mark the PR as "Approved" by choosing the "Approve" option in the previous step, with or without additional comments. The steward can then either request additional review by another steward or maintainer if desired, merge the PR if they have merge access, or request a merge from a maintainer. + +6. @[all-contributors](https://allcontributors.org/docs/en/emoji-key) bot should be called to add any new contributors to the list of contributors in the README.md file. Each type of contribution can be indicated in place of `[contribution` `type]` below, the full list of available types of contributions can be found in the link above. + +`@all-contributors` `please` `add` `@[GitHub` `handle]` `for` `[contribution` `type]` + + +### New feature/feature enhancement + +The process for new feature or feature enhancement PR is similar to bug fixes with just one notable difference: + +- A new feature/feature enhancement PR must be reviewed and approved by at least two stewards or maintainers before it can be merged. + + +### Dependabot + +Dependabot PRs are usually only visible to repo admins so if this does not apply to you, please skip this section. + +- Dependabot PRs can be merged directly if the version update is a [semver](https://semver.org/) patch version and the automated CI test has passed. +- Dependabot PRs with semver minor version changes can usually be merged directly as long as automated CI test passes. A quick check on the changelog of the updated dependency is recommended. +- Dependabot PRs with semver major version changes may likely affect either the build process or p5.js functionalities. The reviewer, in this case, is encouraged to review the changelog from the current version to the target version if possible and test the PR locally to ensure all processes are functioning and make any required changes due to potential breaking changes in the dependencies. + - Many dependencies bump major version numbers only because they drop official support for very old versions of Node.js. In many cases, major version changes don't necessarily mean breaking changes resulting from dependency API changes. + +--- + + +## Build process + +This section will not cover the general build setup nor commands but rather details about what's happening behind the scenes. Please see the [contributor’s guidelines](contributor_guidelines.md#working-on-p5js-codebase) for more detailed build info. + +The Gruntfile.js file contains the main build definitions for p5.js. Among the different tools used to build the library and documentation includes but not limited to Grunt, Browserify, YUIDoc, ESLint, Babel, Uglify, and Mocha. It may be helpful for us to start with the `default` task and work backward from there. It may be helpful at this point to open up the Gruntfile.js document while going through the explainer below. + + +### Main build task + +``` +grunt.registerTask('default', ['lint', 'test']); +``` + +When we run `grunt` or the npm script `npm test`, we run the default task consisting of `lint` then `test`. + + +#### `lint` Task + +``` +grunt.registerTask('lint', ['lint:source', 'lint:samples']); +``` + +The `lint` task consists of two sub tasks: `lint:source` and `lint:samples`. `lint:source` is further subdivided into three more sub tasks `eslint:build`, `eslint:source`, and `eslint:test`, which uses ESLint to check the build scripts, the source code, and the test scripts. + +The `lint:samples` task will first run the `yui` task which itself consists of `yuidoc:prod`, `clean:reference`, and `minjson`, which extract the documentation from the source code into a JSON document, remove unused files from the previous step, and minify the generated JSON file into `data.min.json` respectively. + +Next in `lint:samples` is `eslint-samples:source`, which is a custom written task whose definition is in [./tasks/build/eslint-samples.js](tasks/build/eslint-samples.js); it will run ESLint to check the documentation example code to make sure they follow the same coding convention as the rest of p5.js (`yui` is run first here because we need the JSON file to be built first before we can lint the examples). + + +#### `test` Task + +```js +grunt.registerTask('test', [ +  'build', +  'connect:server', +  'mochaChrome', +  'mochaTest', +  'nyc:report' +]); +``` + +First let's look at the `build` task under `test`. + +```js +grunt.registerTask('build', [ +  'browserify', +  'browserify:min', +  'uglify', +  'browserify:test' +]); +``` + +Tasks that start with `browserify` are defined in [./tasks/build/browserify.js](tasks/build/browserify.js). They all  similar steps with minor differences. These are the main steps to build the full p5.js library from its many source code files into one: + +- `browserify` builds p5.js while `browserify:min` builds an intermediate file to be minified in the next step. The difference between `browserify` and `browserify:min` is that `browserify:min` does not contain data needed for FES to function. +- `uglify` takes the output file of `browserify:min` and minify it into the final p5.min.js (configuration of this step is in the main Gruntfile.js). +- `browserify:test` is building a version identical to the full p5.js except for added code that is used for test code coverage reporting (using [Istanbul](https://istanbul.js.org/)). + +First, use of the `fs.readFileSync()` node.js specific code is replaced with the file's actual content using `brfs-babel`. This is used mainly by WebGL code to inline shader code from source code written as separate files. + +Next, the source code, including all dependencies from node\_modules, is transpiled using Babel to match the [Browserslist](https://browsersl.ist/) requirement defined in package.json as well as to make the ES6 import statements into CommonJS `require()` that browserify understands. This also enables us to use newer syntax available in ES6 and beyond without worrying about browser compatibility. + +After bundling but before the bundled code is written to file, the code is passed through `pretty-fast`, if it is not meant to be minified, it should be cleaned up so the final formatting is a bit more consistent (we anticipate the p5.js source code can be read and inspected if desired). + +A few small detailed steps are left out here; you can check out the browserify build definition file linked above to have a closer look at everything. + +``` +connect:server +``` + +This step spins up a local server hosting the test files and built source code files so that automated tests can be run in Chrome. + +``` +mochaChrome +``` + +This step is defined in [./tasks/test/mocha-chrome.js](tasks/test/mocha-chrome.js). It uses Puppeteer to spin up a headless version of Chrome that can be remote controlled and runs the tests associated with the HTML files in the `./test` folder, which includes testing the unminified and minified version of the library against the unit test suites as well as testing all reference examples. + +``` +mochaTest +``` + +This step differs from `mochaChrome` in that it is run in node.js instead of in Chrome and only tests a small subset of features in the library. Most features in p5.js will require a browser environment, so this set of tests should only be expanded if the new tests really don't need a browser environment. + +``` +nyc:report +``` + +Finally, after all builds and tests are complete, this step will gather the test coverage report while `mochaChrome` was testing the full version of the library and print the test coverage data to the console. Test coverage for p5.js is mainly for monitoring and having some additional data points; having 100% test coverage is not a goal. + +And that covers the default task in the Gruntfile.js configuration! + + +### Miscellaneous tasks + +All of the steps can be run directly with `npx grunt [step]`. There are also a few tasks that are not covered above but could be useful in certain cases. + +``` +grunt yui:dev +``` + +This task will run the documentation and library builds described above, followed by spinning up a web server that serves a functionally similar version of the reference page you will find on the website on [http://localhost:9001/docs/reference/](http://localhost:9001/docs/reference/). It will then monitor the source code for changes and rebuild the documentation and library. + +`grunt` `yui:dev` is useful when you are working on the reference in the inline documentation because you don't have to move built files from the p5.js repository to a local p5.js-website repository and rebuild the website each time you make a change, and you can just preview your changes with this slightly simplified version of the reference in your browser. This way, you can also be more confident that the changes you made are likely to show up correctly on the website. Note that this is only meant for modifications to the inline documentation; changes to the reference page itself, including styling and layout, should be made and tested on the website repository. + +``` +grunt watch +grunt watch:main +grunt watch:quick +``` + +The watch tasks will watch a series of files for changes and run associated tasks to build the reference or the library according to what files have changed. These tasks all do the same thing, with the only difference being the scope. + +The `watch` task will run all builds and tests similar to running the full default task on detecting changes in the source code. + +The `watch:main` task will run the library build and tests but not rebuild the reference on detecting changes in the source code. + +The `watch:quick` task will run the library build only on detecting changes in the source code. + +Depending on what you are working on, choosing the most minimal watch task here can save you from having to manually run a rebuild whenever you want to make some changes. + +--- + + +## Release process + +Please see [release\_process.md](release_process.md). + +--- + + +## Tips & tricks + +Sometimes, the number of issues and PR that require review can get a bit overwhelming.  While we try to put in place processes that make things easier, there are some tips and tricks that you can utilize to help with reviewing issues and PRs. + + +### Reply templates + +A handy GitHub feature that you can use is the [Saved Replies](https://docs.github.com/en/get-started/writing-on-github/working-with-saved-replies/about-saved-replies) feature, which is available to use when authoring a reply to issues or pull requests. Some of the workflow described above may require responding to issues or PRs with identical or very similar replies (redirecting questions to the forum, accepting an issue for fixing, etc.), and using Saved Replies can just ever so slightly make this more efficient. + +Below are some of the Saved Replies that are being used by p5.js maintainers. You can use them yourself or create your own! + + +##### Closing: Can’t Reproduce + +> We're not able to reproduce this, but please feel free to reopen if you can provide a code sample that demonstrates the issue. Thanks! + + +##### Closing: Need Snippet + +> I'm closing this for organizational purposes. Please reopen if you can provide a code snippet that illustrates the issue. Thanks! + + +##### Closing: Use the Forum + +> The GitHub issues here are a good place for bugs and issues with the p5.js library itself. For questions about writing your own code, tests, or following tutorials, the [forum](https://discourse.processing.org/) is the best place to post. Thanks! + + +##### Closing: GSOC + +> Thanks! The best place to discuss GSOC proposals is on our [forum](https://discourse.processing.org/c/summer-of-code). + + +##### Closing: Access + +> 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. + +> 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! + + +##### Closing: Addon + +> 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) + + +##### Closing PR: Need Issue First + +> Thank you. As a reminder, issues need to be opened before pull requests are opened and tagged with the issue. This is necessary for tracking development and keeping discussion clear. Thanks! + + +##### Approve issue for fixing + +> You can go ahead with a fix. Thanks. + + +##### Merged PR + +> Looks good. Thanks! + + +### GitHub CLI + +Reviewing a complex PR can be difficult with complex git commands required to get the PR's version of code locally for you to test. Fortunately, the [GitHub CLI](https://cli.github.com/) tool can help greatly with this process and more. + +After installing the CLI and logging in, reviewing a PR locally can be done by running the command `gh pr checkout [pull_request_id]`, and the process of fetching a remote fork, creating a branch, and checking out the branch are all done automatically for you. Going back to the main branch will be the same as switching a branch by running `git checkout main`. You can even leave a comment in the PR from the CLI without needing to visit the webpage at all! + +There are many other commands available in the GitHub CLI as well that you may or may not find useful, but it is a good tool to have around in any case. + + +### Managing notifications + +Instead of manually monitoring the "Issues" or "Pull Requests" tabs of the repo for new issues or PRs, you can "watch" the repo by clicking on the "Watch" button with an eye icon on the top of the repo page opposite the repo name. + +![Cropped screenshot of the top right corner of a GitHub repository page showing a series of buttons in the center from left to right: Sponsor, Watch, Fork, Starred.](images/github-repo-metrics.png) + +By watching a repo, events such as new issues, new pull requests, mentions of your user handle, and other activities you subscribed to on the repo will be sent as notifications to your [notification page](https://github.com/notifications), where they can be marked as read or dismissed much like an email inbox. + +In some cases, you may receive emails from GitHub about events in the repo you are watching as well, and you can customize these (including unsubscribing from them completely) from your [notifications settings page](https://github.com/settings/notifications). + +Setting these up to fit the way you work can be the difference between having to find relevant issues/PRs to review manually and being overwhelmed by endless notifications from GitHub. A good balance is required here. As a starting suggestion, stewards should watch this repo for "Issues" and "Pull Requests" and set it to only receive emails on "Participating, @mentions and custom." From 635891f53363b0a7d3cc715de682018b9a22e474 Mon Sep 17 00:00:00 2001 From: Orwiss <7181108+Orwiss@users.noreply.github.com> Date: Sat, 16 Mar 2024 16:40:31 +0900 Subject: [PATCH 03/12] Rename steward_guidelines.md to [p5.js KO] steward_guidelines.md --- .../{steward_guidelines.md => [p5.js KO] steward_guidelines.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename contributor_docs/ko/{steward_guidelines.md => [p5.js KO] steward_guidelines.md} (100%) diff --git a/contributor_docs/ko/steward_guidelines.md b/contributor_docs/ko/[p5.js KO] steward_guidelines.md similarity index 100% rename from contributor_docs/ko/steward_guidelines.md rename to contributor_docs/ko/[p5.js KO] steward_guidelines.md From f6d17d4037d2f51394d9c37f53f2eaa0f652f040 Mon Sep 17 00:00:00 2001 From: IENGROUND Date: Mon, 18 Mar 2024 18:27:31 +0900 Subject: [PATCH 04/12] Update [p5.js KO] steward_guidelines.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit connect:server 이후 부분 1차 번역 업로드합니다 --- .../ko/[p5.js KO] steward_guidelines.md | 101 +++++++++--------- 1 file changed, 51 insertions(+), 50 deletions(-) diff --git a/contributor_docs/ko/[p5.js KO] steward_guidelines.md b/contributor_docs/ko/[p5.js KO] steward_guidelines.md index 87d1f89631..ef7f302539 100644 --- a/contributor_docs/ko/[p5.js KO] steward_guidelines.md +++ b/contributor_docs/ko/[p5.js KO] steward_guidelines.md @@ -239,40 +239,41 @@ A few small detailed steps are left out here; you can check out the browserify b connect:server ``` -This step spins up a local server hosting the test files and built source code files so that automated tests can be run in Chrome. +이 단계에서는 테스트 파일과 빌드된 소스 코드 파일을 호스팅하는 로컬 서버를 가동하여 Chrome에서 자동화된 테스트를 실행할 수 있도록 합니다. ``` mochaChrome ``` -This step is defined in [./tasks/test/mocha-chrome.js](tasks/test/mocha-chrome.js). It uses Puppeteer to spin up a headless version of Chrome that can be remote controlled and runs the tests associated with the HTML files in the `./test` folder, which includes testing the unminified and minified version of the library against the unit test suites as well as testing all reference examples. +이 단계는 [./tasks/test/mocha-chrome.js](tasks/test/mocha-chrome.js)에 정의되어 있습니다. Puppeteer를 사용해 원격 제어가 가능한 Chrome의 헤드리스 버전을 가동하고, `./test` 폴더에 있는 HTML 파일과 관련된 테스트를 실행합니다. 여기에는 라이브러리의 축소되지 않은 버전과 축소된 버전을 단위 테스트(unit test) 모음에 대해 테스트하는 것은 물론, 모든 참조 예제를 테스트하는 것도 포함되어 있습니다. ``` mochaTest ``` -This step differs from `mochaChrome` in that it is run in node.js instead of in Chrome and only tests a small subset of features in the library. Most features in p5.js will require a browser environment, so this set of tests should only be expanded if the new tests really don't need a browser environment. +이 단계는 Chrome 대신 node.js에서 실행되고 라이브러리의 기능 중 일부만 테스트한다는 점에서 `mochaChrome`과 차이가 있습니다. 대부분의 p5.js 기능은 브라우저 환경이 필요하므로 이 테스트 세트는 새로운 테스트에 브라우저 환경이 필요하지 않을 때만 확장해야 합니다. ``` nyc:report ``` -Finally, after all builds and tests are complete, this step will gather the test coverage report while `mochaChrome` was testing the full version of the library and print the test coverage data to the console. Test coverage for p5.js is mainly for monitoring and having some additional data points; having 100% test coverage is not a goal. +마지막으로, 모든 빌드와 테스트가 완료되면 이 단계에서는 `mochaChrome`이 전체 라이브러리 버전을 테스트하는 동안 테스트 커버리지 보고서를 수집하고, 테스트 범위 데이터를 콘솔에 출력합니다. p5.js의 테스트 커버리지는 주로 추가적인 데이터 포인트를 모니터링하고 확보하는 것으로, 테스트 커버리지 100%를 목표로 하지는 않습니다. -And that covers the default task in the Gruntfile.js configuration! +그리고 그것은 Gruntfile.js 구성의 기본 작업을 다루고 있습니다! -### Miscellaneous tasks +### 기타 작업 -All of the steps can be run directly with `npx grunt [step]`. There are also a few tasks that are not covered above but could be useful in certain cases. +모든 단계는 `npx grunt [step]`으로 직접 실행할 수 있습니다. 위에서 다루지는 않았지만 특정 상황에서 유용할 수 있는 몇 가지 작업도 있습니다. ``` grunt yui:dev ``` -This task will run the documentation and library builds described above, followed by spinning up a web server that serves a functionally similar version of the reference page you will find on the website on [http://localhost:9001/docs/reference/](http://localhost:9001/docs/reference/). It will then monitor the source code for changes and rebuild the documentation and library. +이 작업은 위에 설명된 문서 및 라이브러리 빌드를 실행한 다음, [http://localhost:9001/docs/reference/](http://localhost:9001/docs/reference/)의 웹사이트에서 찾을 수 있는 참조 페이지와 유사한 기능을 가진 버전을 제공하는 웹 서버를 가동합니다. 그런 다음 소스 코드의 변경점을 모니터링하고 문서와 라이브러리를 다시 빌드합니다. + +`grunt` `yui:dev`는 인라인 문서의 참조 작업을 할 때 유용한데, 빌드된 파일을 p5.js 저장소(repository)에서 로컬 p5.js-웹사이트 저장소로 이동할 필요도, 변경사항이 생길 때마다 웹사이트를 다시 빌드할 필요도 없기 때문입니다. 그저 브라우저에서 약간 단순화된 참조 버전으로 변경사항을 미리 보면 됩니다. 이렇게 하면 변경사항이 웹사이트에 더욱 올바르게 표시될 것이라는 확신을 가질 수도 있습니다. 이는 인라인 문서를 수정하는 경우에만 해당된다는 것을 알아두세요. 스타일 및 레이아웃 작업을 포함한 참조 페이지 자체에 대한 변경사항은 웹사이트 저장소에서 생기고 테스트해야 합니다. -`grunt` `yui:dev` is useful when you are working on the reference in the inline documentation because you don't have to move built files from the p5.js repository to a local p5.js-website repository and rebuild the website each time you make a change, and you can just preview your changes with this slightly simplified version of the reference in your browser. This way, you can also be more confident that the changes you made are likely to show up correctly on the website. Note that this is only meant for modifications to the inline documentation; changes to the reference page itself, including styling and layout, should be made and tested on the website repository. ``` grunt watch @@ -280,102 +281,102 @@ grunt watch:main grunt watch:quick ``` -The watch tasks will watch a series of files for changes and run associated tasks to build the reference or the library according to what files have changed. These tasks all do the same thing, with the only difference being the scope. +Watch 작업은 여러 파일의 변경사항을 감시하고, 관련 작업을 실행하여 변경된 파일에 따라 참조나 라이브러리를 빌드합니다. 이러한 작업은 범위의 차이를 제외하면 모두 동일한 작업을 수행합니다. -The `watch` task will run all builds and tests similar to running the full default task on detecting changes in the source code. +`watch` 작업은 소스 코드의 변경사항을 감지할 때 전체 기본 작업을 실행하는 것과 비슷한 모든 빌드와 테스트를 실행합니다. -The `watch:main` task will run the library build and tests but not rebuild the reference on detecting changes in the source code. +`watch:main` 작업은 라이브러리 빌드와 테스트를 실행하지만, 소스 코드의 변경사항을 감지해도 참조를 다시 빌드하지는 않습니다. -The `watch:quick` task will run the library build only on detecting changes in the source code. +`watch:quick` 작업은 소스 코드의 변경사항이 감지된 경우에만 라이브러리 빌드를 실행합니다. -Depending on what you are working on, choosing the most minimal watch task here can save you from having to manually run a rebuild whenever you want to make some changes. +작업 중인 내용에 따라 가장 적은 감시 작업이 일어나는 것을 선택한다면 변경사항을 만들고 싶을 때마다 수동으로 다시 빌드를 하지 않아도 됩니다. --- -## Release process +## 배포 과정 -Please see [release\_process.md](release_process.md). +[release\_process.md](release_process.md)를 확인하세요. --- -## Tips & tricks +## 팁과 요령 -Sometimes, the number of issues and PR that require review can get a bit overwhelming.  While we try to put in place processes that make things easier, there are some tips and tricks that you can utilize to help with reviewing issues and PRs. +때때로 검토가 필요한 이슈와 PR의 수가 너무 많아질 수도 있습니다. 저희가 이를 더 쉽게 만드는 과정을 마련하려는 동안 이슈와 PR을 검토하는 데 도움이 될 만한 몇 가지 팁과 요령을 알려드립니다. -### Reply templates +### 회신(Reply) 양식 -A handy GitHub feature that you can use is the [Saved Replies](https://docs.github.com/en/get-started/writing-on-github/working-with-saved-replies/about-saved-replies) feature, which is available to use when authoring a reply to issues or pull requests. Some of the workflow described above may require responding to issues or PRs with identical or very similar replies (redirecting questions to the forum, accepting an issue for fixing, etc.), and using Saved Replies can just ever so slightly make this more efficient. +사용할 수 있는 편리한 깃허브(GitHub) 기능은 이슈 또는 풀 요청(pull request)에 대한 회신을 작성할 떄 사용할 수 있는 [저장된 회신](https://docs.github.com/en/get-started/writing-on-github/working-with-saved-replies/about-saved-replies) 기능입니다. 위에 설명된 작업 흐름(workflow) 중 일부는 동일하거나 매우 유사한 답변(포럼으로 질문을 리디렉션하거나, 수정을 위한 이슈 수락 등)으로 이슈 또는 PR에 응답해야 할 수도 있는데, **저장된 회신**을 사용하면 이 작업의 효율이 조금 더 올라갈 수 있습니다. -Below are some of the Saved Replies that are being used by p5.js maintainers. You can use them yourself or create your own! +다음은 p5.js 메인테이너가 사용하는 **저장된 회신**의 일부입니다. 이를 사용하거나 직접 만들어 보세요! -##### Closing: Can’t Reproduce +##### 종결: 재현할 수 없음 -> We're not able to reproduce this, but please feel free to reopen if you can provide a code sample that demonstrates the issue. Thanks! +> 이것을 재현할 수는 없지만, 이 이슈를 보여줄 수 있는 샘플 코드를 제공할 수 있다면 다시 열어주세요. 감사합니다! -##### Closing: Need Snippet +##### 종결: 스니펫 필요 -> I'm closing this for organizational purposes. Please reopen if you can provide a code snippet that illustrates the issue. Thanks! +> 조직적인 목적으로 이 이슈를 종결합니다. 이 이슈를 설명하는 코드 스니펫을 제공할 수 있다면 다시 열어주세요. 감사합니다! -##### Closing: Use the Forum +##### 종결: 포럼 사용 -> The GitHub issues here are a good place for bugs and issues with the p5.js library itself. For questions about writing your own code, tests, or following tutorials, the [forum](https://discourse.processing.org/) is the best place to post. Thanks! +> 이 깃허브 이슈는 p5.js 라이브러리 자체의 버그나 이슈를 올리기에 좋은 곳입니다. 여러분의 코드나 테스트, 또는 튜토리얼을 따라하는 것에 대한 질문을 하고 싶다면 [포럼](https://discourse.processing.org/)만한 곳이 없을 거에요. 감사합니다! -##### Closing: GSOC +##### 종결: GSOC -> Thanks! The best place to discuss GSOC proposals is on our [forum](https://discourse.processing.org/c/summer-of-code). +> 감사합니다! GSOC 제안을 논의하고 싶다면 우리의 [포럼](https://discourse.processing.org/c/summer-of-code)만한 곳이 없답니다. -##### Closing: Access +##### 종결: 접근성 -> 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. +> 저는 이 기능에 큰 관심이 없고, 어떻게 [접근성을 확장](access.md)하는지에 대한 명확한 설명이 없으므로 일단 이 이슈를 종결하겠습니다. 이슈 요청에 접근성 설명을 추가할 수 있게 되면 언제든지 다시 열어주세요. -> 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! +> 이 이슈로 인해 어떻게 [접근성이 확장](access.md)되는지에 대한 추가 설명이 없으므로 일단 이 이슈를 종결하겠습니다. 기능 요청에 더 자세한 접근성 설명을 추가할 수 있게 되면 언제든지 다시 열어주세요. 감사합니다! -##### Closing: Addon +##### 종결: 애드온 -> 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) +> 저는 이 기능이 p5.js API의 범위를 벗어나는 것이라고 생각하지만 (최소한의 크기를 유지하고 싶어요), 애드온 라이브러리를 만드는 좋은 시작점이 될 것 같습니다. 애드온을 생성하는 방법을 알고 싶다면 이 문서를 확인해 보세요. [https://github.com/processing/p5.js/blob/main/contributor\_docs/creating\_libraries.md](creating_libraries.md) -##### Closing PR: Need Issue First +##### PR 종결: 이슈가 먼저 필요함 -> Thank you. As a reminder, issues need to be opened before pull requests are opened and tagged with the issue. This is necessary for tracking development and keeping discussion clear. Thanks! +> 감사합니다. 참고로, 풀 요청(pull request)을 게시하고 이슈에 태그를 지정하기 전에 먼저 이슈를 게시해야 합니다. 이는 개발을 추적하고 토론을 명확하게 유지하는 데 필요해요. 감사합니다! -##### Approve issue for fixing +##### 이슈 해결 승인 -> You can go ahead with a fix. Thanks. +> 계속 해결해도 됩니다. 감사합니다! -##### Merged PR +##### PR 병합 -> Looks good. Thanks! +> 괜찮아 보이는데요? 감사합니다! -### GitHub CLI +### 깃허브 CLI -Reviewing a complex PR can be difficult with complex git commands required to get the PR's version of code locally for you to test. Fortunately, the [GitHub CLI](https://cli.github.com/) tool can help greatly with this process and more. +테스트할 PR의 코드 버전을 로컬로 가져오는 데 필요한 복잡한 git 명령어를 사용하면 복잡한 PR을 검토하는 게 어려울 수 있습니다. 다행히도 [깃허브 CLI](https://cli.github.com/)가 이 과정에서 큰 도움을 줄 수 있겠군요. -After installing the CLI and logging in, reviewing a PR locally can be done by running the command `gh pr checkout [pull_request_id]`, and the process of fetching a remote fork, creating a branch, and checking out the branch are all done automatically for you. Going back to the main branch will be the same as switching a branch by running `git checkout main`. You can even leave a comment in the PR from the CLI without needing to visit the webpage at all! +CLI를 설치하고 로그인하고 `gh pr checkout [pull_request_id]` 명령어를 실행하면 로컬에서 PR 검토가 가능하며, 원격 포크 가져오기, 브랜치 생성, 브랜치 체크아웃 과정이 모두 자동으로 수행됩니다. main 브랜치로 돌아가는 것은 `git checkout main`으로 브랜치를 전환하는 것과 같습니다. 심지어 웹사이트를 방문하지 않고도 CLI에서 PR에 댓글을 남길 수도 있습니다! -There are many other commands available in the GitHub CLI as well that you may or may not find useful, but it is a good tool to have around in any case. +깃허브 CLI에는 유용할 수도, 그렇지 않을 수도 있는 수많은 명령어가 있지만, 여전히 사용하기에 좋은 도구입니다. -### Managing notifications +### 알림 관리 -Instead of manually monitoring the "Issues" or "Pull Requests" tabs of the repo for new issues or PRs, you can "watch" the repo by clicking on the "Watch" button with an eye icon on the top of the repo page opposite the repo name. +새로운 이슈나 PR에 대해 **이슈** 나 **풀 요청** 탭을 수동으로 감시하지 말고, 저장소 이름 맞은편 저장소 페이지 상단에 눈 아이콘이 있는 **보기(Watch)** 버튼을 클릭하여 저장소를 감시할 수 있습니다. -![Cropped screenshot of the top right corner of a GitHub repository page showing a series of buttons in the center from left to right: Sponsor, Watch, Fork, Starred.](images/github-repo-metrics.png) +![왼쪽에서 오른쪽으로 중앙에 있는 Sponsor, Watch, Fork, Starring 등의 버튼을 포함한 깃허브(GitHub) 저장소 페이지의 오른쪽 상단을 잘라낸 스크린샷](images/github-repo-metrics.png) -By watching a repo, events such as new issues, new pull requests, mentions of your user handle, and other activities you subscribed to on the repo will be sent as notifications to your [notification page](https://github.com/notifications), where they can be marked as read or dismissed much like an email inbox. +저장소 보기를 활성화하면, 새 이슈, 풀 요청, 사용자 핸들에 대한 언급 및 저장소에서 구독한 다른 활동과 같은 이벤트가 [알림 페이지](https://github.com/notifications)에 알림으로 전송되며, 이메일의 받은 편지함과 비슷하게 _읽음_, _삭제됨_ 으로 표시될 수 있습니다. -In some cases, you may receive emails from GitHub about events in the repo you are watching as well, and you can customize these (including unsubscribing from them completely) from your [notifications settings page](https://github.com/settings/notifications). +경우에 따라 보기가 활성화된 저장소에 대한 이메일을 GitHub로부터 수신할 수도 있으며, [알림 설정 페이지](https://github.com/settings/notifications)에서 (아예 구독 취소하는 것을 포함한) 사용자 설정을 할 수 있습니다. -Setting these up to fit the way you work can be the difference between having to find relevant issues/PRs to review manually and being overwhelmed by endless notifications from GitHub. A good balance is required here. As a starting suggestion, stewards should watch this repo for "Issues" and "Pull Requests" and set it to only receive emails on "Participating, @mentions and custom." +작업 방식에 맞게 이를 설정하고 싶다면, 검토할 관련 이슈 및 PR을 수동으로 찾아야 하는 귀찮음과, 깃허브의 끝없는 알림 속에서의 압도 사이에서 어떤 것을 선택할 것인지에 대한 기로에 서 있게 됩니다. 여기에는 균형 잡힌 선택이 필요한데, 만약 처음이라면 스튜어드는 **이슈**와 **풀 요청**에 대해 이 저장소에 **보기**를 활성화하고, "참여, @멘션 및 사용자 정의"에 대한 이메일만 수신하도록 설정하는 것을 추천합니다. From 3cf9d3dfae8c1be523d8efc24be930cd5f613ffe Mon Sep 17 00:00:00 2001 From: Orwiss <7181108+Orwiss@users.noreply.github.com> Date: Tue, 19 Mar 2024 10:36:14 +0900 Subject: [PATCH 05/12] Update [p5.js KO] steward_guidelines.md First Update --- .../ko/[p5.js KO] steward_guidelines.md | 222 +++++++++--------- 1 file changed, 113 insertions(+), 109 deletions(-) diff --git a/contributor_docs/ko/[p5.js KO] steward_guidelines.md b/contributor_docs/ko/[p5.js KO] steward_guidelines.md index ef7f302539..42f6a1af0c 100644 --- a/contributor_docs/ko/[p5.js KO] steward_guidelines.md +++ b/contributor_docs/ko/[p5.js KO] steward_guidelines.md @@ -1,151 +1,155 @@ -# Steward Guidelines - -Whether you have just joined us as a steward, are a seasoned maintainer of p5.js, or are somewhere in between, this guide contains information as well as tips and tricks that will help you effectively contribute to p5.js. Most of what is written here are guidelines unless otherwise stated, which means you can adapt the practices shown here to suit your workflow. - - -## Table of Contents - -- [Issues](steward_guidelines.md#issues) - - [Bug report](steward_guidelines.md#bug-report) - - [Feature request](steward_guidelines.md#feature-request) - - [Feature enhancement](steward_guidelines.md#feature-enhancement) - - [Discussion](steward_guidelines.md#discussion) -- [Pull Requests](steward_guidelines.md#pull-requests) - - [Simple fix](steward_guidelines.md#simple-fix) - - [Bug fix](steward_guidelines.md#bug-fix) - - [New feature/feature enhancement](steward_guidelines.md#new-feature-feature-enhancement) - - [Dependabot](steward_guidelines.md#dependabot) -- [Build Process](steward_guidelines.md#build-process) - - [Main build task](steward_guidelines.md#main-build-task) - - [Miscellaneous tasks](steward_guidelines.md#miscellaneous-tasks) -- [Release Process](steward_guidelines.md#release-process) -- [Tips & Tricks](steward_guidelines.md#tips--tricks) - - [Reply templates](steward_guidelines.md#reply-templates) - - [GitHub CLI](steward_guidelines.md#github-cli) - - [Managing notifications](steward_guidelines.md#managing-notifications) +# 스튜어드(Steward) 지침 + +방금 스튜어드(Steward)로 가입하셨든, p5.js의 경험 많은 유지 관리자(Maintainer)셨든, 그 사이 어딘가에 계시든, 이 안내서에는 p5.js에 효과적으로 기여하는 데 도움이 되는 정보는 물론 팁과 요령이 포함되어 있습니다. 여기에 작성된 대부분의 내용은 특별히 언급되지 않는 한 지침이며, 이는 여러분의 작업 흐름(workflow)에 맞게 여기에 표시된 관행들을 조정할 수 있음을 의미합니다. + + +## 목차 + +- [이슈(Issues)](steward_guidelines.md#issues) + - [버그 보고](steward_guidelines.md#bug-report) + - [기능 요청](steward_guidelines.md#feature-request) + - [기능 향상](steward_guidelines.md#feature-enhancement) + - [토론(Discussion)](steward_guidelines.md#discussion) +- [풀 리퀘스트(Pull Requests)](steward_guidelines.md#pull-requests) + - [간단한 수정](steward_guidelines.md#simple-fix) + - [버그 수정](steward_guidelines.md#bug-fix) + - [새로운 기능/기능 향상](steward_guidelines.md#new-feature-feature-enhancement) + - [디펜다봇(Dependabot)](steward_guidelines.md#dependabot) +- [빌드 과정](steward_guidelines.md#build-process) + - [주요 빌드 작업](steward_guidelines.md#main-build-task) + - [기타 작업](steward_guidelines.md#miscellaneous-tasks) +- [배포 과정](steward_guidelines.md#release-process) +- [팁과 요령](steward_guidelines.md#tips--tricks) + - [회신(Reply) 양식](steward_guidelines.md#reply-templates) + - [깃허브 CLI](steward_guidelines.md#github-cli) + - [알림 관](steward_guidelines.md#managing-notifications) --- -## Issues +## 이슈(Issues) -We encourage most source code contributions to start with an issue, and as such, issues are the place where most of the discussions will take place. The steps to take when reviewing an issue will depend on what kind of issue it is. The repo uses [GitHub issue templates](https://github.com/processing/p5.js/blob/main/.github/ISSUE_TEMPLATE) in order to better organize different kinds of issues and encourage issue authors to provide all relevant information about their problems. The first step in reviewing the issue will often be looking through the filled-out template and determining if you need additional information (e.g., because some fields weren't filled in or the incorrect template was used). +우리는 대부분의 소스 코드 기여가 이슈(Issue)에서 시작하는 것을 권장하며, 따라서 이슈는 대부분의 논의가 이루어지는 곳입니다. 문제를 검토할 때 취해야 할 단계는 문제의 종류에 따라 달라집니다. 리포지토리(repo)는 다양한 유형의 문제를 더 잘 정리하고 문제 작성자가 문제에 대한 정보를 모두 제공하도록 권장하기 위해 [깃허브 이슈 템플릿(templates)](https://github.com/processing/p5.js/tree/main/.github/ISSUE_TEMPLATE)을 사용합니다. 문제를 검토하는 첫 번째 단계는 종종 입력된 템플릿을 살펴보고 추가 정보가 필요한지 여부를 결정하는 것입니다 (예: 일부 필드가 입력되지 않았거나 잘못된 템플릿이 사용되었을 경우). -### Bug report +### 버그 보고 -Bug report issues should use the "Found a bug" issue template. The following workflow is typical for addressing bug reports: +버그 보고는 "버그 발견" 이슈 템플릿(template)을 사용해야 합니다. 버그 보고를 하기 위해서는 다음과 같은 과정이 일반적입니다: -1. Replicate the bug - - The goal of the template is to provide enough information for a reviewer to attempt to replicate the bug in question. - - If the reported bug is not relevant to the repo it is opened in (p5.js, p5.js-website, or otherwise): - - Transfer the issue to the relevant repo if you have access to it. - - Otherwise, leave a comment about where the bug report should be filed (with a direct link provided) and close the issue. - - The first step in reviewing a bug report is to see if enough information is provided for a bug replication, and if so, attempt to replicate the bug as described. -2. If the bug can be replicated: - - Some discussion may be required to determine the best way to fix a particular bug. Sometimes, it may be straightforward; sometimes, it may be tricky. Please refer to [p5.js' design principles](design_principles.md) when making this decision on a case-by-case basis. - - If the issue author indicated in the issue they are willing to contribute a fix: - - Approve the issue for fixing by the issue author by leaving a comment and assigning them to the issue. Use the cog button on the right side next to "Assignee". - - If the issue author does not wish to contribute a fix: - - Leave a comment recognizing the bug is replicable. - - Attempt to fix yourself or add the `help wanted` label to signal an issue needing a fix. -3. If the bug cannot be replicated: - - Ask for additional info if not already provided in the template (p5.js version, browser version, OS version, etc.). - - If your testing environment differs from what is reported in the issue (e.g., a different browser or OS): - - Leave a comment saying you are not able to replicate in your specific environment. - - Add a `help wanted` label to the issue and ask for someone else with the setup specified in the issue to try to replicate the bug. - - Sometimes, bugs only occur when using the web editor and not when testing locally. In this case, the issue should be redirected to the [web editor repo](https://github.com/processing/p5.js-web-editor). - - If replication is possible later, go back to step 2. -4. If the bug stems from the code the user provided in the bug report and not p5.js' behavior: - - Determine if p5.js' documentation, code implementation, or friendly error system can be improved to prevent the same mistake from being made. - - Kindly redirect any further questions to the [forum](https://discourse.processing.org/) or [Discord](https://discord.com/invite/SHQ8dH25r9) and close the issue if no further changes are to be made to p5.js. +1. 버그 복사 + - 템플릿의 목표는 검토자가 문제의 버그를 복사할 수 있도록 충분한 정보를 제공하는 것입니다. + - 보고된 버그가 리포지토리(repo)와 관련이 없는 경우 (p5.js, p5.js 웹사이트 등): + - 액세스 권한이 있는 경우 해당 담당자에게 문제를 전송합니다. + - 그렇지 않으면 버그 보고서가 위치할 곳에 대한 답변을 (직접 연결되는 링크와 함께) 남기고 문제를 닫습니다. + - 버그 보고를 검토하는 첫 번째 단계는 버그 복사를 위해 충분한 정보가 제공되는지 확인하고, 제공되는 경우에, 설명된 대로 버그 복제를 시도하는 것입니다. +2. 버그를 복사할 수 있는 경우: + - 특정 버그를 고치는 최선의 방법을 찾기 위해 약간의 논의가 필요할 수 있습니다. 때로는 간단할 수도 있고 때로는 까다로울 수도 있습니다. 사례별로 이러한 결정을 내릴 때는 [p5.js 디자인 원칙](notion://www.notion.so/cybergeist/design_principles.md)를 참조하세요. + - 이슈 작성자가 수정에 기여할 의향이 있는 경우: + - Approve the issue for fixing by the issue author by leaving a comment and assigning them to the issue. “담당자(Assignee)” 우측에 있는 톱니바퀴 버튼을 사용하세요. + - 이슈 작성자가 수정에 기여하기 원하지 않는 경우: + - 버그를 복사할 수 있는지 알 수 있는 댓글을 남깁니다. + - 수정을 시도하거나 `help wanted` 레이블을 추가하여 수정이 필요한 문제를 표시합니다. +3. 버그를 복사할 수 없는 경우: + - 템플릿(template)에 정보가 부족하다면 추가 정보를 요청합니다 (p5.js 버전, 브라우저 버전, OS 버전 등). + - 테스트 환경이 이슈의 내용과 다른 경우 (예: 다른 브라우저 또는 OS): + - 여러분의 특정 환경에서 복사할 수 없다는 의견을 남깁니다. + - 이슈에 `help wanted` 레이블을 추가하고 같은 설정을 가진 사람에게 버그 복사를 요청합니다. + - 버그는 종종 웹 에디터를 사용할 때만 발생하고 로컬에서 테스트할 때는 발생하지 않습니다. 이 경우 문제를 [웹 에디터 리포지토리(repo)](https://github.com/processing/p5.js-web-editor)로 리디렉션해야 합니다. + - 나중에 복사가 가능하게 된 경우 2번로 다시 이동합니다. +4. p5.js의 동작이 아니라 사용자가 버그 보고서에 제공한 코드에서 버그가 발생한 경우: + - p5.js의 문서화, 코드 구현 또는 친근 오류 시스템(friendly error system)을 개선하여 동일한 오류가 발생하지 않도록 할 수 있는지 판단합니다. + - 추가 질문이 있으면 [포럼(forum)](https://discourse.processing.org/) 또는 [디스코드(Discord)](https://discord.com/invite/SHQ8dH25r9) 로 리디렉션하고 p5.js에 더 이상 변경사항이 없다면 문제를 종료하세요. -### Feature request +### 기능 요청 -Feature request issues should use the "New Feature Request" issue template. The following workflow is typical for addressing feature requests: +기능 요청은 "새로운 기능 요청" 이슈 템플릿(template)을 사용해야 합니다. 새로운 기능을 요청하기 위해서는 다음과 같은 과정이 일반적입니다: -1. As part of p5.js' commitment to increase access, a feature request must make a case for how it increases access of p5.js to communities that are historically marginalized in the field. More details are available [here](access.md). - - If a feature request does not have the "Increasing Access" field sufficiently filled out, you can ask the issue author how the feature increases access. - - The access statement of a feature can be provided by a different member of the community, including the issue reviewers. -2. The new feature request can be assessed for inclusion based on the following criteria. - - Does the feature fit into the project scope and [design principles](design_principles.md) of p5.js? - - For example, a request to add a new drawing primitive shape may be considered, but a request to adopt a browser-based IOT protocol will likely be out of scope. - - Overall, the scope of p5.js should be relatively narrow in order to avoid excessive bloat from rarely used features. - - If a feature does not fit into the scope of p5.js, suggest that the issue author implement the feature as as an addon library. - - If it is unclear whether or not it fits, it can be a good idea to suggest making an addon library as a proof-of-concept. This helps give users a way to use the feature, provides a much more concrete example of its usage and importance, and does not necessarily need to be as complete of a solution as a fully integrated feature. It can be integrated into the core of p5.js later if appropriate. - - Is the feature likely to cause a breaking change? - - Will it conflict with existing p5.js functions and variables? - - Will it conflict with typical sketches already written for p5.js? - - Features that are likely to cause conflicts such as  the ones above  are  considered breaking changes. Without a [major version release](https://docs.npmjs.com/about-semantic-versioning), we should not make breaking changes to p5.js. - - Can the proposed new feature be achieved using existing functionalities already in p5.js, relatively simple native JavaScript code, or existing easy-to-use libraries? - - For example, instead of providing a p5.js function to join an array of strings such as `join(["Hello", "world!"])`, the native JavaScript `["Hello", "world!"].join()` should be preferred instead. -3. If the access requirement and other considerations have been fulfilled, at least two stewards or maintainers must approve the new feature request before work should begin toward a PR. The PR review process for new features is documented below. +1. 기능 요청은 p5.js의 접근성 향상을 위한 노력의 일환으로, 해당 분야에서 역사적으로 소외된 커뮤니티에서 p5.js의 접근성을 높이는 방법에 대한 사례가 되어야 합니다. 자세한 내용은 [이 곳](notion://www.notion.so/cybergeist/access.md)에서 볼 수 있습니다. + - 기능 요청에 "접근성 증가" 필드가 충분히 입력되지 않은 경우, 이슈 작성자에게 이 기능이 어떻게 접근성을 높이는지 질문할 수 있습니다. + - 기능의 접근성은 이슈 검토자를 포함한 커뮤니티의 다른 구성원이 제공할 수 있습니다. +2. 새로운 기능 요청은 다음 기준에 따라 포함 여부를 평가할 수 있습니다. + - 해당 기능이 p5.js의 프로젝트 범위와 [디자인 원칙](design_principles.md)에 적합한가요? + - 예를 들어, 새로운 기본 도형을 추가하는 요청은 고려될 수 있지만, 브라우저 기반 IOT 프로토콜을 채택하기 위한 요청은 범위에서 벗어날 가능성이 높습니다. + - 전체적으로, p5.js의 범위는 거의 사용되지 않는 기능으로부터 지나친 팽창을 피하기 위해 상대적으로 범위가 좁아야 합니다. + - 기능이 p5.js 범위에 맞지 않는 경우, 이슈 작성자가 기능을 애드온 라이브러리(addon library)로 만들도록 제안합니다. + - 범위에 맞는지 불분명한 경우, 개념 증명으로써 애드온 라이브러리를 만드는 것을 제안하는 것이 좋습니다. 이는 사용자에게 기능을 사용할 수 있는 방법을 제공하고, 쓰임새와 중요성에 대한 훨씬 더 구체적인 예시를 제공하며, 완전히 통합된 기능처럼 해결책이 완벽할 필요는 없습니다. 나중에 적합하다고 판단될 경우 p5.js 내에 통합될 수 있습니다. + - 기능이 호환되지 않는 변경(breaking changes)의 원인이 될 수 있나요? + - 기존 p5.js 함수 및 변수와 충돌이 발생할까요? + - 기존에 p5.js로 작성된 일반적인 스케치와 충돌할까요? + - 위와 같이 충돌을 일으킬 수 있는 기능들은 호환되지 않는 변경 사항으로 간주됩니다. [주요 버전 배포](https://docs.npmjs.com/about-semantic-versioning)가 아니면 우리는 p5.js에 호환되지 않는 변경 사항을 만들지는 않습니다. + - 제안된 새로운 기능이 이미 p5.js에 있는 기존 기능, 비교적 간단한 순수 자바스크립트 코드나 기존의 사용하기 쉬운 라이브러리를 사용하여 만들어질 수 있요? + - 예를 들어, `join(["Hello", "world!"])` 와 같은 문자열 배열에 p5.js 기능을 제공하는 것보다는 자바스크립트 기본 문법의 `["Hello", "world!"].join()` 가 우선되어야 합니다. +3. 접근 요구 사항과 나머지 고려 사항이 충족된 경우, PR을 시작하기 전에 최소 2명의 스튜어드(Stewards) 또는 유지 관리자(Maintainers)가 새로운 기능 요청을 승인해야 합니다. 새로운 기능에 대한 PR 검토 과정은 아래에 설명되어 있습니다. -### Feature enhancement +### 기능 향상 -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. +기능 향상 이슈는 "기존 기능 향상" 이슈 템플릿(template)을 사용해야 합니다. 이 과정은 새로운 기능 요청과 매우 비슷합니다. 가끔 새로운 기능 요청과 기능 향상의 차이가 명확하지 않을 수 있습니다. 기능 향상은 주로 p5.js의 기존 기능을 다루지만, 새로운 기능 요청은 완전히 새로운 기능을 추가하도록 요청할 수 있습니다. -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). -2. Inclusion criteria for feature enhancements are similar to those for feature requests, but particular attention should be paid to potential breaking changes. - - If modifying existing functions, all previous valid and documented function signatures must behave in the same way. -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. +1. 새로운 기능 요청과 마찬가지로 기능 향상은 p5.js에 대한 접근성을 높이는 경우에만 허용되어야 합니다. [위 섹션](http://guidelines.md#feature-request)의 1번 항목을 참고해주세요. +2. 기능 향상에 대한 포함? 기준은 기능 요청의 경우와 비슷하지만, 잠재적인 호환되지 않는 변경 사항(breaking changes)을 특히 주의해야 합니다. + - 기존 기능을 수정하는 경우, 모든 이전의 유효하고 문서화된 함수 시그니처가 같은 방식으로 동작해야 합니다. +3. 기능 향상은 PR이 시작되기 전에 적어도 한 명의 스튜어드(Steward) 또는 유지보수자(Maintainer)의 승인을 받아야 합니다. 기능 향상을 위한 PR 검토 과정은 아래에 문서화되어 있습니다. +### 토론(Discussion) -### Discussion +이 유형의 이슈는 최소한의 템플릿 ("토론")을 가지고 있으며 기능 요청과 같은 좀 더 구체적인 것으로 통합하기 전에 일반적으로 주제에 대한 피드백을 모으는 데에 사용되어야 합니다. 이런 종류의 토론 이슈는 대화가 끝나고 구체적인 문제가 생성되면 종료될 수 있습니다: -This type of issue has a minimal template ("Discussion") and should be used to gather feedback around a topic in general before coalescing it into something more specific, like a feature request. These sorts of discussion issues can be closed when the conversation finishes and the resulting more specific issues have been created:  - -- If an issue is opened as a discussion but should be, for example, a bug report, the correct label should be applied and the "discussion" label removed. Additional info about the bug should also be requested from the author if not already included. -- If an issue is opened as a discussion but isn't relevant to source code contribution or otherwise relevant to the GitHub repositories/contribution process/contribution community, they should be redirected to the forum or Discord and the issue closed. -- If relevant, additional labels should be added to discussion issues to further signal what type of discussion it is at a glance. +- 이슈가 토론으로 열려 있다면 버그 보고 같은 것들은 올바른 레이블을 적용하고 “토론” 레이블을 없애야 합니다. 버그에 대한 추가 정보가 포함되지 않았다면 작성자에게 요청해야 합니다. +- 토론으로 이가 열렸지만 소스 코드 기여와 관련이 없거나 깃허브 리포지토리(repository)/기여 과정/기여 커뮤니티와 관련이 없는 경우 포럼(forum) 또는 디스코드(Discord)로 리디렉션하 문제를 닫아야 합니다. +- 관련이 있는 경우에는, 한 눈에 어떤 유형의 토론인지 알 수 있게 표시하기 위해 토론 이슈에 레이블을 추가해야 합니다. --- -## Pull Requests - -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: +## 풀 리퀘스트(Pull Requests) -- Pull request template can be found [here](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md). -- 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. - - 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. - - 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. -- 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. +p5.js 리포지토리(repository)에 대한 대부분의 코드 기여는 풀 리퀘스트(pull request)를 통해 이루어집니다. 스튜어드(Stewards)와 유지보수자(Maintainers)는 리포지토리에 대한 푸시(push) 권한이 있지만 코드 기여 시에 똑같이 이슈 > PR > 검토 과정을 거치도록 권장합니다. PR을 검토하는 단계는 다음과 같습니다: +- 풀 리퀘스트 템플릿(template)은 [이 곳](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md)에서 확인할 수 있습니다. +- 거의 모든 풀 리퀘스트는 먼저 관련 이슈를 열고 논의해야 합니다. 즉, 관련 [이슈 작업 절차(workflow)](notion://www.notion.so/cybergeist/steward_guidelines.md#issues)를 먼저 따른 뒤에 스튜어드나 유지 관리자가 검토해야 합니다. + - 절차가 적용되지 않는 유일한 경우는 매우 간단한 오타 수정 뿐이며, 이슈를 열 필요가 없고 특정 분야의 스튜어드가 아니더라도 리포지토리에 대한 병합(merge) 권한이 있는 모든 사람이 병합할 수 있습니다. + - 이러한 예외가 존재하지만, 우리는 기여자들이 새로운 이슈를 먼저 열도록 권장될 때에만 예외를 적용할 것입니다. 즉, 예외가 적용될지 잘 모르겠다면 어쨌든 이슈를 열어보세요! +- 풀 리퀘스트가 참조된 문제가 완전히 해결해 주지 않았다면, 원본 게시물(post)의 "Resolves #OOOO"를 "Addresses #OOOO"로 수정하여 PR 병합 시에 원본 이슈가 자동으로 닫히지 않게끔 할 수 있습니다. -### Simple fix +### 간단한 수정 -Simple fixes, such as a small typo fix, can be merged directly by anyone with merge access.  Check on the PR "Files Changed" tab to ensure  that the automated CI test passes. +약간의 오타 수정 같은 간단한 수정은 병합(merge) 권한이 있는 누구나 직접 병합할 수 있습니다. PR “Files Changed” 탭에서 자동화된 CI 테스트를 통과하는지 확인하세요. ![The "files changed" tab when viewing a pull request on GitHub](images/files-changed.png) ![The "All checks have passed" indicator on a GitHub pull request, highlighted above the merge button](images/all-checks-passed.png) -### Bug fix +### 버그 수정 -1. Bug fixes should be reviewed by the relevant area steward, ideally the same one that approved the referenced issue for fixing. -2. The PR "Files Changed" tab can be used to initially review whether the fix is implemented as described in the issue discussion. -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)). - - [ ] The fix should address the original issue sufficiently. - - [ ] The fix should not change any existing behaviors unless agreed upon in the original issue. - - [ ] The fix should not have a significant performance impact on p5.js. - - [ ] The fix should not have any impact on p5.js' accessibility. - - [ ] The fix should use the modern standard of JavaScript coding. - - [ ] The fix should pass all automated tests and include new tests if relevant. -4. If any additional changes are required, line comments should be added to the relevant lines as described [here](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request#adding-line-comments-to-a-pull-request). - - A suggestion block can also be used to suggest specific changes:\ +1. 버그 수정은 관련 분야의 스튜어드(Steward)가 해야 합니다. 이상적으로는 참조된 이슈를 수정하도록 승인한 것과 같습니다. +2. PR "Files Changed" 탭을 이슈 토론(discussion)에 설명된 대로 수정이 되었는지 최초로 검토하는 데에 사용할 수 있습니다. +3. PR은 가능하고 적절하다면 로컬에서 테스트해야 합니다. GitHub CLI는 일부 과정을 간소화하는 데에 도움이 될 수 있습니다 (더 많은 내용은 아래의 [팁과 요령](notion://www.notion.so/cybergeist/steward_guidelines.md#tips-tricks)에 있습니다). + - [ ] 수정은 원래의 이슈를 충분히 해결해야 합니다. + - [ ] 수정은 원래의 이슈에서 합의되지 않는 한 기존 동작을 변경해서는 안됩니다. + - [ ] 수정은 p5.js의 성능에 큰 영향을 주지 않아야 합니다. + - [ ] 수정은 p5.js의 접근성에 어떤 영향도 주지 않아야 합니다. + - [ ] 수정은 최신 표준 자바스크립트 코딩을 사용해야 합니다. + - [ ] 수정사항은 자동화된 테스트를 모두 통과해야 하고 관련 있는 경우에 새 테스트를 포함해야 합니다. +4. 추가 변경 사항이 필요한 경우, [이 곳](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request#adding-line-comments-to-a-pull-request)에 설명된 대로 해당 행에 행 주석(line comments)을 추가해야 합니다. + - 제안 블록(block)으로 특정 변경 사항을 제안할 수도 있습니다:\ ![The Suggest Change button while writing a comment on code in a GitHub pull request](images/suggest-change.png)\ ![A suggested change appearing within code fences with the "suggestion" tag](images/suggested-value-change.png)\ ![A suggested change previewed as a diff](images/suggestion-preview.png) - - If multiple changes are required, don’t add single-line comments many times. Instead, follow the procedure documented [here](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request) to make multiple-line comments and a single request for changes. - - If line comments are just for clarification or discussion, choose “Comment” instead of "Request changes":\ + - 여러 번 변경이 필요한 경우 한 줄 주석(single-line comments)을 여러 번 추가하지 마세요. 대신 문서화된 [이 곳](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)에 절차에 따라 여러 줄 주석(multiple-line comments)과 한 번의 요청으로 변경하세요. + - 행 주석(line comments)이 설명이나 토론을 위한 것이라면, “변경 요청(Request changes)” 대신 “답글(Comment)”을 선택해 주세요:\ ![The "comment" option circled within the GitHub Finish Review menu](images/comment-review.png) -5. Once the PR has been reviewed and no additional changes are required, a steward can mark the PR as "Approved" by choosing the "Approve" option in the previous step, with or without additional comments. The steward can then either request additional review by another steward or maintainer if desired, merge the PR if they have merge access, or request a merge from a maintainer. - -6. @[all-contributors](https://allcontributors.org/docs/en/emoji-key) bot should be called to add any new contributors to the list of contributors in the README.md file. Each type of contribution can be indicated in place of `[contribution` `type]` below, the full list of available types of contributions can be found in the link above. +5. 한 번 PR이 검토되고 더 이상 변경이 필요하지 않으면 스튜어드(Steward)는 추가 댓글이 있든 없든 이전 단계에서 “승인(Approve)” 옵션을 선택하여 PR을 “승인(Approved)”으로 표시할 수 있습니다. 그런 다음 스튜어드는 원한다면 다른 스튜어드나 유지 관리자(Maintanier)에게 추가 검토를 요청할 수 있고, 병합(merge) 권한이 있다면 PR을 병합하거나 유지 관리자에게 병합을 요청할 수 있습니다. + +6. 새로운 기여자를 [README.md](http://readme.md/) 파일의 기여자 목록에 추가하려면 @[all-contributors](https://allcontributors.org/docs/en/emoji-key) 봇을 호출해야 합니다. 각각의 기여 유형은 아래의 `[contribution` `type]` 대신 표시할 수 있고, 사용할 수 있는 기여 유형의 전체 목록은 위 링크에서 확인할 수 있습니다. + + ![images/suggest-change.png](images/suggest-change.png) + + ![images/suggested-value-change.png](images/suggested-value-change.png) + + ![images/suggestion-preview.png](images/suggestion-preview.png) `@all-contributors` `please` `add` `@[GitHub` `handle]` `for` `[contribution` `type]` From d5de08652e4d79ca5aacb3279eda4f48d5dabf47 Mon Sep 17 00:00:00 2001 From: IENGROUND Date: Tue, 19 Mar 2024 14:32:18 +0900 Subject: [PATCH 06/12] Update [p5.js KO] steward_guidelines.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit connect:server 뒷부분 1차 피드백 반영 --- .../ko/[p5.js KO] steward_guidelines.md | 73 +++++++++++-------- 1 file changed, 42 insertions(+), 31 deletions(-) diff --git a/contributor_docs/ko/[p5.js KO] steward_guidelines.md b/contributor_docs/ko/[p5.js KO] steward_guidelines.md index 42f6a1af0c..c1145b09b4 100644 --- a/contributor_docs/ko/[p5.js KO] steward_guidelines.md +++ b/contributor_docs/ko/[p5.js KO] steward_guidelines.md @@ -243,19 +243,19 @@ A few small detailed steps are left out here; you can check out the browserify b connect:server ``` -이 단계에서는 테스트 파일과 빌드된 소스 코드 파일을 호스팅하는 로컬 서버를 가동하여 Chrome에서 자동화된 테스트를 실행할 수 있도록 합니다. +이 단계에서는 테스트 파일과 빌드된 소스 코드 파일을 호스팅하는 로컬 서버를 가동하여 크롬(Chrome)에서 자동화된 테스트를 실행할 수 있도록 합니다. ``` mochaChrome ``` -이 단계는 [./tasks/test/mocha-chrome.js](tasks/test/mocha-chrome.js)에 정의되어 있습니다. Puppeteer를 사용해 원격 제어가 가능한 Chrome의 헤드리스 버전을 가동하고, `./test` 폴더에 있는 HTML 파일과 관련된 테스트를 실행합니다. 여기에는 라이브러리의 축소되지 않은 버전과 축소된 버전을 단위 테스트(unit test) 모음에 대해 테스트하는 것은 물론, 모든 참조 예제를 테스트하는 것도 포함되어 있습니다. +이 단계는 [./tasks/test/mocha-chrome.js](tasks/test/mocha-chrome.js)에 정의되어 있습니다. Puppeteer를 사용해 원격 제어가 가능한 크롬의 헤드리스 버전을 가동하고, `./test` 폴더에 있는 HTML 파일과 관련된 테스트를 실행합니다. 여기에는 라이브러리의 축소되지 않은 버전과 축소된 버전을 단위 테스트(unit test) 모음에 대해 테스트하는 것은 물론, 모든 레퍼런스 예제를 테스트하는 것도 포함되어 있습니다. ``` mochaTest ``` -이 단계는 Chrome 대신 node.js에서 실행되고 라이브러리의 기능 중 일부만 테스트한다는 점에서 `mochaChrome`과 차이가 있습니다. 대부분의 p5.js 기능은 브라우저 환경이 필요하므로 이 테스트 세트는 새로운 테스트에 브라우저 환경이 필요하지 않을 때만 확장해야 합니다. +이 단계는 크롬 대신 node.js에서 실행되고 라이브러리의 기능 중 일부만 테스트한다는 점에서 `mochaChrome`과 차이가 있습니다. 대부분의 p5.js 기능은 브라우저 환경이 필요하므로 이 테스트 세트는 새로운 테스트에 브라우저 환경이 필요하지 않을 때만 확장해야 합니다. ``` nyc:report @@ -263,7 +263,7 @@ nyc:report 마지막으로, 모든 빌드와 테스트가 완료되면 이 단계에서는 `mochaChrome`이 전체 라이브러리 버전을 테스트하는 동안 테스트 커버리지 보고서를 수집하고, 테스트 범위 데이터를 콘솔에 출력합니다. p5.js의 테스트 커버리지는 주로 추가적인 데이터 포인트를 모니터링하고 확보하는 것으로, 테스트 커버리지 100%를 목표로 하지는 않습니다. -그리고 그것은 Gruntfile.js 구성의 기본 작업을 다루고 있습니다! +여기까지 우리는 Gruntfile.js 의 기본적인 환경 구성(configuration) 작업을 다루어 보았습니다. ### 기타 작업 @@ -274,9 +274,9 @@ nyc:report grunt yui:dev ``` -이 작업은 위에 설명된 문서 및 라이브러리 빌드를 실행한 다음, [http://localhost:9001/docs/reference/](http://localhost:9001/docs/reference/)의 웹사이트에서 찾을 수 있는 참조 페이지와 유사한 기능을 가진 버전을 제공하는 웹 서버를 가동합니다. 그런 다음 소스 코드의 변경점을 모니터링하고 문서와 라이브러리를 다시 빌드합니다. +이 작업은 위에 설명된 문서 및 라이브러리 빌드를 실행한 다음, 웹 서버를 가동합니다. 이 웹 서버는 [http://localhost:9001/docs/reference/](http://localhost:9001/docs/reference/)와 기능적으로 유사한 레퍼런스 페이지를 제공합니다. 그런 다음 소스 코드의 변경점을 모니터링하고 문서와 라이브러리를 다시 빌드합니다. -`grunt` `yui:dev`는 인라인 문서의 참조 작업을 할 때 유용한데, 빌드된 파일을 p5.js 저장소(repository)에서 로컬 p5.js-웹사이트 저장소로 이동할 필요도, 변경사항이 생길 때마다 웹사이트를 다시 빌드할 필요도 없기 때문입니다. 그저 브라우저에서 약간 단순화된 참조 버전으로 변경사항을 미리 보면 됩니다. 이렇게 하면 변경사항이 웹사이트에 더욱 올바르게 표시될 것이라는 확신을 가질 수도 있습니다. 이는 인라인 문서를 수정하는 경우에만 해당된다는 것을 알아두세요. 스타일 및 레이아웃 작업을 포함한 참조 페이지 자체에 대한 변경사항은 웹사이트 저장소에서 생기고 테스트해야 합니다. +`grunt` `yui:dev`는 인라인 문서의 레퍼런스 작업을 할 때 유용한데, 빌드된 파일을 p5.js 저장소(repository)에서 로컬 p5.js 웹사이트 저장소로 이동할 필요도, 변경사항이 생길 때마다 웹사이트를 다시 빌드할 필요도 없기 때문입니다. 그저 브라우저에서 약간 단순화된 레퍼런스 버전으로 변경사항을 미리 보면 됩니다. 이렇게 하면 변경사항이 웹사이트에 올바르게 표시되는지 여부를 확인할 수 있습니다. 이는 인라인 문서를 수정하는 경우에만 해당된다는 것을 알아두세요. 스타일 및 레이아웃 작업을 포함한 레퍼런스 페이지 자체에 대한 변경사항은 웹사이트 저장소에서 생성 및 테스트해야 합니다. ``` @@ -285,15 +285,15 @@ grunt watch:main grunt watch:quick ``` -Watch 작업은 여러 파일의 변경사항을 감시하고, 관련 작업을 실행하여 변경된 파일에 따라 참조나 라이브러리를 빌드합니다. 이러한 작업은 범위의 차이를 제외하면 모두 동일한 작업을 수행합니다. +워치(Watch) 작업은 여러 파일의 변경사항을 감시하고, 관련 작업을 실행하여 변경된 파일에 따라 레퍼런스나 라이브러리를 빌드합니다. 이러한 작업은 범위의 차이를 제외하면 모두 동일한 작업을 수행합니다. -`watch` 작업은 소스 코드의 변경사항을 감지할 때 전체 기본 작업을 실행하는 것과 비슷한 모든 빌드와 테스트를 실행합니다. +`watch` 작업은 소스 코드의 변경사항을 감지할 때 모든 빌드와 테스트를 실행합니다. 마치 전체 기본 작업을 실행하는 것처럼 보일 거예요. -`watch:main` 작업은 라이브러리 빌드와 테스트를 실행하지만, 소스 코드의 변경사항을 감지해도 참조를 다시 빌드하지는 않습니다. +`watch:main` 작업은 라이브러리 빌드와 테스트를 실행하지만, 소스 코드의 변경사항을 감지해도 레퍼런스를 다시 빌드하지는 않습니다. `watch:quick` 작업은 소스 코드의 변경사항이 감지된 경우에만 라이브러리 빌드를 실행합니다. -작업 중인 내용에 따라 가장 적은 감시 작업이 일어나는 것을 선택한다면 변경사항을 만들고 싶을 때마다 수동으로 다시 빌드를 하지 않아도 됩니다. +작업 중인 내용에 따라 가장 효율적인 워치(watch) 작업 방식을 선택한다면 매 변경사항마다 수동으로 다시 빌드하지 않아도 됩니다. --- @@ -307,66 +307,77 @@ Watch 작업은 여러 파일의 변경사항을 감시하고, 관련 작업을 ## 팁과 요령 -때때로 검토가 필요한 이슈와 PR의 수가 너무 많아질 수도 있습니다. 저희가 이를 더 쉽게 만드는 과정을 마련하려는 동안 이슈와 PR을 검토하는 데 도움이 될 만한 몇 가지 팁과 요령을 알려드립니다. +때때로 검토가 필요한 이슈와 PR의 수가 너무 많아질 수도 있습니다. 보다 용이한 이슈 및 PR 검토를 위한 팁과 요령 몇 가지를 알려드립니다. -### 회신(Reply) 양식 +### 회신 양식 (Reply Template) -사용할 수 있는 편리한 깃허브(GitHub) 기능은 이슈 또는 풀 요청(pull request)에 대한 회신을 작성할 떄 사용할 수 있는 [저장된 회신](https://docs.github.com/en/get-started/writing-on-github/working-with-saved-replies/about-saved-replies) 기능입니다. 위에 설명된 작업 흐름(workflow) 중 일부는 동일하거나 매우 유사한 답변(포럼으로 질문을 리디렉션하거나, 수정을 위한 이슈 수락 등)으로 이슈 또는 PR에 응답해야 할 수도 있는데, **저장된 회신**을 사용하면 이 작업의 효율이 조금 더 올라갈 수 있습니다. +이슈 또는 풀 리퀘스트에 대한 회신 작성을 돕는 깃허브(GitHub) 기능인 [저장된 회신(Saved Replies)](https://docs.github.com/en/get-started/writing-on-github/working-with-saved-replies/about-saved-replies)이 있습니다. 위에 설명된 작업 흐름(workflow) 중 일부는 동일하거나 매우 유사한 답변(포럼으로 질문을 리디렉션하거나, 수정을 위한 이슈 승인 등)으로 이슈 또는 PR에 응답해야 할 수도 있는데, **저장된 회신**을 사용하면 이 작업의 효율이 조금 더 올라갈 수 있습니다. -다음은 p5.js 메인테이너가 사용하는 **저장된 회신**의 일부입니다. 이를 사용하거나 직접 만들어 보세요! +다음은 p5.js 유지관리자(maintainer)가 사용하는 **저장된 회신**의 일부입니다. 이를 사용하거나 직접 만들어 보세요! -##### 종결: 재현할 수 없음 +##### 종결(Closing): 재현할 수 없음 +> We're not able to reproduce this, but please feel free to reopen if you can provide a code sample that demonstrates the issue. Thanks! > 이것을 재현할 수는 없지만, 이 이슈를 보여줄 수 있는 샘플 코드를 제공할 수 있다면 다시 열어주세요. 감사합니다! -##### 종결: 스니펫 필요 +##### 종결(Closing): 스니펫 필요 +>I'm closing this for organizational purposes. Please reopen if you can provide a code snippet that illustrates the issue. Thanks! -> 조직적인 목적으로 이 이슈를 종결합니다. 이 이슈를 설명하는 코드 스니펫을 제공할 수 있다면 다시 열어주세요. 감사합니다! +> 조직 운영 및 관리 차원에서 이 이슈를 종결합니다. 이 이슈를 설명하는 코드 스니펫을 제공할 수 있다면 다시 열어주세요. 감사합니다! -##### 종결: 포럼 사용 +##### 종결(Closing): 포럼 사용 +>The GitHub issues here are a good place for bugs and issues with the p5.js library itself. For questions about writing your own code, tests, or following tutorials, the [forum](https://discourse.processing.org/) is the best place to post. Thanks! -> 이 깃허브 이슈는 p5.js 라이브러리 자체의 버그나 이슈를 올리기에 좋은 곳입니다. 여러분의 코드나 테스트, 또는 튜토리얼을 따라하는 것에 대한 질문을 하고 싶다면 [포럼](https://discourse.processing.org/)만한 곳이 없을 거에요. 감사합니다! +> 깃허브 이슈는 p5.js 라이브러리 자체의 버그나 이슈를 올리는 곳입니다. 여러분의 코드나 테스트, 또는 튜토리얼에 대한 것에 대한 질문을 하고 싶다면 [포럼](https://discourse.processing.org/)만한 곳이 없을 거에요. 감사합니다! -##### 종결: GSOC +##### 종결(Closing): GSOC +>Thanks! The best place to discuss GSOC proposals is on our [forum](https://discourse.processing.org/c/summer-of-code). > 감사합니다! GSOC 제안을 논의하고 싶다면 우리의 [포럼](https://discourse.processing.org/c/summer-of-code)만한 곳이 없답니다. -##### 종결: 접근성 +##### 종결(Closing): 접근성 +>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. -> 저는 이 기능에 큰 관심이 없고, 어떻게 [접근성을 확장](access.md)하는지에 대한 명확한 설명이 없으므로 일단 이 이슈를 종결하겠습니다. 이슈 요청에 접근성 설명을 추가할 수 있게 되면 언제든지 다시 열어주세요. +> 우리는 이 기능으로부터 큰 이점을 찾을 수 없고, 어떻게 [접근성을 확장](access.md)하는지에 대한 명확한 설명이 없으므로 일단 이 이슈를 종결하겠습니다. 이슈 요청에 접근성 설명을 추가할 수 있게 되면 언제든지 다시 열어주세요. + +>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! > 이 이슈로 인해 어떻게 [접근성이 확장](access.md)되는지에 대한 추가 설명이 없으므로 일단 이 이슈를 종결하겠습니다. 기능 요청에 더 자세한 접근성 설명을 추가할 수 있게 되면 언제든지 다시 열어주세요. 감사합니다! -##### 종결: 애드온 +##### 종결(Closing): 애드온(Addon, 부가 기능) +>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) -> 저는 이 기능이 p5.js API의 범위를 벗어나는 것이라고 생각하지만 (최소한의 크기를 유지하고 싶어요), 애드온 라이브러리를 만드는 좋은 시작점이 될 것 같습니다. 애드온을 생성하는 방법을 알고 싶다면 이 문서를 확인해 보세요. [https://github.com/processing/p5.js/blob/main/contributor\_docs/creating\_libraries.md](creating_libraries.md) +> 기능이 p5.js API 범위를 벗어나는 것 같지만 (우리는 최소한의 크기를 유지하고 싶어요), 애드온 라이브러리를 만드는 좋은 시작점이 될 것 같습니다. 애드온을 생성하는 방법을 알고 싶다면 이 문서를 확인해 보세요. [https://github.com/processing/p5.js/blob/main/contributor\_docs/creating\_libraries.md](creating_libraries.md) -##### PR 종결: 이슈가 먼저 필요함 +##### PR 종결(Closing): 이슈가 먼저 필요함 +>Thank you. As a reminder, issues need to be opened before pull requests are opened and tagged with the issue. This is necessary for tracking development and keeping discussion clear. Thanks! -> 감사합니다. 참고로, 풀 요청(pull request)을 게시하고 이슈에 태그를 지정하기 전에 먼저 이슈를 게시해야 합니다. 이는 개발을 추적하고 토론을 명확하게 유지하는 데 필요해요. 감사합니다! +> 감사합니다. 참고로, 풀 리퀘스트를 게시하고 이슈에 태그를 지정하기 전에 먼저 이슈를 게시해야 합니다. 이는 개발을 추적하고 토론을 명확하게 유지하는 데 필요해요. 감사합니다! ##### 이슈 해결 승인 +>You can go ahead with a fix. Thanks. > 계속 해결해도 됩니다. 감사합니다! ##### PR 병합 +>Looks good. Thanks! > 괜찮아 보이는데요? 감사합니다! ### 깃허브 CLI -테스트할 PR의 코드 버전을 로컬로 가져오는 데 필요한 복잡한 git 명령어를 사용하면 복잡한 PR을 검토하는 게 어려울 수 있습니다. 다행히도 [깃허브 CLI](https://cli.github.com/)가 이 과정에서 큰 도움을 줄 수 있겠군요. +코드가 복잡한 PR의 경우, 여러분이 로컬에서 테스트할 코드 버전을 복잡한 git 명령어로 가져오면 검토가 어려울 수 있습니다. 다행히도 [깃허브 CLI](https://cli.github.com/)가 이 과정에서 큰 도움을 줄 수 있겠군요. CLI를 설치하고 로그인하고 `gh pr checkout [pull_request_id]` 명령어를 실행하면 로컬에서 PR 검토가 가능하며, 원격 포크 가져오기, 브랜치 생성, 브랜치 체크아웃 과정이 모두 자동으로 수행됩니다. main 브랜치로 돌아가는 것은 `git checkout main`으로 브랜치를 전환하는 것과 같습니다. 심지어 웹사이트를 방문하지 않고도 CLI에서 PR에 댓글을 남길 수도 있습니다! @@ -375,12 +386,12 @@ CLI를 설치하고 로그인하고 `gh pr checkout [pull_request_id]` 명령어 ### 알림 관리 -새로운 이슈나 PR에 대해 **이슈** 나 **풀 요청** 탭을 수동으로 감시하지 말고, 저장소 이름 맞은편 저장소 페이지 상단에 눈 아이콘이 있는 **보기(Watch)** 버튼을 클릭하여 저장소를 감시할 수 있습니다. +새로운 이슈나 PR에 대해 **이슈** 나 **풀 리퀘스트** 탭을 수동으로 확인하는 대신, 저장소 이름 반대편 저장소 페이지 상단에 눈 아이콘이 있는 **보기(Watch)** 버튼을 클릭하여 저장소를 확인할 수 있습니다. -![왼쪽에서 오른쪽으로 중앙에 있는 Sponsor, Watch, Fork, Starring 등의 버튼을 포함한 깃허브(GitHub) 저장소 페이지의 오른쪽 상단을 잘라낸 스크린샷](images/github-repo-metrics.png) +![Cropped screenshot of the top right corner of a GitHub repository page showing a series of buttons in the center from left to right: Sponsor, Watch, Fork, Starred.](images/github-repo-metrics.png) -저장소 보기를 활성화하면, 새 이슈, 풀 요청, 사용자 핸들에 대한 언급 및 저장소에서 구독한 다른 활동과 같은 이벤트가 [알림 페이지](https://github.com/notifications)에 알림으로 전송되며, 이메일의 받은 편지함과 비슷하게 _읽음_, _삭제됨_ 으로 표시될 수 있습니다. +저장소 보기를 활성화하면, 새 이슈, 풀 리퀘스트, 사용자 핸들에 대한 언급 및 저장소에서 구독한 다른 활동과 같은 이벤트가 [알림 페이지](https://github.com/notifications)에 알림으로 전송되며, 이메일의 받은 편지함과 비슷하게 _읽음_, _삭제됨_ 으로 표시될 수 있습니다. 경우에 따라 보기가 활성화된 저장소에 대한 이메일을 GitHub로부터 수신할 수도 있으며, [알림 설정 페이지](https://github.com/settings/notifications)에서 (아예 구독 취소하는 것을 포함한) 사용자 설정을 할 수 있습니다. -작업 방식에 맞게 이를 설정하고 싶다면, 검토할 관련 이슈 및 PR을 수동으로 찾아야 하는 귀찮음과, 깃허브의 끝없는 알림 속에서의 압도 사이에서 어떤 것을 선택할 것인지에 대한 기로에 서 있게 됩니다. 여기에는 균형 잡힌 선택이 필요한데, 만약 처음이라면 스튜어드는 **이슈**와 **풀 요청**에 대해 이 저장소에 **보기**를 활성화하고, "참여, @멘션 및 사용자 정의"에 대한 이메일만 수신하도록 설정하는 것을 추천합니다. +작업 방식에 맞는 알림 방식을 선택하는 과정에서, 여러분은 이슈 및 PR 검토 사안을 직접 찾아내야 하는 귀찮음과, 깃허브의 끝없는 알림 압박 사이의 선택지에 서 있게 됩니다. 여기에는 균형 잡힌 선택이 필요한데, 만약 처음이라면 스튜어드는 **이슈**와 **풀 리퀘스트**에 대해 이 저장소에 **보기**를 활성화하고, "참여, @멘션 및 사용자 정의"에 대한 이메일만 수신하도록 설정하는 것을 추천합니다. From 70bcce79b558bd93643d8770623836c14e97d51b Mon Sep 17 00:00:00 2001 From: Orwiss <7181108+Orwiss@users.noreply.github.com> Date: Tue, 19 Mar 2024 15:19:54 +0900 Subject: [PATCH 07/12] Update [p5.js KO] steward_guidelines.md Sunghun upload more --- .../ko/[p5.js KO] steward_guidelines.md | 52 +++++++++---------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/contributor_docs/ko/[p5.js KO] steward_guidelines.md b/contributor_docs/ko/[p5.js KO] steward_guidelines.md index c1145b09b4..5f360948b9 100644 --- a/contributor_docs/ko/[p5.js KO] steward_guidelines.md +++ b/contributor_docs/ko/[p5.js KO] steward_guidelines.md @@ -22,7 +22,7 @@ - [팁과 요령](steward_guidelines.md#tips--tricks) - [회신(Reply) 양식](steward_guidelines.md#reply-templates) - [깃허브 CLI](steward_guidelines.md#github-cli) - - [알림 관](steward_guidelines.md#managing-notifications) + - [알림 관리](steward_guidelines.md#managing-notifications) --- @@ -115,7 +115,7 @@ p5.js 리포지토리(repository)에 대한 대부분의 코드 기여는 풀 ### 간단한 수정 -약간의 오타 수정 같은 간단한 수정은 병합(merge) 권한이 있는 누구나 직접 병합할 수 있습니다. PR “Files Changed” 탭에서 자동화된 CI 테스트를 통과하는지 확인하세요. +약간의 오타 수정 같은 간단한 수정은 병합(merge) 권한이 있는 누구나 직접 병합할 수 있습니다. PR “Files Changed” 탭에서 자동 CI 테스트를 통과하는지 확인하세요. ![The "files changed" tab when viewing a pull request on GitHub](images/files-changed.png) @@ -154,55 +154,55 @@ p5.js 리포지토리(repository)에 대한 대부분의 코드 기여는 풀 `@all-contributors` `please` `add` `@[GitHub` `handle]` `for` `[contribution` `type]` -### New feature/feature enhancement +### 새로운 기능/기능 향상 -The process for new feature or feature enhancement PR is similar to bug fixes with just one notable difference: +새로운 기능 또는 기능 향상 PR의 과정은 버그 수정과 비슷하지만 한 가지 주목해야 할 차이점이 있습니다: -- A new feature/feature enhancement PR must be reviewed and approved by at least two stewards or maintainers before it can be merged. +- 새로운 기능/기능 향상 PR은 병합(merge)되기 전에 적어도 두 명의 스튜어드(Stewards) 또는 유지 관리자(Maintainers)의 검토와 승인을 받아야 합니다. -### Dependabot +### 디펜다봇(Dependabot) -Dependabot PRs are usually only visible to repo admins so if this does not apply to you, please skip this section. +디펜다봇(Dependabot) PR은 보통 리포지토리(repo)의 관리자(admins)에게만 표시되므로 여러분에게 해당하지 않는다면 이 섹션(section)을 건너뛰어 주세요. -- Dependabot PRs can be merged directly if the version update is a [semver](https://semver.org/) patch version and the automated CI test has passed. -- Dependabot PRs with semver minor version changes can usually be merged directly as long as automated CI test passes. A quick check on the changelog of the updated dependency is recommended. -- Dependabot PRs with semver major version changes may likely affect either the build process or p5.js functionalities. The reviewer, in this case, is encouraged to review the changelog from the current version to the target version if possible and test the PR locally to ensure all processes are functioning and make any required changes due to potential breaking changes in the dependencies. - - Many dependencies bump major version numbers only because they drop official support for very old versions of Node.js. In many cases, major version changes don't necessarily mean breaking changes resulting from dependency API changes. +- [유의적 버전(semver)](https://semver.org/) 패치(patch) 버전 업데이트면서 자동 CI 테스트를 통과한 경우에 Dependabot PR은 바로 병합(merge)될 수 있습니다. +- 유의적 버전 마이너(minor) 버전 변경이 있는 디펜다봇 PR은 보통 자동 CI 테스트만 통과하면 바로 병합될 수 있습니다. 빠르게 업데이트된 종속성(dependency)의 변경 기록(changelog)을 확인하는 것이 좋습니다. +- 유의적 버전 메이저(major) 버전 변경이 있는 디펜다봇 PR은 빌드 과정이나 p5.js 기능에 영향을 줄 수 있습니다. 이 경우에 검토자(reviewer)는 가능하면 최신 버전부터 대상(target) 버전까지의 변경 기록을 검토하고, PR을 로컬 환경에서 테스트하여 모든 과정이 정상적으로 작동하는지 확인하고, 종속성의 잠재적인 호환되지 않는 변경 사항(breaking changes)으로 인해 필요한 변경 사항을 적용하는 것이 권장됩니다. + - 많은 종속성들이 Node.js의 매우 오래된 버전에 대해 공식 지원을 중단하게 되면서 주요 버전 번호를 올립니다. 많은 경우, 주요 버전 변경이 반드시 종속성 API 변경으로 인한 호환되지 않는 변경 사항을 의미하지는 않습니다. --- -## Build process +## 빌드 과정 -This section will not cover the general build setup nor commands but rather details about what's happening behind the scenes. Please see the [contributor’s guidelines](contributor_guidelines.md#working-on-p5js-codebase) for more detailed build info. +이 섹션(section)에서는 일반적인 빌드 설정이나 명령어는 다루지 않고, 대신 뒤에서 무슨 일이 일어나고 있는지 자세히 설명합니다. -The Gruntfile.js file contains the main build definitions for p5.js. Among the different tools used to build the library and documentation includes but not limited to Grunt, Browserify, YUIDoc, ESLint, Babel, Uglify, and Mocha. It may be helpful for us to start with the `default` task and work backward from there. It may be helpful at this point to open up the Gruntfile.js document while going through the explainer below. +Gruntfile.js 파일에는 p5.js에 대한 주요 빌드 정의들이 포함되어 있습니다. 라이브러리와 문서를 구축하는 데 사용된 다양한 도구 중에는 Grunt, Browserify, YUIDoc, ESLint, Babel, Uglify, Mocha가 포함되어 있지만 이게 다는 아닙니다. `default` 작업으로 시작하여 거기서부터 거꾸로 작업하는 것이 우리에게 도움될 수 있습니다. 이 시점에는 아래의 설명을 따라가며 Gruntfile.js를 열어보는 것이 도움될 수 있습니다. -### Main build task +### 주 빌드 작업 ``` grunt.registerTask('default', ['lint', 'test']); ``` -When we run `grunt` or the npm script `npm test`, we run the default task consisting of `lint` then `test`. +우리가 `grunt` 또는 npm 스크립트 `npm test`를 열었을 때, `lint`와 `test`로 구성된 기본 작업을 실행합니다. -#### `lint` Task +#### `lint` 작업 ``` grunt.registerTask('lint', ['lint:source', 'lint:samples']); ``` -The `lint` task consists of two sub tasks: `lint:source` and `lint:samples`. `lint:source` is further subdivided into three more sub tasks `eslint:build`, `eslint:source`, and `eslint:test`, which uses ESLint to check the build scripts, the source code, and the test scripts. +`lint` 작업은 두 가지 하위 작업으로 구성됩니다: `lint:source` 및 `lint:samples`. `lint:source` 는 다시 ESLint를 사용하여 빌드 스크립트(build script), 소스 코드, 테스트 스크립트(test script)를 확인하는 `eslint:build`, `eslint:source`, `eslint:test`의 세 가지 하위 작업으로 나뉩니다. -The `lint:samples` task will first run the `yui` task which itself consists of `yuidoc:prod`, `clean:reference`, and `minjson`, which extract the documentation from the source code into a JSON document, remove unused files from the previous step, and minify the generated JSON file into `data.min.json` respectively. +The `lint:samples` 작업은 우선 `yuidoc:prod`, `clean:reference`, `minjson`로 구성된 `yui` 작업을 실행하는데, 이 작업은 소스 코드에서 문서를 추출하여 이전 단계에서 사용되지 않은 파일을 제거하고 생성된 JSON 파일을 각각 `data.min.json` 로 최소화합니다. -Next in `lint:samples` is `eslint-samples:source`, which is a custom written task whose definition is in [./tasks/build/eslint-samples.js](tasks/build/eslint-samples.js); it will run ESLint to check the documentation example code to make sure they follow the same coding convention as the rest of p5.js (`yui` is run first here because we need the JSON file to be built first before we can lint the examples). +`lint:samples` 다음은 `eslint-samples:source`로, [./tasks/build/eslint-samples.js](notion://www.notion.so/cybergeist/tasks/build/eslint-samples.js)에 정의되어 있는 사용자 작성 작업입니다; 이는 문서 예제 코드가 p5.js의 나머지 부분와 동일한 코딩 규칙을 따르는지 확인하기 위해 ESLint를 실행할 것입니다 (예제를 린트(lint)하기 전에 JSON 파일을 빌드해야 하기 때문에 여기서 `yui`는 먼저 실행됩니다). -#### `test` Task +#### `test` 작업 ```js grunt.registerTask('test', [ @@ -214,7 +214,7 @@ grunt.registerTask('test', [ ]); ``` -First let's look at the `build` task under `test`. +먼저 `test` 아래의 `build` 작업을 살펴보겠습니다. ```js grunt.registerTask('build', [ @@ -225,11 +225,11 @@ grunt.registerTask('build', [ ]); ``` -Tasks that start with `browserify` are defined in [./tasks/build/browserify.js](tasks/build/browserify.js). They all  similar steps with minor differences. These are the main steps to build the full p5.js library from its many source code files into one: +`browserify`로 시작하는 작업들은 [./tasks/build/browserify.js](notion://www.notion.so/cybergeist/tasks/build/browserify.js)에 정의되어 있습니다. 이 작업들은 모두 약간의 차이가 있지만 비슷한 단계로 되어 있습니다. 다음은 많은 소스 코드 파일에서 전체 p5.js 라이브러리를 하나로 빌드하는 주요 단계입니다: -- `browserify` builds p5.js while `browserify:min` builds an intermediate file to be minified in the next step. The difference between `browserify` and `browserify:min` is that `browserify:min` does not contain data needed for FES to function. -- `uglify` takes the output file of `browserify:min` and minify it into the final p5.min.js (configuration of this step is in the main Gruntfile.js). -- `browserify:test` is building a version identical to the full p5.js except for added code that is used for test code coverage reporting (using [Istanbul](https://istanbul.js.org/)). +- `browserify`는 p5.js를 빌드하는 반면, `browserify:min`는 다음 단계에서 최소화할 중간 파일들을 빌드합니다. `browserify`와 `browserify:min`의 차이점은 `browserify:min`에는 FES가 작동하는 데 필요한 데이터가 포함되어 있지 않다는 것입니다. +- `uglify`는 `browserify:min` 의 출력 파일을 가져와 최종적으로 p5.min.js로 최소화합니다 (이 단계의 구성은 메인 Gruntfile.js에 있습니다). +- 테스트 코드 커버리지(code coverage) 보고를 위해 추가된 코드를 제외하고 `browserify:test`는 전체 p5.js와 동일한 버전으로 빌드하고 있습니다 ([Istanbul](https://istanbul.js.org/)을 사용합니다). First, use of the `fs.readFileSync()` node.js specific code is replaced with the file's actual content using `brfs-babel`. This is used mainly by WebGL code to inline shader code from source code written as separate files. From b7a1790e7d323af5ae3b4158ac2c5272776d3674 Mon Sep 17 00:00:00 2001 From: Orwiss <7181108+Orwiss@users.noreply.github.com> Date: Tue, 19 Mar 2024 15:20:17 +0900 Subject: [PATCH 08/12] Update [p5.js KO] steward_guidelines.md --- contributor_docs/ko/[p5.js KO] steward_guidelines.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributor_docs/ko/[p5.js KO] steward_guidelines.md b/contributor_docs/ko/[p5.js KO] steward_guidelines.md index 5f360948b9..0e897a5930 100644 --- a/contributor_docs/ko/[p5.js KO] steward_guidelines.md +++ b/contributor_docs/ko/[p5.js KO] steward_guidelines.md @@ -79,7 +79,7 @@ - 기존에 p5.js로 작성된 일반적인 스케치와 충돌할까요? - 위와 같이 충돌을 일으킬 수 있는 기능들은 호환되지 않는 변경 사항으로 간주됩니다. [주요 버전 배포](https://docs.npmjs.com/about-semantic-versioning)가 아니면 우리는 p5.js에 호환되지 않는 변경 사항을 만들지는 않습니다. - 제안된 새로운 기능이 이미 p5.js에 있는 기존 기능, 비교적 간단한 순수 자바스크립트 코드나 기존의 사용하기 쉬운 라이브러리를 사용하여 만들어질 수 있요? - - 예를 들어, `join(["Hello", "world!"])` 와 같은 문자열 배열에 p5.js 기능을 제공하는 것보다는 자바스크립트 기본 문법의 `["Hello", "world!"].join()` 가 우선되어야 합니다. + - 예를 들어, `join(["Hello", "world!"])`와 같은 문자열 배열에 p5.js 기능을 제공하는 것보다는 자바스크립트 기본 문법의 `["Hello", "world!"].join()`가 우선되어야 합니다. 3. 접근 요구 사항과 나머지 고려 사항이 충족된 경우, PR을 시작하기 전에 최소 2명의 스튜어드(Stewards) 또는 유지 관리자(Maintainers)가 새로운 기능 요청을 승인해야 합니다. 새로운 기능에 대한 PR 검토 과정은 아래에 설명되어 있습니다. From da9fa3807b36af297ec15722f52a13dcb92ba48f Mon Sep 17 00:00:00 2001 From: Orwiss <7181108+Orwiss@users.noreply.github.com> Date: Tue, 19 Mar 2024 22:22:19 +0900 Subject: [PATCH 09/12] Update [p5.js KO] steward_guidelines.md Sunghun Commit 1 --- .../ko/[p5.js KO] steward_guidelines.md | 34 +++++++++---------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/contributor_docs/ko/[p5.js KO] steward_guidelines.md b/contributor_docs/ko/[p5.js KO] steward_guidelines.md index 0e897a5930..5c5e32f1f6 100644 --- a/contributor_docs/ko/[p5.js KO] steward_guidelines.md +++ b/contributor_docs/ko/[p5.js KO] steward_guidelines.md @@ -29,7 +29,7 @@ ## 이슈(Issues) -우리는 대부분의 소스 코드 기여가 이슈(Issue)에서 시작하는 것을 권장하며, 따라서 이슈는 대부분의 논의가 이루어지는 곳입니다. 문제를 검토할 때 취해야 할 단계는 문제의 종류에 따라 달라집니다. 리포지토리(repo)는 다양한 유형의 문제를 더 잘 정리하고 문제 작성자가 문제에 대한 정보를 모두 제공하도록 권장하기 위해 [깃허브 이슈 템플릿(templates)](https://github.com/processing/p5.js/tree/main/.github/ISSUE_TEMPLATE)을 사용합니다. 문제를 검토하는 첫 번째 단계는 종종 입력된 템플릿을 살펴보고 추가 정보가 필요한지 여부를 결정하는 것입니다 (예: 일부 필드가 입력되지 않았거나 잘못된 템플릿이 사용되었을 경우). +우리는 대부분의 소스 코드 기여가 이슈(Issue)에서 시작하는 것을 권장하며, 따라서 이슈는 대부분의 논의가 이루어지는 곳입니다. 문제를 검토할 때 취해야 할 단계는 문제의 종류에 따라 달라집니다. 리포지토리(repo)는 다양한 유형의 문제를 더 잘 정리하고 문제 작성자가 문제에 대한 정보를 모두 제공하도록 권장하기 위해 [깃허브 이슈 템플릿(templates)](https://github.com/processing/p5.js/blob/main/.github/ISSUE_TEMPLATE)을 사용합니다. 문제를 검토하는 첫 번째 단계는 종종 입력된 템플릿을 살펴보고 추가 정보가 필요한지 여부를 결정하는 것입니다 (예: 일부 필드가 입력되지 않았거나 잘못된 템플릿이 사용되었을 경우). ### 버그 보고 @@ -43,9 +43,9 @@ - 그렇지 않으면 버그 보고서가 위치할 곳에 대한 답변을 (직접 연결되는 링크와 함께) 남기고 문제를 닫습니다. - 버그 보고를 검토하는 첫 번째 단계는 버그 복사를 위해 충분한 정보가 제공되는지 확인하고, 제공되는 경우에, 설명된 대로 버그 복제를 시도하는 것입니다. 2. 버그를 복사할 수 있는 경우: - - 특정 버그를 고치는 최선의 방법을 찾기 위해 약간의 논의가 필요할 수 있습니다. 때로는 간단할 수도 있고 때로는 까다로울 수도 있습니다. 사례별로 이러한 결정을 내릴 때는 [p5.js 디자인 원칙](notion://www.notion.so/cybergeist/design_principles.md)를 참조하세요. + - 특정 버그를 고치는 최선의 방법을 찾기 위해 약간의 논의가 필요할 수 있습니다. 때로는 간단할 수도 있고 때로는 까다로울 수도 있습니다. 사례별로 이러한 결정을 내릴 때는 [p5.js 디자인 원칙](design_principles.md)를 참조하세요. - 이슈 작성자가 수정에 기여할 의향이 있는 경우: - - Approve the issue for fixing by the issue author by leaving a comment and assigning them to the issue. “담당자(Assignee)” 우측에 있는 톱니바퀴 버튼을 사용하세요. + - 이슈 작성자가 코멘트를 남기 이슈에 할당하여 이슈 수정을 승인합니다. “담당자(Assignee)” 우측에 있는 톱니바퀴 버튼을 사용하세요. - 이슈 작성자가 수정에 기여하기 원하지 않는 경우: - 버그를 복사할 수 있는지 알 수 있는 댓글을 남깁니다. - 수정을 시도하거나 `help wanted` 레이블을 추가하여 수정이 필요한 문제를 표시합니다. @@ -57,7 +57,7 @@ - 버그는 종종 웹 에디터를 사용할 때만 발생하고 로컬에서 테스트할 때는 발생하지 않습니다. 이 경우 문제를 [웹 에디터 리포지토리(repo)](https://github.com/processing/p5.js-web-editor)로 리디렉션해야 합니다. - 나중에 복사가 가능하게 된 경우 2번로 다시 이동합니다. 4. p5.js의 동작이 아니라 사용자가 버그 보고서에 제공한 코드에서 버그가 발생한 경우: - - p5.js의 문서화, 코드 구현 또는 친근 오류 시스템(friendly error system)을 개선하여 동일한 오류가 발생하지 않도록 할 수 있는지 판단합니다. + - p5.js의 문서화, 코드 구현 또는 친근한 오류 시스템(friendly error system)을 개선하여 동일한 오류가 발생하지 않도록 할 수 있는지 판단합니다. - 추가 질문이 있으면 [포럼(forum)](https://discourse.processing.org/) 또는 [디스코드(Discord)](https://discord.com/invite/SHQ8dH25r9) 로 리디렉션하고 p5.js에 더 이상 변경사항이 없다면 문제를 종료하세요. @@ -65,14 +65,14 @@ 기능 요청은 "새로운 기능 요청" 이슈 템플릿(template)을 사용해야 합니다. 새로운 기능을 요청하기 위해서는 다음과 같은 과정이 일반적입니다: -1. 기능 요청은 p5.js의 접근성 향상을 위한 노력의 일환으로, 해당 분야에서 역사적으로 소외된 커뮤니티에서 p5.js의 접근성을 높이는 방법에 대한 사례가 되어야 합니다. 자세한 내용은 [이 곳](notion://www.notion.so/cybergeist/access.md)에서 볼 수 있습니다. +1. 기능 요청은 p5.js의 접근성 향상을 위한 노력의 일환으로, 해당 분야에서 역사적으로 소외된 커뮤니티에서 p5.js의 접근성을 높이는 방법에 대한 사례가 되어야 합니다. 자세한 내용은 [이 곳](access.md)에서 볼 수 있습니다. - 기능 요청에 "접근성 증가" 필드가 충분히 입력되지 않은 경우, 이슈 작성자에게 이 기능이 어떻게 접근성을 높이는지 질문할 수 있습니다. - 기능의 접근성은 이슈 검토자를 포함한 커뮤니티의 다른 구성원이 제공할 수 있습니다. 2. 새로운 기능 요청은 다음 기준에 따라 포함 여부를 평가할 수 있습니다. - 해당 기능이 p5.js의 프로젝트 범위와 [디자인 원칙](design_principles.md)에 적합한가요? - 예를 들어, 새로운 기본 도형을 추가하는 요청은 고려될 수 있지만, 브라우저 기반 IOT 프로토콜을 채택하기 위한 요청은 범위에서 벗어날 가능성이 높습니다. - 전체적으로, p5.js의 범위는 거의 사용되지 않는 기능으로부터 지나친 팽창을 피하기 위해 상대적으로 범위가 좁아야 합니다. - - 기능이 p5.js 범위에 맞지 않는 경우, 이슈 작성자가 기능을 애드온 라이브러리(addon library)로 만들도록 제안합니다. + - 기능이 p5.js의의 범위에 맞지 않는 경우, 이슈 작성자가 기능을 애드온 라이브러리(addon library)로 만들도록 제안합니다. - 범위에 맞는지 불분명한 경우, 개념 증명으로써 애드온 라이브러리를 만드는 것을 제안하는 것이 좋습니다. 이는 사용자에게 기능을 사용할 수 있는 방법을 제공하고, 쓰임새와 중요성에 대한 훨씬 더 구체적인 예시를 제공하며, 완전히 통합된 기능처럼 해결책이 완벽할 필요는 없습니다. 나중에 적합하다고 판단될 경우 p5.js 내에 통합될 수 있습니다. - 기능이 호환되지 않는 변경(breaking changes)의 원인이 될 수 있나요? - 기존 p5.js 함수 및 변수와 충돌이 발생할까요? @@ -88,7 +88,7 @@ 기능 향상 이슈는 "기존 기능 향상" 이슈 템플릿(template)을 사용해야 합니다. 이 과정은 새로운 기능 요청과 매우 비슷합니다. 가끔 새로운 기능 요청과 기능 향상의 차이가 명확하지 않을 수 있습니다. 기능 향상은 주로 p5.js의 기존 기능을 다루지만, 새로운 기능 요청은 완전히 새로운 기능을 추가하도록 요청할 수 있습니다. 1. 새로운 기능 요청과 마찬가지로 기능 향상은 p5.js에 대한 접근성을 높이는 경우에만 허용되어야 합니다. [위 섹션](http://guidelines.md#feature-request)의 1번 항목을 참고해주세요. -2. 기능 향상에 대한 포함? 기준은 기능 요청의 경우와 비슷하지만, 잠재적인 호환되지 않는 변경 사항(breaking changes)을 특히 주의해야 합니다. +2. 기능 향상에 대한 포함 기준은 기능 요청의 경우와 비슷하지만, 잠재적인 호환되지 않는 변경 사항(breaking changes)을 특히 주의해야 합니다. - 기존 기능을 수정하는 경우, 모든 이전의 유효하고 문서화된 함수 시그니처가 같은 방식으로 동작해야 합니다. 3. 기능 향상은 PR이 시작되기 전에 적어도 한 명의 스튜어드(Steward) 또는 유지보수자(Maintainer)의 승인을 받아야 합니다. 기능 향상을 위한 PR 검토 과정은 아래에 문서화되어 있습니다. @@ -97,7 +97,7 @@ 이 유형의 이슈는 최소한의 템플릿 ("토론")을 가지고 있으며 기능 요청과 같은 좀 더 구체적인 것으로 통합하기 전에 일반적으로 주제에 대한 피드백을 모으는 데에 사용되어야 합니다. 이런 종류의 토론 이슈는 대화가 끝나고 구체적인 문제가 생성되면 종료될 수 있습니다: - 이슈가 토론으로 열려 있다면 버그 보고 같은 것들은 올바른 레이블을 적용하고 “토론” 레이블을 없애야 합니다. 버그에 대한 추가 정보가 포함되지 않았다면 작성자에게 요청해야 합니다. -- 토론으로 이가 열렸지만 소스 코드 기여와 관련이 없거나 깃허브 리포지토리(repository)/기여 과정/기여 커뮤니티와 관련이 없는 경우 포럼(forum) 또는 디스코드(Discord)로 리디렉션하 문제를 닫아야 합니다. +- 토론으로 이가 열렸지만 소스 코드 기여와 관련이 없거나 깃허브 리포지토리(repository)/기여 과정/기여 커뮤니티와 관련이 없는 경우 포럼(forum) 또는 디스코드(Discord)로 리디렉션하고고 문제를 닫아야 합니다. - 관련이 있는 경우에는, 한 눈에 어떤 유형의 토론인지 알 수 있게 표시하기 위해 토론 이슈에 레이블을 추가해야 합니다. --- @@ -108,7 +108,7 @@ p5.js 리포지토리(repository)에 대한 대부분의 코드 기여는 풀 리퀘스트(pull request)를 통해 이루어집니다. 스튜어드(Stewards)와 유지보수자(Maintainers)는 리포지토리에 대한 푸시(push) 권한이 있지만 코드 기여 시에 똑같이 이슈 > PR > 검토 과정을 거치도록 권장합니다. PR을 검토하는 단계는 다음과 같습니다: - 풀 리퀘스트 템플릿(template)은 [이 곳](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md)에서 확인할 수 있습니다. -- 거의 모든 풀 리퀘스트는 먼저 관련 이슈를 열고 논의해야 합니다. 즉, 관련 [이슈 작업 절차(workflow)](notion://www.notion.so/cybergeist/steward_guidelines.md#issues)를 먼저 따른 뒤에 스튜어드나 유지 관리자가 검토해야 합니다. +- 거의 모든 풀 리퀘스트는 먼저 관련 이슈를 열고 논의해야 합니다. 즉, 관련 [이슈 작업 절차(workflow)](steward_guidelines.md#issues)를 먼저 따른 뒤에 스튜어드나 유지 관리자가 검토해야 합니다. - 절차가 적용되지 않는 유일한 경우는 매우 간단한 오타 수정 뿐이며, 이슈를 열 필요가 없고 특정 분야의 스튜어드가 아니더라도 리포지토리에 대한 병합(merge) 권한이 있는 모든 사람이 병합할 수 있습니다. - 이러한 예외가 존재하지만, 우리는 기여자들이 새로운 이슈를 먼저 열도록 권장될 때에만 예외를 적용할 것입니다. 즉, 예외가 적용될지 잘 모르겠다면 어쨌든 이슈를 열어보세요! - 풀 리퀘스트가 참조된 문제가 완전히 해결해 주지 않았다면, 원본 게시물(post)의 "Resolves #OOOO"를 "Addresses #OOOO"로 수정하여 PR 병합 시에 원본 이슈가 자동으로 닫히지 않게끔 할 수 있습니다. @@ -125,8 +125,8 @@ p5.js 리포지토리(repository)에 대한 대부분의 코드 기여는 풀 ### 버그 수정 1. 버그 수정은 관련 분야의 스튜어드(Steward)가 해야 합니다. 이상적으로는 참조된 이슈를 수정하도록 승인한 것과 같습니다. -2. PR "Files Changed" 탭을 이슈 토론(discussion)에 설명된 대로 수정이 되었는지 최초로 검토하는 데에 사용할 수 있습니다. -3. PR은 가능하고 적절하다면 로컬에서 테스트해야 합니다. GitHub CLI는 일부 과정을 간소화하는 데에 도움이 될 수 있습니다 (더 많은 내용은 아래의 [팁과 요령](notion://www.notion.so/cybergeist/steward_guidelines.md#tips-tricks)에 있습니다). +2. PR "변경된 파일(Files Changed)" 탭을 이슈 토론(discussion)에 설명된 대로 수정이 되었는지 최초로 검토하는 데에 사용할 수 있습니다. +3. PR은 가능하고 적절하다면 로컬에서 테스트해야 합니다. GitHub CLI는 일부 과정을 간소화하는 데에 도움이 될 수 있습니다 (더 많은 내용은 아래의 [팁과 요령](steward_guidelines.md#tips-tricks)에 있습니다). - [ ] 수정은 원래의 이슈를 충분히 해결해야 합니다. - [ ] 수정은 원래의 이슈에서 합의되지 않는 한 기존 동작을 변경해서는 안됩니다. - [ ] 수정은 p5.js의 성능에 큰 영향을 주지 않아야 합니다. @@ -199,7 +199,7 @@ grunt.registerTask('lint', ['lint:source', 'lint:samples']); The `lint:samples` 작업은 우선 `yuidoc:prod`, `clean:reference`, `minjson`로 구성된 `yui` 작업을 실행하는데, 이 작업은 소스 코드에서 문서를 추출하여 이전 단계에서 사용되지 않은 파일을 제거하고 생성된 JSON 파일을 각각 `data.min.json` 로 최소화합니다. -`lint:samples` 다음은 `eslint-samples:source`로, [./tasks/build/eslint-samples.js](notion://www.notion.so/cybergeist/tasks/build/eslint-samples.js)에 정의되어 있는 사용자 작성 작업입니다; 이는 문서 예제 코드가 p5.js의 나머지 부분와 동일한 코딩 규칙을 따르는지 확인하기 위해 ESLint를 실행할 것입니다 (예제를 린트(lint)하기 전에 JSON 파일을 빌드해야 하기 때문에 여기서 `yui`는 먼저 실행됩니다). +`lint:samples` 다음은 `eslint-samples:source`로, [./tasks/build/eslint-samples.js](tasks/build/eslint-samples.js)에 정의되어 있는 사용자 작성 작업입니다; 이는 문서 예제 코드가 p5.js의 나머지 부분와 동일한 코딩 규칙을 따르는지 확인하기 위해 ESLint를 실행할 것입니다 (예제를 린트(lint)하기 전에 JSON 파일을 빌드해야 하기 때문에 여기서 `yui`는 먼저 실행됩니다). #### `test` 작업 @@ -225,19 +225,19 @@ grunt.registerTask('build', [ ]); ``` -`browserify`로 시작하는 작업들은 [./tasks/build/browserify.js](notion://www.notion.so/cybergeist/tasks/build/browserify.js)에 정의되어 있습니다. 이 작업들은 모두 약간의 차이가 있지만 비슷한 단계로 되어 있습니다. 다음은 많은 소스 코드 파일에서 전체 p5.js 라이브러리를 하나로 빌드하는 주요 단계입니다: +`browserify`로 시작하는 작업들은 [./tasks/build/browserify.js](tasks/build/browserify.js)에 정의되어 있습니다. 이 작업들은 모두 약간의 차이가 있지만 비슷한 단계로 되어 있습니다. 다음은 많은 소스 코드 파일에서 전체 p5.js 라이브러리를 하나로 빌드하는 주요 단계입니다: - `browserify`는 p5.js를 빌드하는 반면, `browserify:min`는 다음 단계에서 최소화할 중간 파일들을 빌드합니다. `browserify`와 `browserify:min`의 차이점은 `browserify:min`에는 FES가 작동하는 데 필요한 데이터가 포함되어 있지 않다는 것입니다. - `uglify`는 `browserify:min` 의 출력 파일을 가져와 최종적으로 p5.min.js로 최소화합니다 (이 단계의 구성은 메인 Gruntfile.js에 있습니다). - 테스트 코드 커버리지(code coverage) 보고를 위해 추가된 코드를 제외하고 `browserify:test`는 전체 p5.js와 동일한 버전으로 빌드하고 있습니다 ([Istanbul](https://istanbul.js.org/)을 사용합니다). -First, use of the `fs.readFileSync()` node.js specific code is replaced with the file's actual content using `brfs-babel`. This is used mainly by WebGL code to inline shader code from source code written as separate files. +먼저, `fs.readFileSync()` node.js 전용 코드의 사용은 `brfs-babel`을 사용하여 파일의 실제 내용으로 대체됩니다. 이는 WebGL 코드에서 별도의 파일로 작성된 소스 코드로부터 셰이더(shader) 코드를 삽입(inline)하기 위해 사용됩니다. -Next, the source code, including all dependencies from node\_modules, is transpiled using Babel to match the [Browserslist](https://browsersl.ist/) requirement defined in package.json as well as to make the ES6 import statements into CommonJS `require()` that browserify understands. This also enables us to use newer syntax available in ES6 and beyond without worrying about browser compatibility. +다음으로, node_modules의 모든 종속성(dependency)을 포함한 소스 코드가 Babel을 사용하여 package.json에서 정의된 Browserslist 요구 사항에 맞춰 트랜스파일(transpile)하고, ES6 import문(import statement)을 browserify가 이해하는 CommonJS require()로 변환합니다. 이를 통해 브라우저 호환성에 대한 걱정 없이 ES6 이상에서 사용할 수 있는 최신 구문(syntax)을 사용할 수 있게 됩니다. -After bundling but before the bundled code is written to file, the code is passed through `pretty-fast`, if it is not meant to be minified, it should be cleaned up so the final formatting is a bit more consistent (we anticipate the p5.js source code can be read and inspected if desired). +번들링(bundling) 후, 번들링된 코드가 파일에 기록되기 전까지 코드는 `pretty-fast`를 통해 전달됩니다. 최소화할 것이 아니라면, 최종 포맷이 좀 더 일관되도록 정리되어야 합니다 (원하는 경우 p5.js 소스 코드를 읽고 검사할 수 있을 것으로 예상됩니다). -A few small detailed steps are left out here; you can check out the browserify build definition file linked above to have a closer look at everything. +이 곳에 몇 가지 세부 단계가 나와 있습니다; 위에 링크된 browserify 빌드 정의 파일을 확인하여 모든 내용을 자세히 확인할 수 있습니다. ``` connect:server From ff82ae0aec805e243c4a723dd4ecd39c2be61677 Mon Sep 17 00:00:00 2001 From: Orwiss <7181108+Orwiss@users.noreply.github.com> Date: Thu, 21 Mar 2024 08:20:05 +0900 Subject: [PATCH 10/12] Update [p5.js KO] steward_guidelines.md Sunghun 2nd --- .../ko/[p5.js KO] steward_guidelines.md | 134 +++++++++--------- 1 file changed, 67 insertions(+), 67 deletions(-) diff --git a/contributor_docs/ko/[p5.js KO] steward_guidelines.md b/contributor_docs/ko/[p5.js KO] steward_guidelines.md index 5c5e32f1f6..ae2ad9a3c3 100644 --- a/contributor_docs/ko/[p5.js KO] steward_guidelines.md +++ b/contributor_docs/ko/[p5.js KO] steward_guidelines.md @@ -1,6 +1,6 @@ # 스튜어드(Steward) 지침 -방금 스튜어드(Steward)로 가입하셨든, p5.js의 경험 많은 유지 관리자(Maintainer)셨든, 그 사이 어딘가에 계시든, 이 안내서에는 p5.js에 효과적으로 기여하는 데 도움이 되는 정보는 물론 팁과 요령이 포함되어 있습니다. 여기에 작성된 대부분의 내용은 특별히 언급되지 않는 한 지침이며, 이는 여러분의 작업 흐름(workflow)에 맞게 여기에 표시된 관행들을 조정할 수 있음을 의미합니다. +방금 스튜어드(steward)로 참여하셨거나, p5.js의 숙련된 유지 관리자(maintainer)거나, 그 사이 어딘가에 있으시거나, 이 안내서에는 p5.js에 효과적으로 기여하는 데 도움이 되는 정보는 물론 팁과 요령이 포함되어 있습니다. 여기에 작성된 대부분의 내용은 달리 명시되지 않는 한 지침에 불과하므, 여기서 보여지는 절차들은 여러분의 작업 흐름에 맞게 조정할 수 있습니다. ## 목차 @@ -20,7 +20,7 @@ - [기타 작업](steward_guidelines.md#miscellaneous-tasks) - [배포 과정](steward_guidelines.md#release-process) - [팁과 요령](steward_guidelines.md#tips--tricks) - - [회신(Reply) 양식](steward_guidelines.md#reply-templates) + - [회신 템플릿 (Reply templates)](steward_guidelines.md#reply-templates) - [깃허브 CLI](steward_guidelines.md#github-cli) - [알림 관리](steward_guidelines.md#managing-notifications) @@ -34,88 +34,88 @@ ### 버그 보고 -버그 보고는 "버그 발견" 이슈 템플릿(template)을 사용해야 합니다. 버그 보고를 하기 위해서는 다음과 같은 과정이 일반적입니다: +버그 보고는 "버그 보고 (Found a bug)" 이슈 템플릿(template)을 사용해야 합니다. 버그 보고를 하기 위해서는 다음과 같은 과정이 일반적입니다: -1. 버그 복사 - - 템플릿의 목표는 검토자가 문제의 버그를 복사할 수 있도록 충분한 정보를 제공하는 것입니다. +1. 버그 재현 + - 템플릿의 목표는 검토자가 문제의 버그를 재현할 수 있도록 충분한 정보를 제공하는 것입니다. - 보고된 버그가 리포지토리(repo)와 관련이 없는 경우 (p5.js, p5.js 웹사이트 등): - - 액세스 권한이 있는 경우 해당 담당자에게 문제를 전송합니다. - - 그렇지 않으면 버그 보고서가 위치할 곳에 대한 답변을 (직접 연결되는 링크와 함께) 남기고 문제를 닫습니다. - - 버그 보고를 검토하는 첫 번째 단계는 버그 복사를 위해 충분한 정보가 제공되는지 확인하고, 제공되는 경우에, 설명된 대로 버그 복제를 시도하는 것입니다. -2. 버그를 복사할 수 있는 경우: + - 접근 권한이 있다면 연관 리포지토리로 문제를 전송합니다. + - 그렇지 않으면 버그 보고서가 위치할 곳에 대한 답변을 (직접 연결되는 링크와 함께) 남기고 이슈를 닫습니다. + - 버그 보고를 검토하는 첫 번째 단계는 버그 재현 위해 충분한 정보가 제공되는지 확인하고, 제공되는 경우에, 설명된 대로 버그 재현을 시도하는 것입니다. +2. 버그를 재현할 수 있는 경우: - 특정 버그를 고치는 최선의 방법을 찾기 위해 약간의 논의가 필요할 수 있습니다. 때로는 간단할 수도 있고 때로는 까다로울 수도 있습니다. 사례별로 이러한 결정을 내릴 때는 [p5.js 디자인 원칙](design_principles.md)를 참조하세요. - - 이슈 작성자가 수정에 기여할 의향이 있는 경우: + - 이슈 작성자가 버그 수정에 기여할 의향이 있는 경우: - 이슈 작성자가 코멘트를 남기 이슈에 할당하여 이슈 수정을 승인합니다. “담당자(Assignee)” 우측에 있는 톱니바퀴 버튼을 사용하세요. - - 이슈 작성자가 수정에 기여하기 원하지 않는 경우: - - 버그를 복사할 수 있는지 알 수 있는 댓글을 남깁니다. - - 수정을 시도하거나 `help wanted` 레이블을 추가하여 수정이 필요한 문제를 표시합니다. -3. 버그를 복사할 수 없는 경우: + - 이슈 작성자가 버그 수정에 기여하기 원하지 않는 경우: + - 버그를 재현 가능한지 알아볼 수 있는 댓글을 남깁니다. + - 문제를 직접 해결하려고 시도하거나, 해결이 필요한 문제임을 나타내기 위해 `help wanted` 라벨을 추가하여 수정이 필요한 문제를 표시합니다. +3. 버그를 재현할 수 없는 경우: - 템플릿(template)에 정보가 부족하다면 추가 정보를 요청합니다 (p5.js 버전, 브라우저 버전, OS 버전 등). - - 테스트 환경이 이슈의 내용과 다른 경우 (예: 다른 브라우저 또는 OS): - - 여러분의 특정 환경에서 복사할 수 없다는 의견을 남깁니다. - - 이슈에 `help wanted` 레이블을 추가하고 같은 설정을 가진 사람에게 버그 복사를 요청합니다. - - 버그는 종종 웹 에디터를 사용할 때만 발생하고 로컬에서 테스트할 때는 발생하지 않습니다. 이 경우 문제를 [웹 에디터 리포지토리(repo)](https://github.com/processing/p5.js-web-editor)로 리디렉션해야 합니다. - - 나중에 복사가 가능하게 된 경우 2번로 다시 이동합니다. + - 테스트 환경이 이슈에 보고된 환경과 다른 경우 (예: 다른 브라우저 또는 OS): + - 여러분의 특정 환경에서 버그를 재현할 수 없다는 의견을 남깁니다. + - 이슈에 `help wanted` 라벨을 추가하고 같은 설정을 가진 사람에게 버그 재현을 요청합니다. + - 버그는 종종 웹 에디터를 사용할 때만 발생하고 로컬에서 테스트할 때는 발생하지 않습니다. 이 경우 이슈를 [웹 에디터 리포지토리(repo)](https://github.com/processing/p5.js-web-editor)로 리디렉션해야 합니다. + - 나중에 버그 재현이 가능해 경우 2번로 다시 이동합니다. 4. p5.js의 동작이 아니라 사용자가 버그 보고서에 제공한 코드에서 버그가 발생한 경우: - p5.js의 문서화, 코드 구현 또는 친근한 오류 시스템(friendly error system)을 개선하여 동일한 오류가 발생하지 않도록 할 수 있는지 판단합니다. - - 추가 질문이 있으면 [포럼(forum)](https://discourse.processing.org/) 또는 [디스코드(Discord)](https://discord.com/invite/SHQ8dH25r9) 로 리디렉션하고 p5.js에 더 이상 변경사항이 없다면 문제를 종료하세요. + - 추가 질문이 있으면 [포럼(forum)](https://discourse.processing.org/) 또는 [디스코드(Discord)](https://discord.com/invite/SHQ8dH25r9) 로 리디렉션하고 p5.js에 더 이상 변경사항이 없다면 이슈를 종결(close)하세요. ### 기능 요청 -기능 요청은 "새로운 기능 요청" 이슈 템플릿(template)을 사용해야 합니다. 새로운 기능을 요청하기 위해서는 다음과 같은 과정이 일반적입니다: +기능 요청은 "새로운 기능 요청(New Feature Request)" 이슈 템플릿(template)을 사용해야 합니다. 새로운 기능을 요청하기 위해서는 다음과 같은 과정이 일반적입니다: -1. 기능 요청은 p5.js의 접근성 향상을 위한 노력의 일환으로, 해당 분야에서 역사적으로 소외된 커뮤니티에서 p5.js의 접근성을 높이는 방법에 대한 사례가 되어야 합니다. 자세한 내용은 [이 곳](access.md)에서 볼 수 있습니다. - - 기능 요청에 "접근성 증가" 필드가 충분히 입력되지 않은 경우, 이슈 작성자에게 이 기능이 어떻게 접근성을 높이는지 질문할 수 있습니다. - - 기능의 접근성은 이슈 검토자를 포함한 커뮤니티의 다른 구성원이 제공할 수 있습니다. +1. 기능 요청은 p5.js의 접근성 향상을 위한 노력의 일환으로, 해당 분야에서 역사적으로 소외된 커뮤니티에서 p5.js의 접근성을 높이는 방법에 대한 사례가 되어야 합니다. 자세한 내용은 [이 곳](access.md)에서 볼 수 있습니다. + - 기능 요청에 "접근성 향상(Increasing Access)" 필드가 충분히 입력되지 않은 경우, 이슈 작성자에게 이 기능이 어떻게 접근성을 높이는지 질문할 수 있습니다. + - 기능의 접근성 설명은 이슈 검토자를 포함한 커뮤니티의 다른 구성원이 제공할 수 있습니다. 2. 새로운 기능 요청은 다음 기준에 따라 포함 여부를 평가할 수 있습니다. - 해당 기능이 p5.js의 프로젝트 범위와 [디자인 원칙](design_principles.md)에 적합한가요? - - 예를 들어, 새로운 기본 도형을 추가하는 요청은 고려될 수 있지만, 브라우저 기반 IOT 프로토콜을 채택하기 위한 요청은 범위에서 벗어날 가능성이 높습니다. - - 전체적으로, p5.js의 범위는 거의 사용되지 않는 기능으로부터 지나친 팽창을 피하기 위해 상대적으로 범위가 좁아야 합니다. - - 기능이 p5.js의의 범위에 맞지 않는 경우, 이슈 작성자가 기능을 애드온 라이브러리(addon library)로 만들도록 제안합니다. - - 범위에 맞는지 불분명한 경우, 개념 증명으로써 애드온 라이브러리를 만드는 것을 제안하는 것이 좋습니다. 이는 사용자에게 기능을 사용할 수 있는 방법을 제공하고, 쓰임새와 중요성에 대한 훨씬 더 구체적인 예시를 제공하며, 완전히 통합된 기능처럼 해결책이 완벽할 필요는 없습니다. 나중에 적합하다고 판단될 경우 p5.js 내에 통합될 수 있습니다. - - 기능이 호환되지 않는 변경(breaking changes)의 원인이 될 수 있나요? - - 기존 p5.js 함수 및 변수와 충돌이 발생할까요? - - 기존에 p5.js로 작성된 일반적인 스케치와 충돌할까요? - - 위와 같이 충돌을 일으킬 수 있는 기능들은 호환되지 않는 변경 사항으로 간주됩니다. [주요 버전 배포](https://docs.npmjs.com/about-semantic-versioning)가 아니면 우리는 p5.js에 호환되지 않는 변경 사항을 만들지는 않습니다. - - 제안된 새로운 기능이 이미 p5.js에 있는 기존 기능, 비교적 간단한 순수 자바스크립트 코드나 기존의 사용하기 쉬운 라이브러리를 사용하여 만들어질 수 있요? - - 예를 들어, `join(["Hello", "world!"])`와 같은 문자열 배열에 p5.js 기능을 제공하는 것보다는 자바스크립트 기본 문법의 `["Hello", "world!"].join()`가 우선되어야 합니다. -3. 접근 요구 사항과 나머지 고려 사항이 충족된 경우, PR을 시작하기 전에 최소 2명의 스튜어드(Stewards) 또는 유지 관리자(Maintainers)가 새로운 기능 요청을 승인해야 합니다. 새로운 기능에 대한 PR 검토 과정은 아래에 설명되어 있습니다. + - 예를 들어, 새로운 기본 도형을 추가하는 요청은 고려될 수 있지만, 브라우저 기반 IOT 프로토콜 추가 요청은 고려 범위에서 벗어날 가능성이 높습니다. + - 전반적으로, p5.js의 프로젝트 범위는 드물게 사용되는 기능으로 인한 과도한 팽창을 피하기 위해 상대적으로 범위가 좁아야 합니다. + - 해당 기능이 p5.js의 프로젝트 범위에 맞지 않는 경우, 이슈 작성자가 기능을 애드온 라이브러리(addon library)로 만들도록 제안합니다. + - 범위에 맞는지 불분명한 경우, 개념 증명 차원에서 애드온 라이브러리(addon library)를 제안하는 것도 좋은 방법입니다. 이는 사용자에게 기능을 사용할 수 있는 방법을 제공하고, 쓰임새와 중요성에 대한 훨씬 더 구체적인 예시를 제공하며, 완전히 통합된 기능처럼 해결책이 완벽할 필요는 없습니다. 나중에 적합하다고 판단될 경우 p5.js 내에 통합될 수 있습니다. + - 해당 기능이 이전 버전과 호환성이 없는 변경(breaking changes)의 원인이 될 수 있나요? + - 기존 p5.js 함수 및 변수와 충돌이 발생하나요? + - 기존에 p5.js로 작성된 일반적인 스케치와 충돌하요? + - 위와 같이 충돌을 일으킬 수 있는 기능들은 이전 버전과 호환성이 없는 변경으로 간주됩니다. [주요 버전 배포](https://docs.npmjs.com/about-semantic-versioning)가 아니면 우리는 p5.js에 이전 버전과 호환성이 없는 변경을 만들지는 않습니다. + - 제안된 새로운 기능이 p5.js에 이미 있는 기능, 비교적 간단한 순수 자바스크립트 코드나 기존의 사용하기 쉬운 라이브러리를 사용하여 만들어질 수 있나요? + - 예를 들어, 문자열 배열을 연결하기 위해 p5.js 함수 `join(["Hello", "world!"])`보다는 자바스크립트 기본 문법인 `["Hello", "world!"].join()`가 우선시됩니다. +3. 접근성 요구 사항과 나머지 고려 사항이 충족된 경우, PR을 시작하기 전에 최소 2명의 스튜어드(steward) 또는 유지 관리자(maintainer)가 새로운 기능 요청을 승인해야 합니다. 새로운 기능에 대한 PR 검토 과정은 아래에 설명되어 있습니다. ### 기능 향상 -기능 향상 이슈는 "기존 기능 향상" 이슈 템플릿(template)을 사용해야 합니다. 이 과정은 새로운 기능 요청과 매우 비슷합니다. 가끔 새로운 기능 요청과 기능 향상의 차이가 명확하지 않을 수 있습니다. 기능 향상은 주로 p5.js의 기존 기능을 다루지만, 새로운 기능 요청은 완전히 새로운 기능을 추가하도록 요청할 수 있습니다. +기능 향상 이슈는 "기존 기능 향상(Existing Feature Enhancement)" 이슈 템플릿(template)을 사용해야 합니다. 이 과정은 새로운 기능 요청과 매우 비슷합니다. 가끔 새로운 기능 요청과 기능 향상의 차이가 명확하지 않을 수 있습니다. 기능 향상은 주로 p5.js의 기존 기능을 다루지만, 새로운 기능 요청은 완전히 새로운 기능을 추가하도록 요청할 수 있습니다. -1. 새로운 기능 요청과 마찬가지로 기능 향상은 p5.js에 대한 접근성을 높이는 경우에만 허용되어야 합니다. [위 섹션](http://guidelines.md#feature-request)의 1번 항목을 참고해주세요. -2. 기능 향상에 대한 포함 기준은 기능 요청의 경우와 비슷하지만, 잠재적인 호환되지 않는 변경 사항(breaking changes)을 특히 주의해야 합니다. - - 기존 기능을 수정하는 경우, 모든 이전의 유효하고 문서화된 함수 시그니처가 같은 방식으로 동작해야 합니다. -3. 기능 향상은 PR이 시작되기 전에 적어도 한 명의 스튜어드(Steward) 또는 유지보수자(Maintainer)의 승인을 받아야 합니다. 기능 향상을 위한 PR 검토 과정은 아래에 문서화되어 있습니다. +1. 새로운 기능 요청과 마찬가지로 기능 향상은 p5.js에 대한 접근성을 높이는 경우에만 허용됩니다. [위 섹션](http://guidelines.md#feature-request)의 1번 항목을 참고해주세요. +2. 기능 향상에 대한 포함 기준은 기능 요청의 경우와 비슷하지만, 잠재적으로 이전 버전과 호환성이 없는 변경(breaking changes)을 특히 주의해야 합니다. + - 기존 함수를 수정하는 경우, 모든 이전의 유효하고 문서화된 함수 시그니처(function signature, 함수의 원형에 명시되는 매개변수 리스트)가 같은 방식으로 동작해야 합니다. +3. 기능 향상은 PR이 시작되기 전에 적어도 한 명의 스튜어드(steward) 또는 유지보수자(maintainer)의 승인을 받아야 합니다. 기능 향상을 위한 PR 검토 과정은 아래에 문서화되어 있습니다. ### 토론(Discussion) -이 유형의 이슈는 최소한의 템플릿 ("토론")을 가지고 있으며 기능 요청과 같은 좀 더 구체적인 것으로 통합하기 전에 일반적으로 주제에 대한 피드백을 모으는 데에 사용되어야 합니다. 이런 종류의 토론 이슈는 대화가 끝나고 구체적인 문제가 생성되면 종료될 수 있습니다: +매우 간단한 템플릿 "토론(Discussion)"을 가지고 있으며 기능 요청과 같은 좀 더 구체적인 것으로 통합하기 전에 일반적으로 주제에 대한 피드백을 모으는 데에 사용되어야 합니다. 이런 종류의 토론 이슈는 대화가 끝나고 구체적인 문제가 생성되면 종료될 수 있습니다: -- 이슈가 토론으로 열려 있다면 버그 보고 같은 것들은 올바른 레이블을 적용하고 “토론” 레이블을 없애야 합니다. 버그에 대한 추가 정보가 포함되지 않았다면 작성자에게 요청해야 합니다. +- 이슈가 토론으로 열려 있다면 버그 보고 같은 것들은 올바른 라벨을 적용하고 “토론” 라벨을 없애야 합니다. 버그에 대한 추가 정보가 포함되지 않았다면 작성자에게 요청해야 합니다. - 토론으로 이가 열렸지만 소스 코드 기여와 관련이 없거나 깃허브 리포지토리(repository)/기여 과정/기여 커뮤니티와 관련이 없는 경우 포럼(forum) 또는 디스코드(Discord)로 리디렉션하고고 문제를 닫아야 합니다. -- 관련이 있는 경우에는, 한 눈에 어떤 유형의 토론인지 알 수 있게 표시하기 위해 토론 이슈에 레이블을 추가해야 합니다. +- 관련이 있는 경우에는, 한 눈에 어떤 유형의 토론인지 알 수 있게 표시하기 위해 토론 이슈에 라벨을 추가해야 합니다. --- ## 풀 리퀘스트(Pull Requests) -p5.js 리포지토리(repository)에 대한 대부분의 코드 기여는 풀 리퀘스트(pull request)를 통해 이루어집니다. 스튜어드(Stewards)와 유지보수자(Maintainers)는 리포지토리에 대한 푸시(push) 권한이 있지만 코드 기여 시에 똑같이 이슈 > PR > 검토 과정을 거치도록 권장합니다. PR을 검토하는 단계는 다음과 같습니다: +p5.js 리포지토리(repository)에 대한 대부분의 코드 기여는 풀 리퀘스트(pull request)를 통해 이루어집니다. 스튜어드(steward)와 유지 관리자(maintainer)는 리포지토리에 대한 푸시(push) 권한이 있지만 코드 기여 시 똑같이 이슈 > PR > 검토 과정을 거치도록 권장합니다. PR을 검토하는 단계는 다음과 같습니다: -- 풀 리퀘스트 템플릿(template)은 [이 곳](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md)에서 확인할 수 있습니다. +- 풀 리퀘스트 템플릿은 [이 곳](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md)에서 확인할 수 있습니다. - 거의 모든 풀 리퀘스트는 먼저 관련 이슈를 열고 논의해야 합니다. 즉, 관련 [이슈 작업 절차(workflow)](steward_guidelines.md#issues)를 먼저 따른 뒤에 스튜어드나 유지 관리자가 검토해야 합니다. - 절차가 적용되지 않는 유일한 경우는 매우 간단한 오타 수정 뿐이며, 이슈를 열 필요가 없고 특정 분야의 스튜어드가 아니더라도 리포지토리에 대한 병합(merge) 권한이 있는 모든 사람이 병합할 수 있습니다. - - 이러한 예외가 존재하지만, 우리는 기여자들이 새로운 이슈를 먼저 열도록 권장될 때에만 예외를 적용할 것입니다. 즉, 예외가 적용될지 잘 모르겠다면 어쨌든 이슈를 열어보세요! -- 풀 리퀘스트가 참조된 문제가 완전히 해결해 주지 않았다면, 원본 게시물(post)의 "Resolves #OOOO"를 "Addresses #OOOO"로 수정하여 PR 병합 시에 원본 이슈가 자동으로 닫히지 않게끔 할 수 있습니다. + - 이러한 예외가 존재하지만, 우리는 기여자들이 새로운 이슈를 먼저 열도록 권장합니다. 즉, 예외가 적용될지 잘 모르겠다면 어쨌든 이슈를 열어보세요! +- 제시된 이슈가 풀 리퀘스트를 통해 완전히 해결되지 않았다면, 원본 게시물(post)의 "Resolves #OOOO"를 "Addresses #OOOO"로 수정하여 PR 병합 시에 원본 이슈가 자동으로 닫히지 않게끔 할 수 있습니다. ### 간단한 수정 -약간의 오타 수정 같은 간단한 수정은 병합(merge) 권한이 있는 누구나 직접 병합할 수 있습니다. PR “Files Changed” 탭에서 자동 CI 테스트를 통과하는지 확인하세요. +약간의 오타 수정 같은 간단한 수정은 병합(merge) 권한이 있는 누구나 직접 병합할 수 있습니다. PR의 “변경된 파일(Files Changed)” 탭에서 자동 지속적 통합(Continuous Integration, CI) 테스트를 통과하는지 확인하세요. ![The "files changed" tab when viewing a pull request on GitHub](images/files-changed.png) @@ -124,8 +124,8 @@ p5.js 리포지토리(repository)에 대한 대부분의 코드 기여는 풀 ### 버그 수정 -1. 버그 수정은 관련 분야의 스튜어드(Steward)가 해야 합니다. 이상적으로는 참조된 이슈를 수정하도록 승인한 것과 같습니다. -2. PR "변경된 파일(Files Changed)" 탭을 이슈 토론(discussion)에 설명된 대로 수정이 되었는지 최초로 검토하는 데에 사용할 수 있습니다. +1. 버그 수정은 관련 분야의 스튜어드(steward)에 의해 검토되어야 하며, 이상적으로는 해당 이슈의 수정을 승인한 동일한 사람이 이를 수행해야 합니다. +2. PR의 "변경된 파일(Files Changed)" 탭을 이슈 토론(discussion)에 설명된 대로 수정이 되었는지 최초로 검토하는 데에 사용할 수 있습니다. 3. PR은 가능하고 적절하다면 로컬에서 테스트해야 합니다. GitHub CLI는 일부 과정을 간소화하는 데에 도움이 될 수 있습니다 (더 많은 내용은 아래의 [팁과 요령](steward_guidelines.md#tips-tricks)에 있습니다). - [ ] 수정은 원래의 이슈를 충분히 해결해야 합니다. - [ ] 수정은 원래의 이슈에서 합의되지 않는 한 기존 동작을 변경해서는 안됩니다. @@ -133,17 +133,17 @@ p5.js 리포지토리(repository)에 대한 대부분의 코드 기여는 풀 - [ ] 수정은 p5.js의 접근성에 어떤 영향도 주지 않아야 합니다. - [ ] 수정은 최신 표준 자바스크립트 코딩을 사용해야 합니다. - [ ] 수정사항은 자동화된 테스트를 모두 통과해야 하고 관련 있는 경우에 새 테스트를 포함해야 합니다. -4. 추가 변경 사항이 필요한 경우, [이 곳](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request#adding-line-comments-to-a-pull-request)에 설명된 대로 해당 행에 행 주석(line comments)을 추가해야 합니다. - - 제안 블록(block)으로 특정 변경 사항을 제안할 수도 있습니다:\ +4. 추가 변경 사항이 필요한 경우, [이 곳](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request#adding-line-comments-to-a-pull-request)에 설명된 대로 해당 행에 줄별 주석(line comments)을 추가해야 합니다. + - 제안 블록(suggestion block)으로 특정 변경 사항을 제안할 수도 있습니다:\ ![The Suggest Change button while writing a comment on code in a GitHub pull request](images/suggest-change.png)\ ![A suggested change appearing within code fences with the "suggestion" tag](images/suggested-value-change.png)\ ![A suggested change previewed as a diff](images/suggestion-preview.png) - 여러 번 변경이 필요한 경우 한 줄 주석(single-line comments)을 여러 번 추가하지 마세요. 대신 문서화된 [이 곳](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)에 절차에 따라 여러 줄 주석(multiple-line comments)과 한 번의 요청으로 변경하세요. - - 행 주석(line comments)이 설명이나 토론을 위한 것이라면, “변경 요청(Request changes)” 대신 “답글(Comment)”을 선택해 주세요:\ + - 줄별 주석(line comments)이 설명이나 토론을 위한 것이라면, “변경 요청(Request changes)” 대신 “답글(Comment)”을 선택해 주세요:\ ![The "comment" option circled within the GitHub Finish Review menu](images/comment-review.png) -5. 한 번 PR이 검토되고 더 이상 변경이 필요하지 않으면 스튜어드(Steward)는 추가 댓글이 있든 없든 이전 단계에서 “승인(Approve)” 옵션을 선택하여 PR을 “승인(Approved)”으로 표시할 수 있습니다. 그런 다음 스튜어드는 원한다면 다른 스튜어드나 유지 관리자(Maintanier)에게 추가 검토를 요청할 수 있고, 병합(merge) 권한이 있다면 PR을 병합하거나 유지 관리자에게 병합을 요청할 수 있습니다. +5. 한 번 PR이 검토되고 더 이상 변경이 필요하지 않으면 스튜어드는 추가 댓글이 있든 없든 이전 단계에서 “승인(Approve)” 옵션을 선택하여 PR을 “승인(Approved)”으로 표시할 수 있습니다. 그런 다음 스튜어드는 원한다면 다른 스튜어드나 유지 관리자에게 추가 검토를 요청할 수 있고, 병합(merge) 권한이 있다면 PR을 병합하거나 유지 관리자에게 병합을 요청할 수 있습니다. -6. 새로운 기여자를 [README.md](http://readme.md/) 파일의 기여자 목록에 추가하려면 @[all-contributors](https://allcontributors.org/docs/en/emoji-key) 봇을 호출해야 합니다. 각각의 기여 유형은 아래의 `[contribution` `type]` 대신 표시할 수 있고, 사용할 수 있는 기여 유형의 전체 목록은 위 링크에서 확인할 수 있습니다. +6. 새로운 기여자를 [README.md](http://readme.md/) 파일의 기여자 목록에 추가하려면 @[all-contributors](https://allcontributors.org/docs/en/emoji-key) 봇을 호출해야 합니다. 각각의 기여 유형은 아래의 `[contribution` `type]`에 표시할 수 있고, 사용할 수 있는 기여 유형의 전체 목록은 위 링크에서 확인할 수 있습니다. ![images/suggest-change.png](images/suggest-change.png) @@ -156,37 +156,37 @@ p5.js 리포지토리(repository)에 대한 대부분의 코드 기여는 풀 ### 새로운 기능/기능 향상 -새로운 기능 또는 기능 향상 PR의 과정은 버그 수정과 비슷하지만 한 가지 주목해야 할 차이점이 있습니다: +새로운 기능 또는 기능 향상 PR은 버그 수정과 비슷하지만 한 가지 주목해야 할 차이점이 있습니다: -- 새로운 기능/기능 향상 PR은 병합(merge)되기 전에 적어도 두 명의 스튜어드(Stewards) 또는 유지 관리자(Maintainers)의 검토와 승인을 받아야 합니다. +- 새로운 기능/기능 향상 PR은 병합(merge)되기 전에 적어도 두 명의 스튜어드 또는 유지 관리자의 검토와 승인을 받아야 합니다. ### 디펜다봇(Dependabot) -디펜다봇(Dependabot) PR은 보통 리포지토리(repo)의 관리자(admins)에게만 표시되므로 여러분에게 해당하지 않는다면 이 섹션(section)을 건너뛰어 주세요. +디펜다봇(Dependabot) PR은 보통 리포지토리의 관리자(admins)에게만 표시되므로 여러분에게 해당하지 않는다면 이 섹션을 건너뛰어 주세요. - [유의적 버전(semver)](https://semver.org/) 패치(patch) 버전 업데이트면서 자동 CI 테스트를 통과한 경우에 Dependabot PR은 바로 병합(merge)될 수 있습니다. -- 유의적 버전 마이너(minor) 버전 변경이 있는 디펜다봇 PR은 보통 자동 CI 테스트만 통과하면 바로 병합될 수 있습니다. 빠르게 업데이트된 종속성(dependency)의 변경 기록(changelog)을 확인하는 것이 좋습니다. -- 유의적 버전 메이저(major) 버전 변경이 있는 디펜다봇 PR은 빌드 과정이나 p5.js 기능에 영향을 줄 수 있습니다. 이 경우에 검토자(reviewer)는 가능하면 최신 버전부터 대상(target) 버전까지의 변경 기록을 검토하고, PR을 로컬 환경에서 테스트하여 모든 과정이 정상적으로 작동하는지 확인하고, 종속성의 잠재적인 호환되지 않는 변경 사항(breaking changes)으로 인해 필요한 변경 사항을 적용하는 것이 권장됩니다. - - 많은 종속성들이 Node.js의 매우 오래된 버전에 대해 공식 지원을 중단하게 되면서 주요 버전 번호를 올립니다. 많은 경우, 주요 버전 변경이 반드시 종속성 API 변경으로 인한 호환되지 않는 변경 사항을 의미하지는 않습니다. +- 디펜다봇 PR이 유의적 버전의 경미한 변경 사항을 다루는 경우, 보통 자동 CI 테스트만 통과하면 바로 병합될 수 있습니다. 빠르게 업데이트된 종속성(dependency)의 변경 기록(changelog)을 확인하는 것이 좋습니다. +- 디펜다봇 PR이 유의적 버전의 주요 변경 사항을 다루는 경우, 빌드 과정이나 p5.js 기능에 영향을 줄 수 있습니다. 이 경우에 검토자(reviewer)는 가능하면 최신 버전부터 대상 버전까지의 변경 기록을 검토하고, PR을 로컬 환경에서 테스트하여 모든 과정이 정상적으로 작동하는지 확인합니다. 그리고 종속성 비호환 발생 대비에 필요한 모든 변경 사항을 제출합니다. + - Node.js는 매우 오래된 버전에 대한 공식 지원을 중단하기 때문에, 꽤나 많은 종속성이 주요 버전과 충돌합니다. 주요 버전 변경이 반드시 종속성 API 변경으로 인한 것은 아닙니다. --- ## 빌드 과정 -이 섹션(section)에서는 일반적인 빌드 설정이나 명령어는 다루지 않고, 대신 뒤에서 무슨 일이 일어나고 있는지 자세히 설명합니다. +이 섹션에서는 일반적인 빌드 설정이나 명령어는 다루지 않고, 대신 뒤에서 무슨 일이 일어나고 있는지 자세히 설명합니다. Gruntfile.js 파일에는 p5.js에 대한 주요 빌드 정의들이 포함되어 있습니다. 라이브러리와 문서를 구축하는 데 사용된 다양한 도구 중에는 Grunt, Browserify, YUIDoc, ESLint, Babel, Uglify, Mocha가 포함되어 있지만 이게 다는 아닙니다. `default` 작업으로 시작하여 거기서부터 거꾸로 작업하는 것이 우리에게 도움될 수 있습니다. 이 시점에는 아래의 설명을 따라가며 Gruntfile.js를 열어보는 것이 도움될 수 있습니다. -### 주 빌드 작업 +### 주요 빌드 작업 ``` grunt.registerTask('default', ['lint', 'test']); ``` -우리가 `grunt` 또는 npm 스크립트 `npm test`를 열었을 때, `lint`와 `test`로 구성된 기본 작업을 실행합니다. +`grunt` 또는 npm 스크립트 `npm test`를 열었을 때, `lint`와 `test`로 구성된 기본 작업이 실행됩니다. #### `lint` 작업 @@ -195,9 +195,9 @@ grunt.registerTask('default', ['lint', 'test']); grunt.registerTask('lint', ['lint:source', 'lint:samples']); ``` -`lint` 작업은 두 가지 하위 작업으로 구성됩니다: `lint:source` 및 `lint:samples`. `lint:source` 는 다시 ESLint를 사용하여 빌드 스크립트(build script), 소스 코드, 테스트 스크립트(test script)를 확인하는 `eslint:build`, `eslint:source`, `eslint:test`의 세 가지 하위 작업으로 나뉩니다. +`lint` 작업은 두 가지 하위 작업으로 구성됩니다: `lint:source` 및 `lint:samples`. `lint:source` 는 다시 ESLint를 사용하여 빌드 스크립트, 소스 코드, 테스트 스크립트를 확인하는 `eslint:build`, `eslint:source`, `eslint:test`의 세 가지 하위 작업으로 나뉩니다. -The `lint:samples` 작업은 우선 `yuidoc:prod`, `clean:reference`, `minjson`로 구성된 `yui` 작업을 실행하는데, 이 작업은 소스 코드에서 문서를 추출하여 이전 단계에서 사용되지 않은 파일을 제거하고 생성된 JSON 파일을 각각 `data.min.json` 로 최소화합니다. +`lint:samples` 작업은 우선 `yuidoc:prod`, `clean:reference`, `minjson`로 구성된 `yui` 작업을 실행합니다. 이는 소스 코드로부터 문서를 추출하여 JSON 문서로 변환합니다. 또, 이전 단계에서 사용되지 않은 파일을 제거하며, 생성된 JSON 파일을 각각 `data.min.json` 로 최소화합니다. `lint:samples` 다음은 `eslint-samples:source`로, [./tasks/build/eslint-samples.js](tasks/build/eslint-samples.js)에 정의되어 있는 사용자 작성 작업입니다; 이는 문서 예제 코드가 p5.js의 나머지 부분와 동일한 코딩 규칙을 따르는지 확인하기 위해 ESLint를 실행할 것입니다 (예제를 린트(lint)하기 전에 JSON 파일을 빌드해야 하기 때문에 여기서 `yui`는 먼저 실행됩니다). @@ -229,7 +229,7 @@ grunt.registerTask('build', [ - `browserify`는 p5.js를 빌드하는 반면, `browserify:min`는 다음 단계에서 최소화할 중간 파일들을 빌드합니다. `browserify`와 `browserify:min`의 차이점은 `browserify:min`에는 FES가 작동하는 데 필요한 데이터가 포함되어 있지 않다는 것입니다. - `uglify`는 `browserify:min` 의 출력 파일을 가져와 최종적으로 p5.min.js로 최소화합니다 (이 단계의 구성은 메인 Gruntfile.js에 있습니다). -- 테스트 코드 커버리지(code coverage) 보고를 위해 추가된 코드를 제외하고 `browserify:test`는 전체 p5.js와 동일한 버전으로 빌드하고 있습니다 ([Istanbul](https://istanbul.js.org/)을 사용합니다). +- `browserify:test`는 [Istanbul](https://istanbul.js.org/)을 사용하여 전체 p5.js와 동일한 버전으로 빌드됩니다. 단, 테스트 코드 커버리지(test code coverage) 보고를 위해 추가된 코드를 제외하고 빌드됩니다. 먼저, `fs.readFileSync()` node.js 전용 코드의 사용은 `brfs-babel`을 사용하여 파일의 실제 내용으로 대체됩니다. 이는 WebGL 코드에서 별도의 파일로 작성된 소스 코드로부터 셰이더(shader) 코드를 삽입(inline)하기 위해 사용됩니다. From 9537e18ee57f1241f4fd1717dcae29cc00cb743c Mon Sep 17 00:00:00 2001 From: Inhwa <51147158+yinhwa@users.noreply.github.com> Date: Thu, 21 Mar 2024 11:13:09 +0900 Subject: [PATCH 11/12] pre-finalize [p5.js KO] steward_guidelines.md minor grammar changes --- .../ko/[p5.js KO] steward_guidelines.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/contributor_docs/ko/[p5.js KO] steward_guidelines.md b/contributor_docs/ko/[p5.js KO] steward_guidelines.md index ae2ad9a3c3..171b668cf5 100644 --- a/contributor_docs/ko/[p5.js KO] steward_guidelines.md +++ b/contributor_docs/ko/[p5.js KO] steward_guidelines.md @@ -1,6 +1,6 @@ # 스튜어드(Steward) 지침 -방금 스튜어드(steward)로 참여하셨거나, p5.js의 숙련된 유지 관리자(maintainer)거나, 그 사이 어딘가에 있으시거나, 이 안내서에는 p5.js에 효과적으로 기여하는 데 도움이 되는 정보는 물론 팁과 요령이 포함되어 있습니다. 여기에 작성된 대부분의 내용은 달리 명시되지 않는 한 지침에 불과하므, 여기서 보여지는 절차들은 여러분의 작업 흐름에 맞게 조정할 수 있습니다. +방금 스튜어드(steward)로 참여하셨거나, p5.js의 숙련된 유지관리자(maintainer)거나, 그 사이 어딘가에 있으시거나, 이 안내서에는 p5.js에 효과적으로 기여하는 데 도움이 되는 정보는 물론 팁과 요령이 포함되어 있습니다. 여기에 작성된 대부분의 내용은 달리 명시되지 않는 한 지침에 불과하므, 여기서 보여지는 절차들은 여러분의 작업 흐름에 맞게 조정할 수 있습니다. ## 목차 @@ -80,7 +80,7 @@ - 위와 같이 충돌을 일으킬 수 있는 기능들은 이전 버전과 호환성이 없는 변경으로 간주됩니다. [주요 버전 배포](https://docs.npmjs.com/about-semantic-versioning)가 아니면 우리는 p5.js에 이전 버전과 호환성이 없는 변경을 만들지는 않습니다. - 제안된 새로운 기능이 p5.js에 이미 있는 기능, 비교적 간단한 순수 자바스크립트 코드나 기존의 사용하기 쉬운 라이브러리를 사용하여 만들어질 수 있나요? - 예를 들어, 문자열 배열을 연결하기 위해 p5.js 함수 `join(["Hello", "world!"])`보다는 자바스크립트 기본 문법인 `["Hello", "world!"].join()`가 우선시됩니다. -3. 접근성 요구 사항과 나머지 고려 사항이 충족된 경우, PR을 시작하기 전에 최소 2명의 스튜어드(steward) 또는 유지 관리자(maintainer)가 새로운 기능 요청을 승인해야 합니다. 새로운 기능에 대한 PR 검토 과정은 아래에 설명되어 있습니다. +3. 접근성 요구 사항과 나머지 고려 사항이 충족된 경우, PR을 시작하기 전에 최소 2명의 스튜어드 또는 유지관리자가 새로운 기능 요청을 승인해야 합니다. 새로운 기능에 대한 PR 검토 과정은 아래에 설명되어 있습니다. ### 기능 향상 @@ -90,7 +90,7 @@ 1. 새로운 기능 요청과 마찬가지로 기능 향상은 p5.js에 대한 접근성을 높이는 경우에만 허용됩니다. [위 섹션](http://guidelines.md#feature-request)의 1번 항목을 참고해주세요. 2. 기능 향상에 대한 포함 기준은 기능 요청의 경우와 비슷하지만, 잠재적으로 이전 버전과 호환성이 없는 변경(breaking changes)을 특히 주의해야 합니다. - 기존 함수를 수정하는 경우, 모든 이전의 유효하고 문서화된 함수 시그니처(function signature, 함수의 원형에 명시되는 매개변수 리스트)가 같은 방식으로 동작해야 합니다. -3. 기능 향상은 PR이 시작되기 전에 적어도 한 명의 스튜어드(steward) 또는 유지보수자(maintainer)의 승인을 받아야 합니다. 기능 향상을 위한 PR 검토 과정은 아래에 문서화되어 있습니다. +3. 기능 향상은 PR이 시작되기 전에 적어도 한 명의 스튜어드 또는 유지관리자의 승인을 받아야 합니다. 기능 향상을 위한 PR 검토 과정은 아래에 문서화되어 있습니다. ### 토론(Discussion) @@ -105,10 +105,10 @@ ## 풀 리퀘스트(Pull Requests) -p5.js 리포지토리(repository)에 대한 대부분의 코드 기여는 풀 리퀘스트(pull request)를 통해 이루어집니다. 스튜어드(steward)와 유지 관리자(maintainer)는 리포지토리에 대한 푸시(push) 권한이 있지만 코드 기여 시 똑같이 이슈 > PR > 검토 과정을 거치도록 권장합니다. PR을 검토하는 단계는 다음과 같습니다: +p5.js 리포지토리(repository)에 대한 대부분의 코드 기여는 풀 리퀘스트(pull request)를 통해 이루어집니다. 스튜어드와 유지관리자는 리포지토리에 대한 푸시(push) 권한이 있지만 코드 기여 시 똑같이 이슈 > PR > 검토 과정을 거치도록 권장합니다. PR을 검토하는 단계는 다음과 같습니다: - 풀 리퀘스트 템플릿은 [이 곳](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md)에서 확인할 수 있습니다. -- 거의 모든 풀 리퀘스트는 먼저 관련 이슈를 열고 논의해야 합니다. 즉, 관련 [이슈 작업 절차(workflow)](steward_guidelines.md#issues)를 먼저 따른 뒤에 스튜어드나 유지 관리자가 검토해야 합니다. +- 거의 모든 풀 리퀘스트는 먼저 관련 이슈를 열고 논의해야 합니다. 즉, 관련 [이슈 작업 절차(workflow)](steward_guidelines.md#issues)를 먼저 따른 뒤에 스튜어드나 유지관리자가 검토해야 합니다. - 절차가 적용되지 않는 유일한 경우는 매우 간단한 오타 수정 뿐이며, 이슈를 열 필요가 없고 특정 분야의 스튜어드가 아니더라도 리포지토리에 대한 병합(merge) 권한이 있는 모든 사람이 병합할 수 있습니다. - 이러한 예외가 존재하지만, 우리는 기여자들이 새로운 이슈를 먼저 열도록 권장합니다. 즉, 예외가 적용될지 잘 모르겠다면 어쨌든 이슈를 열어보세요! - 제시된 이슈가 풀 리퀘스트를 통해 완전히 해결되지 않았다면, 원본 게시물(post)의 "Resolves #OOOO"를 "Addresses #OOOO"로 수정하여 PR 병합 시에 원본 이슈가 자동으로 닫히지 않게끔 할 수 있습니다. @@ -124,7 +124,7 @@ p5.js 리포지토리(repository)에 대한 대부분의 코드 기여는 풀 ### 버그 수정 -1. 버그 수정은 관련 분야의 스튜어드(steward)에 의해 검토되어야 하며, 이상적으로는 해당 이슈의 수정을 승인한 동일한 사람이 이를 수행해야 합니다. +1. 버그 수정은 관련 분야의 스튜어드에 의해 검토되어야 하며, 이상적으로는 해당 이슈의 수정을 승인한 동일한 사람이 이를 수행해야 합니다. 2. PR의 "변경된 파일(Files Changed)" 탭을 이슈 토론(discussion)에 설명된 대로 수정이 되었는지 최초로 검토하는 데에 사용할 수 있습니다. 3. PR은 가능하고 적절하다면 로컬에서 테스트해야 합니다. GitHub CLI는 일부 과정을 간소화하는 데에 도움이 될 수 있습니다 (더 많은 내용은 아래의 [팁과 요령](steward_guidelines.md#tips-tricks)에 있습니다). - [ ] 수정은 원래의 이슈를 충분히 해결해야 합니다. @@ -141,7 +141,7 @@ p5.js 리포지토리(repository)에 대한 대부분의 코드 기여는 풀 - 여러 번 변경이 필요한 경우 한 줄 주석(single-line comments)을 여러 번 추가하지 마세요. 대신 문서화된 [이 곳](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)에 절차에 따라 여러 줄 주석(multiple-line comments)과 한 번의 요청으로 변경하세요. - 줄별 주석(line comments)이 설명이나 토론을 위한 것이라면, “변경 요청(Request changes)” 대신 “답글(Comment)”을 선택해 주세요:\ ![The "comment" option circled within the GitHub Finish Review menu](images/comment-review.png) -5. 한 번 PR이 검토되고 더 이상 변경이 필요하지 않으면 스튜어드는 추가 댓글이 있든 없든 이전 단계에서 “승인(Approve)” 옵션을 선택하여 PR을 “승인(Approved)”으로 표시할 수 있습니다. 그런 다음 스튜어드는 원한다면 다른 스튜어드나 유지 관리자에게 추가 검토를 요청할 수 있고, 병합(merge) 권한이 있다면 PR을 병합하거나 유지 관리자에게 병합을 요청할 수 있습니다. +5. 한 번 PR이 검토되고 더 이상 변경이 필요하지 않으면 스튜어드는 추가 댓글이 있든 없든 이전 단계에서 “승인(Approve)” 옵션을 선택하여 PR을 “승인(Approved)”으로 표시할 수 있습니다. 그런 다음 스튜어드는 원한다면 다른 스튜어드나 유지관리자에게 추가 검토를 요청할 수 있고, 병합(merge) 권한이 있다면 PR을 병합하거나 유지관리자에게 병합을 요청할 수 있습니다. 6. 새로운 기여자를 [README.md](http://readme.md/) 파일의 기여자 목록에 추가하려면 @[all-contributors](https://allcontributors.org/docs/en/emoji-key) 봇을 호출해야 합니다. 각각의 기여 유형은 아래의 `[contribution` `type]`에 표시할 수 있고, 사용할 수 있는 기여 유형의 전체 목록은 위 링크에서 확인할 수 있습니다. @@ -158,7 +158,7 @@ p5.js 리포지토리(repository)에 대한 대부분의 코드 기여는 풀 새로운 기능 또는 기능 향상 PR은 버그 수정과 비슷하지만 한 가지 주목해야 할 차이점이 있습니다: -- 새로운 기능/기능 향상 PR은 병합(merge)되기 전에 적어도 두 명의 스튜어드 또는 유지 관리자의 검토와 승인을 받아야 합니다. +- 새로운 기능/기능 향상 PR은 병합(merge)되기 전에 적어도 두 명의 스튜어드 또는 유지관리자의 검토와 승인을 받아야 합니다. ### 디펜다봇(Dependabot) From af650a9a5a06d9d75628c4c887deaccecb976f0b Mon Sep 17 00:00:00 2001 From: Inhwa <51147158+yinhwa@users.noreply.github.com> Date: Thu, 21 Mar 2024 11:30:28 +0900 Subject: [PATCH 12/12] Finalize [p5.js KO] steward_guidelines.md --- contributor_docs/ko/[p5.js KO] steward_guidelines.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributor_docs/ko/[p5.js KO] steward_guidelines.md b/contributor_docs/ko/[p5.js KO] steward_guidelines.md index 171b668cf5..704a7ad555 100644 --- a/contributor_docs/ko/[p5.js KO] steward_guidelines.md +++ b/contributor_docs/ko/[p5.js KO] steward_guidelines.md @@ -167,7 +167,7 @@ p5.js 리포지토리(repository)에 대한 대부분의 코드 기여는 풀 - [유의적 버전(semver)](https://semver.org/) 패치(patch) 버전 업데이트면서 자동 CI 테스트를 통과한 경우에 Dependabot PR은 바로 병합(merge)될 수 있습니다. - 디펜다봇 PR이 유의적 버전의 경미한 변경 사항을 다루는 경우, 보통 자동 CI 테스트만 통과하면 바로 병합될 수 있습니다. 빠르게 업데이트된 종속성(dependency)의 변경 기록(changelog)을 확인하는 것이 좋습니다. -- 디펜다봇 PR이 유의적 버전의 주요 변경 사항을 다루는 경우, 빌드 과정이나 p5.js 기능에 영향을 줄 수 있습니다. 이 경우에 검토자(reviewer)는 가능하면 최신 버전부터 대상 버전까지의 변경 기록을 검토하고, PR을 로컬 환경에서 테스트하여 모든 과정이 정상적으로 작동하는지 확인합니다. 그리고 종속성 비호환 발생 대비에 필요한 모든 변경 사항을 제출합니다. +- 디펜다봇 PR이 유의적 버전의 주요 변경 사항을 다루는 경우, 빌드 과정이나 p5.js 기능에 영향을 줄 수 있습니다. 이 경우에 검토자(reviewer)는 가능하면 최신 버전부터 대상 버전까지의 변경 기록을 검토하고, PR을 로컬 환경에서 테스트하여 모든 과정이 정상적으로 작동하는지 확인합니다. 그리고 종속성의 호환성 문제 대비에 필요한 모든 변경 사항을 제출합니다. - Node.js는 매우 오래된 버전에 대한 공식 지원을 중단하기 때문에, 꽤나 많은 종속성이 주요 버전과 충돌합니다. 주요 버전 변경이 반드시 종속성 API 변경으로 인한 것은 아닙니다. ---