From 3e1feeab065dfc9c74fadbfa27e2c1546b00e151 Mon Sep 17 00:00:00 2001
From: Marce <ml.008@outlook.com>
Date: Fri, 15 Mar 2024 14:50:56 -0600
Subject: [PATCH 01/19] Create steward_guidelines.md

#NEW FILE , ADDING COMMENT FOR TESTING PURPOSE.
---
 contributor_docs/es/steward_guidelines.md | 384 ++++++++++++++++++++++
 1 file changed, 384 insertions(+)
 create mode 100644 contributor_docs/es/steward_guidelines.md

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
new file mode 100644
index 0000000000..1284686969
--- /dev/null
+++ b/contributor_docs/es/steward_guidelines.md
@@ -0,0 +1,384 @@
+# Steward Guidelines
+
+
+#TESTING COMMENT MARCELA
+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 15d2533163cba78d8b9e0be01b010cf307d630e2 Mon Sep 17 00:00:00 2001
From: Marce <ml.008@outlook.com>
Date: Fri, 15 Mar 2024 14:59:57 -0600
Subject: [PATCH 02/19] Update steward_guidelines.md

Starting translations
---
 contributor_docs/es/steward_guidelines.md | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
index 1284686969..d7e60fbd93 100644
--- a/contributor_docs/es/steward_guidelines.md
+++ b/contributor_docs/es/steward_guidelines.md
@@ -1,11 +1,9 @@
-# Steward Guidelines
+# Directrices para Administradores
 
 
-#TESTING COMMENT MARCELA
-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.
+Ya sea que recién te hayas unido a nosotros como administrador, seas un mantenedor experimentado de p5.js, o estés en algún punto intermedio, esta guía contiene información, así como consejos y trucos que te ayudarán a contribuir de manera efectiva a p5.js. La mayor parte de lo que se escribe aquí son pautas, a menos que se indique lo contrario, lo que significa que puedes adaptar las prácticas mostradas aquí para que se ajusten a tu flujo de trabajo.
 
-
-## Table of Contents
+## Tabla de Contenidos
 
 - [Issues](steward_guidelines.md#issues)
   - [Bug report](steward_guidelines.md#bug-report)

From 413df5b294b651e1f1f475ccf3372852aa1abcf3 Mon Sep 17 00:00:00 2001
From: Marce <ml.008@outlook.com>
Date: Fri, 15 Mar 2024 15:24:28 -0600
Subject: [PATCH 03/19] Update steward_guidelines.md

Translate steward_guidelines
---
 contributor_docs/es/steward_guidelines.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
index d7e60fbd93..44af1d8f8f 100644
--- a/contributor_docs/es/steward_guidelines.md
+++ b/contributor_docs/es/steward_guidelines.md
@@ -29,7 +29,7 @@ Ya sea que recién te hayas unido a nosotros como administrador, seas un mantene
 
 ## 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).
+Alentamos a la mayoría de las contribuciones de código fuente a comenzar con un problema, y como tal, los issues son el lugar donde la mayoría de las discusiones tendrán lugar. Los pasos a seguir al revisar un problema dependerán del tipo de problema que sea. El repositorio utiliza [GitHub issue templates] (https://github.com/processing/p5.js/blob/main/.github/ISSUE_TEMPLATE) para organizar mejor los diferentes tipos de problemas y alentar a los autores de problemas a proporcionar toda la información relevante sobre sus problemas. El primer paso al revisar el issue a menudo será revisar la plantilla completada y determinar si necesita información adicional (por ejemplo, porque algunos campos no se completaron o se utilizó la plantilla incorrecta.
 
 
 ### Bug report

From 6e8441031ac0b606913b690bc7bad8cf7f021232 Mon Sep 17 00:00:00 2001
From: Marce <ml.008@outlook.com>
Date: Fri, 15 Mar 2024 19:59:48 -0600
Subject: [PATCH 04/19] Update steward_guidelines.md

---
 contributor_docs/es/steward_guidelines.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
index 44af1d8f8f..bec324cceb 100644
--- a/contributor_docs/es/steward_guidelines.md
+++ b/contributor_docs/es/steward_guidelines.md
@@ -29,12 +29,12 @@ Ya sea que recién te hayas unido a nosotros como administrador, seas un mantene
 
 ## Issues
 
-Alentamos a la mayoría de las contribuciones de código fuente a comenzar con un problema, y como tal, los issues son el lugar donde la mayoría de las discusiones tendrán lugar. Los pasos a seguir al revisar un problema dependerán del tipo de problema que sea. El repositorio utiliza [GitHub issue templates] (https://github.com/processing/p5.js/blob/main/.github/ISSUE_TEMPLATE) para organizar mejor los diferentes tipos de problemas y alentar a los autores de problemas a proporcionar toda la información relevante sobre sus problemas. El primer paso al revisar el issue a menudo será revisar la plantilla completada y determinar si necesita información adicional (por ejemplo, porque algunos campos no se completaron o se utilizó la plantilla incorrecta.
+Alentamos a la mayoría de las contribuciones de código fuente a comenzar con un problema, y como tal, los issues son el lugar donde la mayoría de las discusiones tendrán lugar. Los pasos a seguir al revisar un problema dependerán del tipo de problema que sea. El repositorio utiliza [GitHub issue templates] (https://github.com/processing/p5.js/blob/main/.github/ISSUE_TEMPLATE) para organizar mejor los diferentes tipos de problemas y alentar a los autores de problemas a proporcionar toda la información relevante sobre sus problemas. El primer paso al revisar el issue a menudo será revisar la plantilla completada y determinar si necesita información adicional por ejemplo, porque algunos campos no se completaron o se utilizó la plantilla incorrecta.
 
 
-### Bug report
+### Reporte/informe de errores (Bug report)
 
-Bug report issues should use the "Found a bug" issue template. The following workflow is typical for addressing bug reports:
+Los informes de errores de issues (Bug report issues)  deberían utilizar la plantilla de problema(issue template) "Found a bug". El siguiente flujo de trabajo es típico para abordar los informes de errores:
 
 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.

From ad914681398be3977a0b9e4b1023262c6ff4320a Mon Sep 17 00:00:00 2001
From: Marce <ml.008@outlook.com>
Date: Fri, 15 Mar 2024 20:55:06 -0600
Subject: [PATCH 05/19] Update steward_guidelines.md

Informe de errores (Bug Report issues)
---
 contributor_docs/es/steward_guidelines.md | 48 ++++++++++++-----------
 1 file changed, 25 insertions(+), 23 deletions(-)

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
index bec324cceb..7c25f6e317 100644
--- a/contributor_docs/es/steward_guidelines.md
+++ b/contributor_docs/es/steward_guidelines.md
@@ -36,29 +36,31 @@ Alentamos a la mayoría de las contribuciones de código fuente a comenzar con u
 
 Los informes de errores de issues (Bug report issues)  deberían utilizar la plantilla de problema(issue template) "Found a bug". El siguiente flujo de trabajo es típico para abordar los informes de errores:
 
-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. Replicar el error
+   - El objetivo de la plantilla es proporcionar suficiente información para que un revisor intente replicar el error en cuestión.
+   - Si el error reportado no es relevante para el repositorio en el que se abrió (p5.js, p5.js-website, u otro):
+     - Transfiera el problema al repositorio relevante si tiene acceso a él.
+     - De lo contrario, deje un comentario sobre dónde debería presentarse el informe de error (con un enlace directo proporcionado) y cierre el problema.
+   - El primer paso para revisar un informe de error es verificar si se proporciona suficiente información para replicar el error, y si es así, intentar replicar el error según lo descrito.
+2. Si el error se puede replicar:
+   - Puede ser necesario realizar alguna discusión para determinar la mejor manera de solucionar un error particular. Puede ser necesario realizar alguna discusión para determinar la mejor manera de solucionar un error particular. A veces, puede ser directo; otras veces, puede ser complicado. Por favor, consulte los principios de diseño de p5.js ( [p5.js' design principles](design_principles.md)al tomar esta decisión caso por caso.
+   - Si el autor del issue indicó en el issue que está dispuesto a contribuir con una solución:
+     - Apruebe el problema para su solución por parte del autor del problema dejando un comentario y asignándoles el problema. Utilice el botón de engranaje en el lado derecho junto a "Asignado a" "Assignee".
+   - Si el autor del problema no desea contribuir con una solución:
+     - Deje un comentario reconociendo que el error se puede replicar.
+     - Intente solucionarlo usted mismo o agregue la etiqueta `help wanted` para señalar que es un issue que  necesita solución.
+3. Si el error no se puede replicar:
+   - Solicite información adicional si aún no se ha proporcionado en la plantilla (versión de p5.js, versión del navegador, versión del sistema operativo, etc.)(p5.js version, browser version, OS version, etc.).
+   - Si su entorno de prueba difiere de lo que se informa en el problema(issue) (por ejemplo, un navegador o sistema operativo diferente)(e.g., a different browser or OS):
+     - Deje un comentario diciendo que no puede replicar en su entorno específico.
+     - Agregue una etiqueta `help wanted` al problema(issue) y pida a alguien más con la configuración especificada en el problema que intente replicar el error.
+   - Sometimes, bugs only occur when using the web editor and not when testing locally. In this case, the issue should be redirected to the 
+   - A veces, los errores solo ocurren al usar el editor web (web editor) y no al probar localmente. En este caso, el problema debería ser redirigido al repositorio del editor web [web editor repo](https://github.com/processing/p5.js-web-editor).
+   - Si la replicación es posible más tarde, regrese al paso 2.
+4. Si el error se origina en el código que el usuario proporcionó en el informe de error y no en el comportamiento de p5.js:
+   - Determine si la documentación de p5.js, la implementación de código o el sistema de errores amigable pueden mejorarse para evitar que se cometa el mismo error.
+   - Redirija amablemente cualquier pregunta adicional al foro [forum](https://discourse.processing.org/)  o al Discord [Discord](https://discord.com/invite/SHQ8dH25r9) y cierre el issue si no se van a realizar más cambios en p5.js.
+   
 
 
 ### Feature request

From 44e536dc51de08d11b60d30e3f1c8dcb75a8b282 Mon Sep 17 00:00:00 2001
From: Marce <ml.008@outlook.com>
Date: Fri, 15 Mar 2024 21:04:18 -0600
Subject: [PATCH 06/19] Update steward_guidelines.md

Feature request
---
 contributor_docs/es/steward_guidelines.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
index 7c25f6e317..6d86b7cf95 100644
--- a/contributor_docs/es/steward_guidelines.md
+++ b/contributor_docs/es/steward_guidelines.md
@@ -63,9 +63,9 @@ Los informes de errores de issues (Bug report issues)  deberían utilizar la pla
    
 
 
-### Feature request
+### Solicitud de función (Feature request)
 
-Feature request issues should use the "New Feature Request" issue template. The following workflow is typical for addressing feature requests:
+Las solicitudes de función de issue (Feature request issues) deberían utilizar la plantilla de problema(issue) "Nueva Solicitud de Función" ("New Feature Request") . El siguiente flujo de trabajo es típico para abordar las solicitudes de función:"
 
 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.

From 84d893f5b632814e6d3c84d8ef39de5e58a7ed93 Mon Sep 17 00:00:00 2001
From: Marce <ml.008@outlook.com>
Date: Fri, 15 Mar 2024 21:06:22 -0600
Subject: [PATCH 07/19] Update steward_guidelines.md

---
 contributor_docs/es/steward_guidelines.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
index 6d86b7cf95..51fa95d547 100644
--- a/contributor_docs/es/steward_guidelines.md
+++ b/contributor_docs/es/steward_guidelines.md
@@ -65,7 +65,7 @@ Los informes de errores de issues (Bug report issues)  deberían utilizar la pla
 
 ### Solicitud de función (Feature request)
 
-Las solicitudes de función de issue (Feature request issues) deberían utilizar la plantilla de problema(issue) "Nueva Solicitud de Función" ("New Feature Request") . El siguiente flujo de trabajo es típico para abordar las solicitudes de función:"
+Los issues/problemas de solicitudes de función (Feature request issues) deberían utilizar la plantilla de problema(issue) "Nueva Solicitud de Función" ("New Feature Request") . El siguiente flujo de trabajo es típico para abordar las solicitudes de función:"
 
 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.

From 3e54cf7e88b7b8e042b3056d7b91444085cf8148 Mon Sep 17 00:00:00 2001
From: Marce <ml.008@outlook.com>
Date: Sat, 16 Mar 2024 06:33:54 -0600
Subject: [PATCH 08/19] Update steward_guidelines.md

Feature enhancement
---
 contributor_docs/es/steward_guidelines.md | 59 ++++++++++++-----------
 1 file changed, 30 insertions(+), 29 deletions(-)

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
index 51fa95d547..c49756e2a0 100644
--- a/contributor_docs/es/steward_guidelines.md
+++ b/contributor_docs/es/steward_guidelines.md
@@ -43,7 +43,7 @@ Los informes de errores de issues (Bug report issues)  deberían utilizar la pla
      - De lo contrario, deje un comentario sobre dónde debería presentarse el informe de error (con un enlace directo proporcionado) y cierre el problema.
    - El primer paso para revisar un informe de error es verificar si se proporciona suficiente información para replicar el error, y si es así, intentar replicar el error según lo descrito.
 2. Si el error se puede replicar:
-   - Puede ser necesario realizar alguna discusión para determinar la mejor manera de solucionar un error particular. Puede ser necesario realizar alguna discusión para determinar la mejor manera de solucionar un error particular. A veces, puede ser directo; otras veces, puede ser complicado. Por favor, consulte los principios de diseño de p5.js ( [p5.js' design principles](design_principles.md)al tomar esta decisión caso por caso.
+   - Puede ser necesario realizar alguna discusión para determinar la mejor manera de solucionar un error particular. Puede ser necesario realizar alguna discusión para determinar la mejor manera de solucionar un error particular. A veces, puede ser directo; otras veces, puede ser complicado. Por favor, consulte los principios de diseño de p5.js [p5.js' design principles](design_principles.md) al tomar esta decisión caso por caso.
    - Si el autor del issue indicó en el issue que está dispuesto a contribuir con una solución:
      - Apruebe el problema para su solución por parte del autor del problema dejando un comentario y asignándoles el problema. Utilice el botón de engranaje en el lado derecho junto a "Asignado a" "Assignee".
    - Si el autor del problema no desea contribuir con una solución:
@@ -67,35 +67,36 @@ Los informes de errores de issues (Bug report issues)  deberían utilizar la pla
 
 Los issues/problemas de solicitudes de función (Feature request issues) deberían utilizar la plantilla de problema(issue) "Nueva Solicitud de Función" ("New Feature Request") . El siguiente flujo de trabajo es típico para abordar las solicitudes de función:"
 
-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).
+1. Como parte del compromiso de p5.js de aumentar el acceso, una solicitud de función(feature request) debe justificar cómo aumenta el acceso de p5.js a comunidades que históricamente han sido marginadas en el campo. Más detalles están disponibles aquí[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
+   - Si una solicitud de función(feature request) no tiene suficientemente completado el campo "Aumento de Acceso"("Increasing Access"), puedes preguntar al autor del problema(issue autor) cómo la función(feature) aumenta el acceso.
+   - La declaración de acceso de una función puede ser proporcionada por un miembro diferente de la comunidad, incluidos los revisores de problemas(issue reviewers).
+1. La nueva solicitud de función puede ser evaluada para su inclusión en base a los siguientes criterios:
+   - ¿La función(feature) encaja en el alcance del proyecto y los principios de diseño [design principles](design_principles.md) de p5.js?
+     - Por ejemplo, una solicitud para agregar una nueva forma primitiva de dibujo puede ser considerada, pero una solicitud para adoptar un protocolo de Internet de las cosas basado en el navegador (browser-based IOT protocol) probablemente estará fuera de alcance.
+     - En general, el alcance de p5.js debería ser relativamente estrecho para evitar un exceso de características poco utilizadas.
+     - Si una función no encaja en el alcance de p5.js, sugiere al autor del problema(issue) que implemente la función(feature) como una biblioteca complementaria(addon library).
+     - Si no está claro si encaja o no, puede ser una buena idea sugerir hacer una biblioteca complementaria(addon library)como una prueba de concepto(proof-of-concept).Esto ayuda a dar a los usuarios una forma de usar la función(feature), proporciona un ejemplo mucho más concreto de su uso e importancia, y no necesariamente necesita ser una solución tan completa como una función completamente integrada. Puede integrarse en el núcleo(the core) de p5.js más adelante si corresponde. 
+   - ¿Es probable que la función(feature) propuesta cause un cambio incompatible?
+     - ¿Entrará en conflicto con las funciones y variables existentes de p5.js?
+     - ¿Entrará en conflicto con los bocetos típicos(typical sketches) ya escritos para p5.js?
+     - Las funciones que probablemente causen conflictos, como las mencionadas anteriormente, se consideran cambios incompatibles(breaking changes). Sin un lanzamiento de versión mayor a [major version release](https://docs.npmjs.com/about-semantic-versioning), no deberíamos realizar cambios incompatibles en p5.js.
+   - ¿Se puede lograr la nueva función propuesta utilizando las funcionalidades existentes ya en p5.js, código JavaScript nativo relativamente simple, o bibliotecas existentes fáciles de usar(existing easy-to-use libraries)?
+     - Por ejemplo, en lugar de proporcionar una función de p5.js para unir una matriz de cadenas (array of strings) como `join(["Hello", "world!"])`, debería preferirse el JavaScript nativo  `["Hello", "world!"].join()`.
+2. Si el requisito de acceso y otras consideraciones han sido cumplidas, al menos dos administradores o mantenedores deben aprobar la nueva solicitud de función(feature request) antes de que comience el trabajo hacia una PR. El proceso de revisión de PR para nuevas funciones está documentado a continuación.
+
+
+### Mejora de función (Feature enhancement)
+
+Las solicitudes(issues) de mejora de función deberían utilizar la plantilla de problema(issue template) "Mejora de Función Existente"("Existing Feature Enhancement"). El proceso es muy similar a las solicitudes de nuevas funciones. La diferencia entre una solicitud de nueva función(new feature request) y una mejora de función puede ser confusa a veces. La mejora de función principalmente trata sobre las funciones existentes de p5.js, mientras que una solicitud de nueva función podría estar solicitando la adición de funciones completamente nuevas.
+
+1. Similar a las solicitudes de nuevas funciones(new feature), las mejoras de función(feature enhancement) solo deben ser aceptadas si aumentan el acceso a p5.js. Por favor, consulta el punto 1 de la sección anterior[section above](steward_guidelines.md#feature-request).
+2. Los criterios de inclusión para las mejoras de función son similares a los de las solicitudes de nuevas funciones, pero se debe prestar especial atención a los posibles cambios incompatibles.
+   - Si se están modificando funciones existentes, todas las firmas de funciones válidas y documentadas previamente deben comportarse de la misma manera.
+3. Las mejoras de funciones deben ser aprobadas por al menos un administrador o mantenedor antes de que comience el trabajo hacia una PR (solicitud de extracción). El proceso de revisión de PR para mejoras de funciones está documentado a continuación.
+
+
+### Discusión
 
 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: 
 

From c5e3b75c1e5bd6680f5bc82051b269d6bc06538b Mon Sep 17 00:00:00 2001
From: Marce <ml.008@outlook.com>
Date: Sat, 16 Mar 2024 10:22:15 -0600
Subject: [PATCH 09/19] Update steward_guidelines.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Discusión
---
 contributor_docs/es/steward_guidelines.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
index c49756e2a0..da34bf44e7 100644
--- a/contributor_docs/es/steward_guidelines.md
+++ b/contributor_docs/es/steward_guidelines.md
@@ -98,11 +98,11 @@ Las solicitudes(issues) de mejora de función deberían utilizar la plantilla de
 
 ### Discusión
 
-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: 
+Este tipo de problema tiene una plantilla(template) mínima ("Discusión") y debería ser utilizada para recopilar comentarios(retroalimentaciones/feedback) sobre un tema en general antes de consolidarlo en algo más específico, como una solicitud de función(feature request). Estos problemas(issues) de discusión pueden cerrarse cuando finaliza la conversación y se han creado los problemas más específicos resultantes:
 
-- 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.
+- Si se abre un issue como una discusión pero debería ser, por ejemplo, un informe de error(bug report), se debe aplicar la etiqueta correcta y quitar la etiqueta de "discusión". Además, se debe solicitar información adicional sobre el error al autor si aún no se ha incluido.
+- Si se abre un problema como una discusión pero no es relevante para la contribución de código fuente o de otra manera relevante para los repositorios de GitHub/el proceso de contribución/la comunidad de contribución, deberían ser redirigidos al foro o a Discord y el problema cerrado.
+- Si es relevante, se deben agregar etiquetas adicionales a los issues de discusión para señalar aún más qué tipo de discusión es con solo mirarla.
 
 ---
 

From c8136060c00b0eb05f3cf62300cad2d24f64da6a Mon Sep 17 00:00:00 2001
From: Marce <ml.008@outlook.com>
Date: Sat, 16 Mar 2024 12:42:04 -0600
Subject: [PATCH 10/19] Update steward_guidelines.md

Ready for review
---
 contributor_docs/es/steward_guidelines.md | 55 +++++++++++------------
 1 file changed, 27 insertions(+), 28 deletions(-)

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
index da34bf44e7..4db341cfb7 100644
--- a/contributor_docs/es/steward_guidelines.md
+++ b/contributor_docs/es/steward_guidelines.md
@@ -109,55 +109,54 @@ Este tipo de problema tiene una plantilla(template) mínima ("Discusión") y deb
 
 ## 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:
+Casi todas las contribuciones de código a los repositorios de p5.js se realizan a través de solicitudes de extracción(Pull Request). Los administradores y mantenedores pueden tener acceso de escritura(push access) a los repositorios, pero aún se les anima a seguir el mismo proceso de issue > PR > proceso de revisión al contribuir con código. Aquí están los pasos para revisar una 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.
+- La plantilla de solicitud de extracción(pull request template) se puede encontrar [here](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md).
+- Casi todas las solicitudes de extracción(pull requests ) deben tener problemas asociados abiertos y discutidos primero, lo que significa que los relevantes [issue workflow](steward_guidelines.md#issues) deben haber sido seguidos primero antes de que una PR sea revisada por cualquier administrador o mantenedor.
+  - Las únicas instancias donde esto no se aplica son correcciones muy menores de errores tipográficos(minor typo fixes), las cuales no requieren un problema abierto y pueden ser fusionadas(merged) por cualquier persona con acceso para fusionar(merge access) al repositorio, incluso si no son administradores de una área en particular.
+  - Si bien esta excepción existe, la aplicaremos en la práctica solo mientras se siga alentando a los contribuyentes a abrir nuevos problemas primero. En otras palabras, si tienes dudas sobre si esta excepción se aplica, simplemente abre un issue de todos modos.
+- Si una solicitud de extracción (pull request) no resuelve completamente el issue referenciado, puedes editar la publicación original y cambiar "Resolves #OOOO" a "Addresses #OOOO" para que no cierre automáticamente el problema original cuando la PR se fusione(merge).
 
 
-### Simple fix
+### Solución sencilla (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.
+Las correcciones simples(simple fix), como la corrección de un pequeño error tipográfico, pueden fusionarse(merge) directamente por cualquier persona con acceso para fusionar(aplicar merge). Verifica en la pestaña "Files Changed" de la PR para asegurarte de que la prueba automatizada de integración continua (CI) pase.
 
 ![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
+### Corrección de error (Bug fix) Seguir desde aqui.
 
-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. Bug fixes deberían ser revisado por el administrador del área relevante, idealmente el mismo que aprobó el issue referenciado para su corrección.
+2. La pestaña "Files Changed" de la PR se puede utilizar para revisar inicialmente si la corrección (el fix)se implementa según lo descrito en la discusión del issue.
+3. El PR Debería ser probado localmente siempre que sea posible y relevante. El GitHub CLI puede ayudar a agilizar parte del proceso. (Ver más abajo en [Tips & Tricks](steward_guidelines.md#tips-tricks)).
+   - [ ] El fix debe abordar suficientemente el problema original.
+   - [ ] El fix no debe cambiar ningún comportamiento existente a menos que se acuerde en el problema original.
+   - [ ] El fix no debe tener un impacto significativo en el rendimiento de p5.js.
+   - [ ] El fix no debe tener ningún impacto en la accesibilidad de p5.js.
+   - [ ] El fix debe utilizar el estándar moderno de codificación en JavaScript.
+   - [ ] El fix debe pasar todas las pruebas automatizadas e incluir nuevas pruebas(tests) si son relevantes.
+4. Si se requieren cambios adicionales, se deben agregar comentarios en línea a las líneas relevantes según se describió anteriormente [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).
+   - Un bloque de sugerencias también puede ser usado para sugerir cambios específicos:\
      ![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":\
+   - Si se requieren múltiples cambios, no agregues comentarios de una sola línea muchas veces. En su lugar, sigue el procedimiento documentado [here](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request) para hacer comentarios de varias líneas y una sola solicitud de cambios (change request).
+   - Si los comentarios en línea son solo para aclaraciones o discusión, elige "Comment" en lugar de "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.
+5. Una vez que la PR haya sido revisada y no se requieran cambios adicionales, un administrador puede marcar la PR como "Approved" eligiendo la opción "Approve" en el paso anterior, con o sin comentarios adicionales. El administrador puede luego solicitar una revisión adicional por otro administrador o mantenedor si lo desea, fusionar(merge) la PR si tiene acceso para fusionar(merge access), o solicitar una fusión (request/solicitar merge) de un mantenedor.
+6. @[all-contributors](https://allcontributors.org/docs/en/emoji-key)El bot debería ser llamado para agregar cualquier nuevo colaborador a la lista de colaboradores en el archivo README.md. Cada tipo de contribución puede ser indicado en lugar de `[contribution` `type]` a continuación, se puede encontrar la lista completa de tipos de contribuciones disponibles en el enlace anterior.
 
 `@all-contributors` `please` `add` `@[GitHub` `handle]` `for` `[contribution` `type]`
 
 
-### New feature/feature enhancement
+### Nueva función/mejora de función (New feature/feature enhancement()
 
-The process for new feature or feature enhancement PR is similar to bug fixes with just one notable difference:
+El proceso para una nueva función o mejora de función en una PR es similar a la de correcciones de errores(bug fixes) con una diferencia notable:
 
-- A new feature/feature enhancement PR must be reviewed and approved by at least two stewards or maintainers before it can be merged.
+- Una PR de nueva función(new feature) o mejora de función(feature enhancement) debe ser revisada y aprobada por al menos dos administradores o mantenedores antes de que pueda fusionarse (be merged).
 
 
 ### Dependabot

From 9c576f11db08a9c65444b297edb1b8d5a3d91187 Mon Sep 17 00:00:00 2001
From: Marce <ml.008@outlook.com>
Date: Sun, 17 Mar 2024 14:54:47 -0600
Subject: [PATCH 11/19] Update steward_guidelines.md

Dependabot
---
 contributor_docs/es/steward_guidelines.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
index 4db341cfb7..5385f74c57 100644
--- a/contributor_docs/es/steward_guidelines.md
+++ b/contributor_docs/es/steward_guidelines.md
@@ -161,12 +161,12 @@ El proceso para una nueva función o mejora de función en una PR es similar a l
 
 ### Dependabot
 
-Dependabot PRs are usually only visible to repo admins so if this does not apply to you, please skip this section.
+Las PRs de Dependabot generalmente solo son visibles para los administradores del repositorio, así que si esto no aplica a ti, por favor omite esta sección.
 
-- 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.
+- Las PRs de Dependabot pueden fusionarse(be merged) directamente si la actualización de la versión es una [semver](https://semver.org/) versión de parche( patch version) y la prueba automatizada de CI(CI test ) ha pasado.
+- Las PRs de Dependabot con cambios de versión semver menor generalmente se pueden fusionar directamente siempre y cuando la prueba automatizada de CI pase. Se recomienda hacer una rápida verificación en el registro de cambios(changelog ) de la dependencia actualizada.
+- Las PRs de Dependabot con cambios de versión semver mayor probablemente afectarán el proceso de compilación o las funcionalidades de p5.js. En este caso, se anima al revisor a revisar el registro de cambios desde la versión actual hasta la versión objetivo, si es posible, y probar la PR localmente para asegurarse de que todos los procesos estén funcionando y realizar los cambios necesarios debido a posibles cambios que puedan romper las dependencias.
+  - Muchas dependencias aumentan los números de versión principales solo porque dejan de admitir versiones muy antiguas de Node.js. En muchos casos, los cambios de versión principales no necesariamente significan cambios que rompan debido a cambios en la API de la dependencia.
 
 ---
 

From cbd5566cfe0c59261225d2b9ae45ad7690946e97 Mon Sep 17 00:00:00 2001
From: Marce <ml.008@outlook.com>
Date: Mon, 18 Mar 2024 06:50:05 -0600
Subject: [PATCH 12/19] Update steward_guidelines.md

Sugerencias implementadas y comentarios nuevos.
---
 contributor_docs/es/steward_guidelines.md | 131 +++++++++++-----------
 1 file changed, 65 insertions(+), 66 deletions(-)

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
index 5385f74c57..2fde1cfac4 100644
--- a/contributor_docs/es/steward_guidelines.md
+++ b/contributor_docs/es/steward_guidelines.md
@@ -1,9 +1,10 @@
-# Directrices para Administradores
+# Directrices para Administradores  
 
 
 Ya sea que recién te hayas unido a nosotros como administrador, seas un mantenedor experimentado de p5.js, o estés en algún punto intermedio, esta guía contiene información, así como consejos y trucos que te ayudarán a contribuir de manera efectiva a p5.js. La mayor parte de lo que se escribe aquí son pautas, a menos que se indique lo contrario, lo que significa que puedes adaptar las prácticas mostradas aquí para que se ajusten a tu flujo de trabajo.
 
 ## Tabla de Contenidos
+#sugiero asegurarnos que el contenido de la tabla no se muestre en ingles en la aplicaciøn antes de traducir bug report, feature request, etc. i.e. una tab llamada new request, pero nosotros escribamos da click en la pesta;a de nueva solicitud.
 
 - [Issues](steward_guidelines.md#issues)
   - [Bug report](steward_guidelines.md#bug-report)
@@ -29,12 +30,12 @@ Ya sea que recién te hayas unido a nosotros como administrador, seas un mantene
 
 ## Issues
 
-Alentamos a la mayoría de las contribuciones de código fuente a comenzar con un problema, y como tal, los issues son el lugar donde la mayoría de las discusiones tendrán lugar. Los pasos a seguir al revisar un problema dependerán del tipo de problema que sea. El repositorio utiliza [GitHub issue templates] (https://github.com/processing/p5.js/blob/main/.github/ISSUE_TEMPLATE) para organizar mejor los diferentes tipos de problemas y alentar a los autores de problemas a proporcionar toda la información relevante sobre sus problemas. El primer paso al revisar el issue a menudo será revisar la plantilla completada y determinar si necesita información adicional por ejemplo, porque algunos campos no se completaron o se utilizó la plantilla incorrecta.
+Alentamos a la mayoría de las contribuciones de código fuente a comenzar con un issue, y como tal, los "issues" son el lugar donde la mayoría de las discusiones tendrán lugar. Los pasos a seguir al revisar un issue dependerán del tipo de issue que sea. El repositorio utiliza Plantillas de issues de GitHub (https://github.com/processing/p5.js/blob/main/.github/ISSUE_TEMPLATE) para organizar mejor los diferentes tipos de problemas y alentar a los autores de problemas a proporcionar toda la información relevante sobre sus problemas. El primer paso al revisar el "issue" a menudo será revisar la plantilla completada y determinar si necesita información adicional por ejemplo, porque algunos campos no se completaron o se utilizó la plantilla incorrecta.
 
 
-### Reporte/informe de errores (Bug report)
+### "Bug report"(informe de error)
 
-Los informes de errores de issues (Bug report issues)  deberían utilizar la plantilla de problema(issue template) "Found a bug". El siguiente flujo de trabajo es típico para abordar los informes de errores:
+Los "Bug report issues" (informes de errores de issues) deberían utilizar la plantilla de Issue "Found a bug". El siguiente flujo de trabajo es típico para abordar los informes de errores:
 
 1. Replicar el error
    - El objetivo de la plantilla es proporcionar suficiente información para que un revisor intente replicar el error en cuestión.
@@ -43,128 +44,126 @@ Los informes de errores de issues (Bug report issues)  deberían utilizar la pla
      - De lo contrario, deje un comentario sobre dónde debería presentarse el informe de error (con un enlace directo proporcionado) y cierre el problema.
    - El primer paso para revisar un informe de error es verificar si se proporciona suficiente información para replicar el error, y si es así, intentar replicar el error según lo descrito.
 2. Si el error se puede replicar:
-   - Puede ser necesario realizar alguna discusión para determinar la mejor manera de solucionar un error particular. Puede ser necesario realizar alguna discusión para determinar la mejor manera de solucionar un error particular. A veces, puede ser directo; otras veces, puede ser complicado. Por favor, consulte los principios de diseño de p5.js [p5.js' design principles](design_principles.md) al tomar esta decisión caso por caso.
-   - Si el autor del issue indicó en el issue que está dispuesto a contribuir con una solución:
-     - Apruebe el problema para su solución por parte del autor del problema dejando un comentario y asignándoles el problema. Utilice el botón de engranaje en el lado derecho junto a "Asignado a" "Assignee".
+   - Puede ser necesario realizar alguna discusión para determinar la mejor manera de solucionar un error particular. Puede ser necesario realizar alguna discusión para determinar la mejor manera de solucionar un error particular. A veces, puede ser directo; otras veces, puede ser complicado. Por favor, consulte los [principios de diseño de p5.js](design_principles.md) al tomar esta decisión caso por caso.
+   - Si el autor del "issue" indicó en el "issue" que está dispuesto a contribuir con una solución:
+     - Apruebe el problema para su solución por parte del autor del problema dejando un comentario y asignándoles el problema. Utilice el botón de engranaje en el lado derecho junto a "Assignee".
    - Si el autor del problema no desea contribuir con una solución:
      - Deje un comentario reconociendo que el error se puede replicar.
-     - Intente solucionarlo usted mismo o agregue la etiqueta `help wanted` para señalar que es un issue que  necesita solución.
+     - Intente solucionarlo usted mismo o agregue la etiqueta `help wanted` para señalar que es un "issue"que necesita solución.
 3. Si el error no se puede replicar:
-   - Solicite información adicional si aún no se ha proporcionado en la plantilla (versión de p5.js, versión del navegador, versión del sistema operativo, etc.)(p5.js version, browser version, OS version, etc.).
-   - Si su entorno de prueba difiere de lo que se informa en el problema(issue) (por ejemplo, un navegador o sistema operativo diferente)(e.g., a different browser or OS):
+   - Solicite información adicional si aún no se ha proporcionado en la plantilla (versión de p5.js, versión del navegador, versión del sistema operativo, etc).
+   - Si su entorno de prueba difiere de lo que se informa en el "issue"(por ejemplo, un navegador o sistema operativo diferente):
      - Deje un comentario diciendo que no puede replicar en su entorno específico.
-     - Agregue una etiqueta `help wanted` al problema(issue) y pida a alguien más con la configuración especificada en el problema que intente replicar el error.
-   - Sometimes, bugs only occur when using the web editor and not when testing locally. In this case, the issue should be redirected to the 
-   - A veces, los errores solo ocurren al usar el editor web (web editor) y no al probar localmente. En este caso, el problema debería ser redirigido al repositorio del editor web [web editor repo](https://github.com/processing/p5.js-web-editor).
+     - Agregue una etiqueta `help wanted` al "issue" incidente y pida a alguien más con la configuración especificada en el"issue" que intente replicar el error.
+   - A veces, los "bugs"(errores) solo ocurren al usar el editor web y no al probar localmente. En este caso, el problema debería ser redirigido al [repositorio del editor web](https://github.com/processing/p5.js-web-editor).
    - Si la replicación es posible más tarde, regrese al paso 2.
 4. Si el error se origina en el código que el usuario proporcionó en el informe de error y no en el comportamiento de p5.js:
    - Determine si la documentación de p5.js, la implementación de código o el sistema de errores amigable pueden mejorarse para evitar que se cometa el mismo error.
-   - Redirija amablemente cualquier pregunta adicional al foro [forum](https://discourse.processing.org/)  o al Discord [Discord](https://discord.com/invite/SHQ8dH25r9) y cierre el issue si no se van a realizar más cambios en p5.js.
+   - Redirija amablemente cualquier pregunta adicional al [foro](https://discourse.processing.org/)  o al [Discord](https://discord.com/invite/SHQ8dH25r9) y cierre el "issue" si no se van a realizar más cambios en p5.js.
    
 
 
-### Solicitud de función (Feature request)
+### "Feature request" (solicitud de función)
 
-Los issues/problemas de solicitudes de función (Feature request issues) deberían utilizar la plantilla de problema(issue) "Nueva Solicitud de Función" ("New Feature Request") . El siguiente flujo de trabajo es típico para abordar las solicitudes de función:"
+Los "issues" de solicitudes de función deberían utilizar la plantilla issue "New Feature Request"(Nueva Solicitud de Función). El siguiente flujo de trabajo es típico para abordar las solicitudes de función:
 
-1. Como parte del compromiso de p5.js de aumentar el acceso, una solicitud de función(feature request) debe justificar cómo aumenta el acceso de p5.js a comunidades que históricamente han sido marginadas en el campo. Más detalles están disponibles aquí[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.
+1. Como parte del compromiso de p5.js de aumentar el acceso, una solicitud de función debe justificar cómo aumenta el acceso de p5.js a comunidades que históricamente han sido marginadas en el campo. Más detalles están disponibles [aquí](access.md).
    - Si una solicitud de función(feature request) no tiene suficientemente completado el campo "Aumento de Acceso"("Increasing Access"), puedes preguntar al autor del problema(issue autor) cómo la función(feature) aumenta el acceso.
    - La declaración de acceso de una función puede ser proporcionada por un miembro diferente de la comunidad, incluidos los revisores de problemas(issue reviewers).
-1. La nueva solicitud de función puede ser evaluada para su inclusión en base a los siguientes criterios:
-   - ¿La función(feature) encaja en el alcance del proyecto y los principios de diseño [design principles](design_principles.md) de p5.js?
-     - Por ejemplo, una solicitud para agregar una nueva forma primitiva de dibujo puede ser considerada, pero una solicitud para adoptar un protocolo de Internet de las cosas basado en el navegador (browser-based IOT protocol) probablemente estará fuera de alcance.
+2. La nueva solicitud de función puede ser evaluada para su inclusión en base a los siguientes criterios:
+   - ¿La función encaja en el alcance del proyecto y los principios de diseño [design principles](design_principles.md) de p5.js?
+     - Por ejemplo, una solicitud para agregar una nueva forma primitiva de dibujo puede ser considerada, pero una solicitud para adoptar un protocolo de Internet de las cosas basado en el navegador probablemente estará fuera de alcance.
      - En general, el alcance de p5.js debería ser relativamente estrecho para evitar un exceso de características poco utilizadas.
-     - Si una función no encaja en el alcance de p5.js, sugiere al autor del problema(issue) que implemente la función(feature) como una biblioteca complementaria(addon library).
+     - Si una función no encaja en el alcance de p5.js, sugiere al autor del problema(issue) que implemente la función como una biblioteca complementaria.
      - Si no está claro si encaja o no, puede ser una buena idea sugerir hacer una biblioteca complementaria(addon library)como una prueba de concepto(proof-of-concept).Esto ayuda a dar a los usuarios una forma de usar la función(feature), proporciona un ejemplo mucho más concreto de su uso e importancia, y no necesariamente necesita ser una solución tan completa como una función completamente integrada. Puede integrarse en el núcleo(the core) de p5.js más adelante si corresponde. 
    - ¿Es probable que la función(feature) propuesta cause un cambio incompatible?
      - ¿Entrará en conflicto con las funciones y variables existentes de p5.js?
      - ¿Entrará en conflicto con los bocetos típicos(typical sketches) ya escritos para p5.js?
-     - Las funciones que probablemente causen conflictos, como las mencionadas anteriormente, se consideran cambios incompatibles(breaking changes). Sin un lanzamiento de versión mayor a [major version release](https://docs.npmjs.com/about-semantic-versioning), no deberíamos realizar cambios incompatibles en p5.js.
-   - ¿Se puede lograr la nueva función propuesta utilizando las funcionalidades existentes ya en p5.js, código JavaScript nativo relativamente simple, o bibliotecas existentes fáciles de usar(existing easy-to-use libraries)?
+     - Las funciones que probablemente causen conflictos, como las mencionadas anteriormente, se consideran cambios incompatibles. Sin un lanzamiento de [Lanzamiento de versión mayor](https://docs.npmjs.com/about-semantic-versioning), no deberíamos realizar cambios incompatibles en p5.js.
+   - ¿Se puede lograr la nueva función propuesta utilizando las funcionalidades existentes ya en p5.js, código JavaScript nativo relativamente simple, o bibliotecas existentes fáciles de usar?
      - Por ejemplo, en lugar de proporcionar una función de p5.js para unir una matriz de cadenas (array of strings) como `join(["Hello", "world!"])`, debería preferirse el JavaScript nativo  `["Hello", "world!"].join()`.
-2. Si el requisito de acceso y otras consideraciones han sido cumplidas, al menos dos administradores o mantenedores deben aprobar la nueva solicitud de función(feature request) antes de que comience el trabajo hacia una PR. El proceso de revisión de PR para nuevas funciones está documentado a continuación.
+3. Si el requisito de acceso y otras consideraciones han sido cumplidas, al menos dos administradores o mantenedores deben aprobar la nueva solicitud de función antes de que comience el trabajo hacia una PR. El proceso de revisión de PR para nuevas funciones está documentado a continuación.
 
 
-### Mejora de función (Feature enhancement)
+### "Feature enhancement" (Mejora de funciones)
 
-Las solicitudes(issues) de mejora de función deberían utilizar la plantilla de problema(issue template) "Mejora de Función Existente"("Existing Feature Enhancement"). El proceso es muy similar a las solicitudes de nuevas funciones. La diferencia entre una solicitud de nueva función(new feature request) y una mejora de función puede ser confusa a veces. La mejora de función principalmente trata sobre las funciones existentes de p5.js, mientras que una solicitud de nueva función podría estar solicitando la adición de funciones completamente nuevas.
+Las solicitudes de issues de mejora de función deberían utilizar la plantilla de incidentes de "Existing Feature Enhancement" (Mejora de Funciones Existentes). El proceso es muy similar a las solicitudes de nuevas funciones. La diferencia entre una "new feature request" (solicitud de nueva función) y una "feature request" (Mejora de Función) puede ser confusa a veces. La mejora de función principalmente trata sobre las funciones existentes de p5.js, mientras que una solicitud de nueva función podría estar solicitando la adición de funciones completamente nuevas.
 
-1. Similar a las solicitudes de nuevas funciones(new feature), las mejoras de función(feature enhancement) solo deben ser aceptadas si aumentan el acceso a p5.js. Por favor, consulta el punto 1 de la sección anterior[section above](steward_guidelines.md#feature-request).
+1. Similar a las solicitudes de nuevas funciones, las mejoras de función solo deben ser aceptadas si aumentan el acceso a p5.js. Por favor, consulta el punto 1 de la [sección anterior](steward_guidelines.md#feature-request).
 2. Los criterios de inclusión para las mejoras de función son similares a los de las solicitudes de nuevas funciones, pero se debe prestar especial atención a los posibles cambios incompatibles.
    - Si se están modificando funciones existentes, todas las firmas de funciones válidas y documentadas previamente deben comportarse de la misma manera.
-3. Las mejoras de funciones deben ser aprobadas por al menos un administrador o mantenedor antes de que comience el trabajo hacia una PR (solicitud de extracción). El proceso de revisión de PR para mejoras de funciones está documentado a continuación.
+3. Las mejoras de funciones deben ser aprobadas por al menos un administrador o mantenedor antes de que comience el trabajo hacia una PR. El proceso de revisión de PR para mejoras de funciones está documentado a continuación.
 
 
 ### Discusión
 
-Este tipo de problema tiene una plantilla(template) mínima ("Discusión") y debería ser utilizada para recopilar comentarios(retroalimentaciones/feedback) sobre un tema en general antes de consolidarlo en algo más específico, como una solicitud de función(feature request). Estos problemas(issues) de discusión pueden cerrarse cuando finaliza la conversación y se han creado los problemas más específicos resultantes:
+Este tipo de issue tiene una plantilla mínima de discusión y debería ser utilizada para recopilar comentarios y retroalimentaciones sobre un tema en general antes de consolidarlo en algo más específico, como una solicitud de función. Estos "issues" de discusión pueden cerrarse cuando finaliza la conversación y se han creado los "issues" más específicos resultantes:
 
-- Si se abre un issue como una discusión pero debería ser, por ejemplo, un informe de error(bug report), se debe aplicar la etiqueta correcta y quitar la etiqueta de "discusión". Además, se debe solicitar información adicional sobre el error al autor si aún no se ha incluido.
-- Si se abre un problema como una discusión pero no es relevante para la contribución de código fuente o de otra manera relevante para los repositorios de GitHub/el proceso de contribución/la comunidad de contribución, deberían ser redirigidos al foro o a Discord y el problema cerrado.
-- Si es relevante, se deben agregar etiquetas adicionales a los issues de discusión para señalar aún más qué tipo de discusión es con solo mirarla.
+- Si se abre un "issue" como una discusión pero debería ser, por ejemplo, un "bug report"(informe de error), se debe aplicar la etiqueta correcta y quitar la etiqueta de "discusión". Además, se debe solicitar información adicional sobre el error al autor si aún no se ha incluido.
+- Si se abre un issue como una discusión pero no es relevante para la contribución de código fuente o de otra manera relevante para los repositorios de GitHub/el proceso de contribución/la comunidad de contribución, deberían ser redirigidos al foro o a Discord y el problema cerrado.
+- Si es relevante, se deben agregar etiquetas adicionales a los "issues" de discusión para señalar aún más qué tipo de discusión es con solo mirarla.
 
 ---
 
 
-## Pull Requests
+## "Pull Requests"
 
-Casi todas las contribuciones de código a los repositorios de p5.js se realizan a través de solicitudes de extracción(Pull Request). Los administradores y mantenedores pueden tener acceso de escritura(push access) a los repositorios, pero aún se les anima a seguir el mismo proceso de issue > PR > proceso de revisión al contribuir con código. Aquí están los pasos para revisar una PR:
+Casi todas las contribuciones de código a los repositorios de p5.js se realizan a través de Pull Request. Los administradores y los encargados de mantenimiento pueden tener "push access" (acceso de escritura) a los repositorios, pero aún se les anima a seguir el mismo proceso de issue > PR > proceso de revisión al contribuir con código. Aquí están los pasos para revisar una PR:
 
-- La plantilla de solicitud de extracción(pull request template) se puede encontrar [here](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md).
-- Casi todas las solicitudes de extracción(pull requests ) deben tener problemas asociados abiertos y discutidos primero, lo que significa que los relevantes [issue workflow](steward_guidelines.md#issues) deben haber sido seguidos primero antes de que una PR sea revisada por cualquier administrador o mantenedor.
-  - Las únicas instancias donde esto no se aplica son correcciones muy menores de errores tipográficos(minor typo fixes), las cuales no requieren un problema abierto y pueden ser fusionadas(merged) por cualquier persona con acceso para fusionar(merge access) al repositorio, incluso si no son administradores de una área en particular.
-  - Si bien esta excepción existe, la aplicaremos en la práctica solo mientras se siga alentando a los contribuyentes a abrir nuevos problemas primero. En otras palabras, si tienes dudas sobre si esta excepción se aplica, simplemente abre un issue de todos modos.
-- Si una solicitud de extracción (pull request) no resuelve completamente el issue referenciado, puedes editar la publicación original y cambiar "Resolves #OOOO" a "Addresses #OOOO" para que no cierre automáticamente el problema original cuando la PR se fusione(merge).
+- La plantilla de pull request se puede encontrar [Aquî](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md).
+- Casi todas las solicitudes de pull requests deben tener problemas asociados abiertos y discutidos primero, lo que significa que los relevantes ["issue workflow"](steward_guidelines.md#issues) deben haber sido seguidos primero antes de que una PR sea revisada por cualquier administrador o encargado de mantenimiento.
+  - Las únicas instancias donde esto no se aplica son correcciones muy menores de errores tipográficos, las cuales no requieren un "issue" abierto y pueden ser fusionadas por cualquier persona con acceso para aplicar "merge" (fusionar) al repositorio, incluso si no son administradores de una área en particular.
+  - Si bien esta excepción existe, la aplicaremos en la práctica solo mientras se siga alentando a los contribuyentes a abrir nuevos "issues" primero. En otras palabras, si tienes dudas sobre si esta excepción se aplica, simplemente abre un "issue" de todos modos.
+- Si una "pull request"no resuelve completamente el "issue" referenciado, puedes editar la publicación original y cambiar "Resolves #OOOO" a "Addresses #OOOO" para que no cierre automáticamente el problema original cuando la PR aplique "merge" (se fusione).
 
 
-### Solución sencilla (Simple fix)
+### "Simple fix" (arreglo simple/soluciøn sencilla)
 
-Las correcciones simples(simple fix), como la corrección de un pequeño error tipográfico, pueden fusionarse(merge) directamente por cualquier persona con acceso para fusionar(aplicar merge). Verifica en la pestaña "Files Changed" de la PR para asegurarte de que la prueba automatizada de integración continua (CI) pase.
+Los "simple fix", como la corrección de un pequeño error tipográfico, pueden "be merged" (fusionarse) directamente por cualquier persona con acceso para aplicar "merge"(fusionar). Verifica en la pestaña "Files Changed" de la PR para asegurarte de que la prueba automatizada de integración continua (CI) pase.
 
-![The "files changed" tab when viewing a pull request on GitHub](images/files-changed.png)
+![La pestaña "File changed" al ver una solicitud de extracción en 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)
+![El indicador "All checks have passed" en una solicitud de PR  de GitHub, resaltado encima del botón de fusión](images/all-checks-passed.png)
 
 
-### Corrección de error (Bug fix) Seguir desde aqui.
+### "Bug fix" (Corrección de error) 
 
-1. Bug fixes deberían ser revisado por el administrador del área relevante, idealmente el mismo que aprobó el issue referenciado para su corrección.
-2. La pestaña "Files Changed" de la PR se puede utilizar para revisar inicialmente si la corrección (el fix)se implementa según lo descrito en la discusión del issue.
-3. El PR Debería ser probado localmente siempre que sea posible y relevante. El GitHub CLI puede ayudar a agilizar parte del proceso. (Ver más abajo en [Tips & Tricks](steward_guidelines.md#tips-tricks)).
-   - [ ] El fix debe abordar suficientemente el problema original.
-   - [ ] El fix no debe cambiar ningún comportamiento existente a menos que se acuerde en el problema original.
-   - [ ] El fix no debe tener un impacto significativo en el rendimiento de p5.js.
-   - [ ] El fix no debe tener ningún impacto en la accesibilidad de p5.js.
-   - [ ] El fix debe utilizar el estándar moderno de codificación en JavaScript.
-   - [ ] El fix debe pasar todas las pruebas automatizadas e incluir nuevas pruebas(tests) si son relevantes.
-4. Si se requieren cambios adicionales, se deben agregar comentarios en línea a las líneas relevantes según se describió anteriormente [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).
+1. "Bug fixes" deberían ser revisado por el administrador del área relevante, idealmente el mismo que aprobó el "issue" referenciado para su corrección.
+2. La pestaña "Files Changed" de la PR se puede utilizar para revisar inicialmente si el "fix" se implementa según lo descrito en la discusión del issue.
+3. El PR Debería ser probado localmente siempre que sea posible y relevante. El GitHub CLI puede ayudar a agilizar parte del proceso. Ver más abajo en [Consejos y trucos](steward_guidelines.md#tips-tricks).
+   - [ ] El "fix"(Corrección) debe abordar suficientemente el problema original.
+   - [ ] El "fix" no debe cambiar ningún comportamiento existente a menos que se acuerde en el problema original.
+   - [ ] El "fix" no debe tener un impacto significativo en el rendimiento de p5.js.
+   - [ ] El "fix" no debe tener ningún impacto en la accesibilidad de p5.js.
+   - [ ] El "fix" debe utilizar el estándar moderno de codificación en JavaScript.
+   - [ ] El "fix" debe pasar todas las pruebas automatizadas e incluir nuevas pruebas(tests) si son relevantes.
+4. Si se requieren cambios adicionales, se deben agregar comentarios en línea a las líneas relevantes según se describió anteriormente [aquí](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).
    - Un bloque de sugerencias también puede ser usado para sugerir cambios específicos:\
-     ![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)
-   - Si se requieren múltiples cambios, no agregues comentarios de una sola línea muchas veces. En su lugar, sigue el procedimiento documentado [here](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request) para hacer comentarios de varias líneas y una sola solicitud de cambios (change request).
+     ![El botón "Suggest Change " al escribir un comentario sobre el código en una solicitud de pull request de GitHub](images/suggest-change.png)\
+     ![Un cambio sugerido que aparece dentro de bloques de código con la etiqueta "suggestion"](images/suggested-value-change.png)\
+     ![Un cambio sugerido previsualizado como una diferencia (diff)](images/suggestion-preview.png)
+   - Si se requieren múltiples cambios, no agregues comentarios de una sola línea muchas veces. En su lugar, sigue el procedimiento documentado [aquí](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request) para hacer comentarios de varias líneas y una sola solicitud de cambios (change request).
    - Si los comentarios en línea son solo para aclaraciones o discusión, elige "Comment" en lugar de "Request changes":\
-     ![The "comment" option circled within the GitHub Finish Review menu](images/comment-review.png)
-5. Una vez que la PR haya sido revisada y no se requieran cambios adicionales, un administrador puede marcar la PR como "Approved" eligiendo la opción "Approve" en el paso anterior, con o sin comentarios adicionales. El administrador puede luego solicitar una revisión adicional por otro administrador o mantenedor si lo desea, fusionar(merge) la PR si tiene acceso para fusionar(merge access), o solicitar una fusión (request/solicitar merge) de un mantenedor.
+     ![La opción "coment" marcada dentro del menú "Finish Review" de GitHub](images/comment-review.png)
+5. Una vez que la PR haya sido revisada y no se requieran cambios adicionales, un administrador puede marcar la PR como "Aprobada" eligiendo la opción "Approve" en el paso anterior, con o sin comentarios adicionales. El administrador puede luego solicitar una revisión adicional por otro administrador o encargado de mantenimiento si lo desea, fusionar(merge) la PR si tiene acceso para fusionar(merge access), o solicitar "merge" (fusión) de un encargado de mantenimiento.
 6. @[all-contributors](https://allcontributors.org/docs/en/emoji-key)El bot debería ser llamado para agregar cualquier nuevo colaborador a la lista de colaboradores en el archivo README.md. Cada tipo de contribución puede ser indicado en lugar de `[contribution` `type]` a continuación, se puede encontrar la lista completa de tipos de contribuciones disponibles en el enlace anterior.
 
 `@all-contributors` `please` `add` `@[GitHub` `handle]` `for` `[contribution` `type]`
 
 
-### Nueva función/mejora de función (New feature/feature enhancement()
+### "New feature/feature enhancement" (Nueva función/mejora de función)
 
-El proceso para una nueva función o mejora de función en una PR es similar a la de correcciones de errores(bug fixes) con una diferencia notable:
+El proceso para una nueva función o mejora de función en una PR es similar a la de "bug fixes" (correcciones de errores) con una diferencia notable:
 
-- Una PR de nueva función(new feature) o mejora de función(feature enhancement) debe ser revisada y aprobada por al menos dos administradores o mantenedores antes de que pueda fusionarse (be merged).
+- Una PR de nueva función o mejora de función debe ser revisada y aprobada por al menos dos administradores o mantenedores antes de que pueda ser fusionada.
 
 
 ### Dependabot
 
 Las PRs de Dependabot generalmente solo son visibles para los administradores del repositorio, así que si esto no aplica a ti, por favor omite esta sección.
 
-- Las PRs de Dependabot pueden fusionarse(be merged) directamente si la actualización de la versión es una [semver](https://semver.org/) versión de parche( patch version) y la prueba automatizada de CI(CI test ) ha pasado.
-- Las PRs de Dependabot con cambios de versión semver menor generalmente se pueden fusionar directamente siempre y cuando la prueba automatizada de CI pase. Se recomienda hacer una rápida verificación en el registro de cambios(changelog ) de la dependencia actualizada.
+- Las PRs de Dependabot pueden fusionarse directamente si la actualización de la versión es una [semver](https://semver.org/) versión de parche y la prueba automatizada de CI ha pasado.
+- Las PRs de Dependabot con cambios de versión semver menor generalmente se pueden fusionar directamente siempre y cuando la prueba automatizada de CI pase. Se recomienda hacer una rápida verificación en el registro de cambios de la dependencia actualizada.
 - Las PRs de Dependabot con cambios de versión semver mayor probablemente afectarán el proceso de compilación o las funcionalidades de p5.js. En este caso, se anima al revisor a revisar el registro de cambios desde la versión actual hasta la versión objetivo, si es posible, y probar la PR localmente para asegurarse de que todos los procesos estén funcionando y realizar los cambios necesarios debido a posibles cambios que puedan romper las dependencias.
   - Muchas dependencias aumentan los números de versión principales solo porque dejan de admitir versiones muy antiguas de Node.js. En muchos casos, los cambios de versión principales no necesariamente significan cambios que rompan debido a cambios en la API de la dependencia.
 

From 776238f1dce576a1201f03f263d2d7325ae7fe0d Mon Sep 17 00:00:00 2001
From: Marce <ml.008@outlook.com>
Date: Mon, 18 Mar 2024 16:47:44 -0600
Subject: [PATCH 13/19] Update steward_guidelines.md

---
 contributor_docs/es/steward_guidelines.md | 178 +++++++++++-----------
 1 file changed, 88 insertions(+), 90 deletions(-)

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
index 2fde1cfac4..44205529c0 100644
--- a/contributor_docs/es/steward_guidelines.md
+++ b/contributor_docs/es/steward_guidelines.md
@@ -1,161 +1,159 @@
 # Directrices para Administradores  
 
 
-Ya sea que recién te hayas unido a nosotros como administrador, seas un mantenedor experimentado de p5.js, o estés en algún punto intermedio, esta guía contiene información, así como consejos y trucos que te ayudarán a contribuir de manera efectiva a p5.js. La mayor parte de lo que se escribe aquí son pautas, a menos que se indique lo contrario, lo que significa que puedes adaptar las prácticas mostradas aquí para que se ajusten a tu flujo de trabajo.
+Ya sea que recién te hayas unido a nosotros como administrador, seas un responsable de mantenimiento experimentado de p5.js, o estés en algún punto intermedio, esta guía contiene información, así como consejos y trucos que te ayudarán a contribuir de manera efectiva a p5.js. La mayor parte de lo que se escribe aquí son pautas a menos que se indique lo contrario, lo que significa que puedes adaptar las prácticas mostradas aquí para que se ajusten a tu flujo de trabajo.
+
 
 ## Tabla de Contenidos
-#sugiero asegurarnos que el contenido de la tabla no se muestre en ingles en la aplicaciøn antes de traducir bug report, feature request, etc. i.e. una tab llamada new request, pero nosotros escribamos da click en la pesta;a de nueva solicitud.
 
-- [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)
+- [Issues](steward_guidelines.md#issues) 
+  - [Informe de Errores](steward_guidelines.md#informe-de-errores) 
+  - [Solicitud de Funcionalidades](steward_guidelines.md#solicitud-de-funcionalidades)
+  - [Mejora de Funcionalidades](steward_guidelines.md#mejora-de-funcionalidades)
+  - [Discusión](steward_guidelines.md#discusión) 
 - [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)
+  - [Corrección Sencilla](steward_guidelines.md#correción-sencilla)
+  - [Corrección de Error](steward_guidelines.md#corrección-de-error) 
+  - [Nuevas Funcionalidades/Mejora de Funcionalidades](steward_guidelines.md#nuevas-funcionalidades/Mejora-de-funcionalidades)
+  - [Dependabot](steward_guidelines.md#dependabot) 
+- [Proceso de Construcción](steward_guidelines.md#proceso-de-construcción)
+  - [Tarea Principal de Construcción](steward_guidelines.md#tarea-principal-de-construcción)
+  - [Tarea Variada](steward_guidelines.md#tarea-variada)
+- [Proceso de Lanzamiento](steward_guidelines.md#proceso-de-lanzamiento)
+- [Consejos y Trucos](steward_guidelines.md#tips--consejos-y-trucos)
+  - [Plantillas de Respuesta](steward_guidelines.md#plantillas-de-respuesta)
   - [GitHub CLI](steward_guidelines.md#github-cli)
-  - [Managing notifications](steward_guidelines.md#managing-notifications)
+  - [Gestión de Notificaciones](steward_guidelines.md#gestión-de-notificaciones)
 
 ---
 
 
-## Issues
+## _Issues_
 
-Alentamos a la mayoría de las contribuciones de código fuente a comenzar con un issue, y como tal, los "issues" son el lugar donde la mayoría de las discusiones tendrán lugar. Los pasos a seguir al revisar un issue dependerán del tipo de issue que sea. El repositorio utiliza Plantillas de issues de GitHub (https://github.com/processing/p5.js/blob/main/.github/ISSUE_TEMPLATE) para organizar mejor los diferentes tipos de problemas y alentar a los autores de problemas a proporcionar toda la información relevante sobre sus problemas. El primer paso al revisar el "issue" a menudo será revisar la plantilla completada y determinar si necesita información adicional por ejemplo, porque algunos campos no se completaron o se utilizó la plantilla incorrecta.
+Alentamos a la mayoría de las contribuciones de código fuente a comenzar con un _issue_, y como tal, los _issues_ son el lugar donde la mayoría de las discusiones tendrán lugar. Los pasos a seguir al revisar un _issue_ dependerán del tipo de _issue_ que sea. El repositorio utiliza [Plantillas de _issues_ de GitHub](https://github.com/processing/p5.js/blob/main/.github/ISSUE_TEMPLATE), para organizar mejor los diferentes tipos de _issues_ y alentar a los autores de _issues_ a proporcionar toda la información relevante sobre sus _issues_. El primer paso al revisar el _issue_ a menudo será revisar la plantilla completada y determinar si necesita información adicional por ejemplo, porque algunos campos no se completaron o se utilizó la plantilla incorrecta.
 
 
-### "Bug report"(informe de error)
+### Informe de Errores
 
-Los "Bug report issues" (informes de errores de issues) deberían utilizar la plantilla de Issue "Found a bug". El siguiente flujo de trabajo es típico para abordar los informes de errores:
+Los _issues_ de informes de errores deberían utilizar la plantilla de _Issue_ "Found a bug". El siguiente flujo de trabajo es típico para abordar los informes de errores:
 
 1. Replicar el error
    - El objetivo de la plantilla es proporcionar suficiente información para que un revisor intente replicar el error en cuestión.
    - Si el error reportado no es relevante para el repositorio en el que se abrió (p5.js, p5.js-website, u otro):
-     - Transfiera el problema al repositorio relevante si tiene acceso a él.
-     - De lo contrario, deje un comentario sobre dónde debería presentarse el informe de error (con un enlace directo proporcionado) y cierre el problema.
-   - El primer paso para revisar un informe de error es verificar si se proporciona suficiente información para replicar el error, y si es así, intentar replicar el error según lo descrito.
+     - Transfiera el _issue_ al repositorio relevante si tiene acceso a él.
+     - De lo contrario, deje un comentario sobre dónde debería presentarse el informe de error (con un enlace directo proporcionado) y cierre el _issue_.
+   - El primer paso para revisar un informe de error es verificar si se proporciona suficiente información para replicar el error, y si es así, se debe intentar replicar el error según lo descrito.
 2. Si el error se puede replicar:
-   - Puede ser necesario realizar alguna discusión para determinar la mejor manera de solucionar un error particular. Puede ser necesario realizar alguna discusión para determinar la mejor manera de solucionar un error particular. A veces, puede ser directo; otras veces, puede ser complicado. Por favor, consulte los [principios de diseño de p5.js](design_principles.md) al tomar esta decisión caso por caso.
-   - Si el autor del "issue" indicó en el "issue" que está dispuesto a contribuir con una solución:
-     - Apruebe el problema para su solución por parte del autor del problema dejando un comentario y asignándoles el problema. Utilice el botón de engranaje en el lado derecho junto a "Assignee".
-   - Si el autor del problema no desea contribuir con una solución:
+   - Puede ser necesario realizar alguna discusión para determinar la mejor manera de solucionar un error particular. Puede ser necesario realizar alguna discusión para determinar la mejor manera de solucionar un error particular. A veces, puede ser directo;otras veces, puede ser complicado. Por favor, consulte los [principios de diseño de p5.js](design_principles.md) al tomar esta decisión caso por caso.
+   - Si el autor del _issue_ indicó en el _issue_ que está dispuesto a contribuir con una solución:
+     - Apruebe el _issue_ para su solución por parte del autor del _issue_ dejando un comentario y asignándoles el _issue_. Utilice el botón de engranaje en el lado derecho junto a "Assignee".
+   - Si el autor del _issue_ no desea contribuir con una solución:
      - Deje un comentario reconociendo que el error se puede replicar.
-     - Intente solucionarlo usted mismo o agregue la etiqueta `help wanted` para señalar que es un "issue"que necesita solución.
+     - Intente solucionarlo usted mismo o agregue la etiqueta `help wanted` para señalar que es un _issue_ que necesita solución.
 3. Si el error no se puede replicar:
    - Solicite información adicional si aún no se ha proporcionado en la plantilla (versión de p5.js, versión del navegador, versión del sistema operativo, etc).
-   - Si su entorno de prueba difiere de lo que se informa en el "issue"(por ejemplo, un navegador o sistema operativo diferente):
+   - Si su entorno de prueba difiere de lo que se informa en el _issue_(por ejemplo,un navegador o sistema operativo diferente):
      - Deje un comentario diciendo que no puede replicar en su entorno específico.
-     - Agregue una etiqueta `help wanted` al "issue" incidente y pida a alguien más con la configuración especificada en el"issue" que intente replicar el error.
-   - A veces, los "bugs"(errores) solo ocurren al usar el editor web y no al probar localmente. En este caso, el problema debería ser redirigido al [repositorio del editor web](https://github.com/processing/p5.js-web-editor).
+     - Agregue una etiqueta `help wanted` al _issue_ incidente y pida a alguien más con la configuración especificada en el _issue_ que intente replicar el error.
+   - A veces, los "bugs"(errores) solo ocurren al usar el editor web y no al probar localmente. En este caso, el _issue_ debería ser redirigido al [repositorio del editor web](https://github.com/processing/p5.js-web-editor).
    - Si la replicación es posible más tarde, regrese al paso 2.
 4. Si el error se origina en el código que el usuario proporcionó en el informe de error y no en el comportamiento de p5.js:
    - Determine si la documentación de p5.js, la implementación de código o el sistema de errores amigable pueden mejorarse para evitar que se cometa el mismo error.
-   - Redirija amablemente cualquier pregunta adicional al [foro](https://discourse.processing.org/)  o al [Discord](https://discord.com/invite/SHQ8dH25r9) y cierre el "issue" si no se van a realizar más cambios en p5.js.
+   - Redirija amablemente cualquier pregunta adicional al [foro](https://discourse.processing.org/) o al [Discord](https://discord.com/invite/SHQ8dH25r9) y cierre el _issue_ si no se van a realizar más cambios en p5.js.
    
 
+### Solicitud de Funcionalidades
 
-### "Feature request" (solicitud de función)
-
-Los "issues" de solicitudes de función deberían utilizar la plantilla issue "New Feature Request"(Nueva Solicitud de Función). El siguiente flujo de trabajo es típico para abordar las solicitudes de función:
+Los _issues_ para solicitar funcionalidades deberían utilizar la plantilla "New Feature Request". El siguiente flujo de trabajo es típico para abordar las solicitudes de función:
 
 1. Como parte del compromiso de p5.js de aumentar el acceso, una solicitud de función debe justificar cómo aumenta el acceso de p5.js a comunidades que históricamente han sido marginadas en el campo. Más detalles están disponibles [aquí](access.md).
-   - Si una solicitud de función(feature request) no tiene suficientemente completado el campo "Aumento de Acceso"("Increasing Access"), puedes preguntar al autor del problema(issue autor) cómo la función(feature) aumenta el acceso.
-   - La declaración de acceso de una función puede ser proporcionada por un miembro diferente de la comunidad, incluidos los revisores de problemas(issue reviewers).
-2. La nueva solicitud de función puede ser evaluada para su inclusión en base a los siguientes criterios:
-   - ¿La función encaja en el alcance del proyecto y los principios de diseño [design principles](design_principles.md) de p5.js?
+   - Si una solicitud de funcionalidad no tiene suficientemente completado el campo "Increasing Access" ("Aumento de Acceso"), puedes preguntar al autor del _issue_ cómo la funcionalidad aumenta el acceso.
+   - La declaración de acceso de una funcionalidad puede ser proporcionada por un miembro diferente de la comunidad, incluidos los revisores de _issue_.
+2. Una nueva solicitud de funcionalidad puede ser evaluada para su inclusión en base a los siguientes criterios:
+   - ¿La función encaja en el alcance del proyecto y los principios de diseño [principios de diseño](design_principles.md) de p5.js?
      - Por ejemplo, una solicitud para agregar una nueva forma primitiva de dibujo puede ser considerada, pero una solicitud para adoptar un protocolo de Internet de las cosas basado en el navegador probablemente estará fuera de alcance.
      - En general, el alcance de p5.js debería ser relativamente estrecho para evitar un exceso de características poco utilizadas.
-     - Si una función no encaja en el alcance de p5.js, sugiere al autor del problema(issue) que implemente la función como una biblioteca complementaria.
-     - Si no está claro si encaja o no, puede ser una buena idea sugerir hacer una biblioteca complementaria(addon library)como una prueba de concepto(proof-of-concept).Esto ayuda a dar a los usuarios una forma de usar la función(feature), proporciona un ejemplo mucho más concreto de su uso e importancia, y no necesariamente necesita ser una solución tan completa como una función completamente integrada. Puede integrarse en el núcleo(the core) de p5.js más adelante si corresponde. 
-   - ¿Es probable que la función(feature) propuesta cause un cambio incompatible?
-     - ¿Entrará en conflicto con las funciones y variables existentes de p5.js?
-     - ¿Entrará en conflicto con los bocetos típicos(typical sketches) ya escritos para p5.js?
-     - Las funciones que probablemente causen conflictos, como las mencionadas anteriormente, se consideran cambios incompatibles. Sin un lanzamiento de [Lanzamiento de versión mayor](https://docs.npmjs.com/about-semantic-versioning), no deberíamos realizar cambios incompatibles en p5.js.
-   - ¿Se puede lograr la nueva función propuesta utilizando las funcionalidades existentes ya en p5.js, código JavaScript nativo relativamente simple, o bibliotecas existentes fáciles de usar?
-     - Por ejemplo, en lugar de proporcionar una función de p5.js para unir una matriz de cadenas (array of strings) como `join(["Hello", "world!"])`, debería preferirse el JavaScript nativo  `["Hello", "world!"].join()`.
-3. Si el requisito de acceso y otras consideraciones han sido cumplidas, al menos dos administradores o mantenedores deben aprobar la nueva solicitud de función antes de que comience el trabajo hacia una PR. El proceso de revisión de PR para nuevas funciones está documentado a continuación.
+     - Si una función no encaja en el alcance de p5.js, sugiere al autor del _issue_ que implemente la función como una biblioteca complementaria.
+     - Si no está claro si encaja o no, puede ser una buena idea sugerir hacer una biblioteca complementaria como una prueba de concepto. Esto ayuda a dar a los usuarios una forma de usar la funcionalidad, proporciona un ejemplo mucho más concreto de su uso e importancia, y no necesariamente necesita ser una solución tan completa como una función completamente integrada. Puede integrarse en el núcleo de p5.js más adelante si corresponde. 
+   - ¿Es probable que la funcionalidad propuesta cause un cambio incompatible?
+     - ¿Entrará en conflicto con las funcionalidades y variables existentes de p5.js?
+     - ¿Entrará en conflicto con los bocetos típicos ya escritos para p5.js?
+     - Las funcionalidades que probablemente causen conflictos, como las mencionadas anteriormente, se consideran cambios incompatibles. Sin un [Lanzamiento de versión mayor](https://docs.npmjs.com/about-semantic-versioning),no deberíamos realizar cambios incompatibles en p5.js.
+   - ¿Se puede lograr la nueva función propuesta utilizando las funcionalidades existentes ya en p5.js,código JavaScript nativo relativamente simple, o bibliotecas existentes fáciles de usar?
+     - Por ejemplo, en lugar de proporcionar una función de p5.js para unir una matriz de cadenas como `join(["Hello","world!"])`, debería preferirse el JavaScript nativo `["Hello","world!"].join()`.
+3. Si el requisito de acceso y otras consideraciones han sido cumplidas, al menos dos administradores o responsables de mantenimiento deben aprobar la nueva solicitud de función antes de que comience el trabajo hacia una PR. El proceso de revisión de PR para nuevas funcionalidades está documentado a continuación.
 
 
-### "Feature enhancement" (Mejora de funciones)
+### Mejora de funcionalidades
 
-Las solicitudes de issues de mejora de función deberían utilizar la plantilla de incidentes de "Existing Feature Enhancement" (Mejora de Funciones Existentes). El proceso es muy similar a las solicitudes de nuevas funciones. La diferencia entre una "new feature request" (solicitud de nueva función) y una "feature request" (Mejora de Función) puede ser confusa a veces. La mejora de función principalmente trata sobre las funciones existentes de p5.js, mientras que una solicitud de nueva función podría estar solicitando la adición de funciones completamente nuevas.
+Las solicitudes de _issues_ de mejora de función deberían utilizar la plantilla de incidentes de "Existing Feature Enhancement" (Mejora de Funcionalidades Existentes). El proceso es muy similar a las solicitudes de nuevas funcionalidades. La diferencia entre una "new feature request" (solicitud de nueva funcionalidad) y una "feature request" (Mejora de Funcionalidad) puede ser confusa a veces. La mejora de función principalmente trata sobre las funcionalidades existentes de p5.js, mientras que una solicitud de nueva función podría estar solicitando la adición de funcionalidades completamente nuevas.
 
-1. Similar a las solicitudes de nuevas funciones, las mejoras de función solo deben ser aceptadas si aumentan el acceso a p5.js. Por favor, consulta el punto 1 de la [sección anterior](steward_guidelines.md#feature-request).
-2. Los criterios de inclusión para las mejoras de función son similares a los de las solicitudes de nuevas funciones, pero se debe prestar especial atención a los posibles cambios incompatibles.
-   - Si se están modificando funciones existentes, todas las firmas de funciones válidas y documentadas previamente deben comportarse de la misma manera.
-3. Las mejoras de funciones deben ser aprobadas por al menos un administrador o mantenedor antes de que comience el trabajo hacia una PR. El proceso de revisión de PR para mejoras de funciones está documentado a continuación.
+1. Similar a las solicitudes de nuevas funcionalidades, las mejoras de función solo deben ser aceptadas si aumentan el acceso a p5.js. Por favor, consulta el punto 1 de la [sección anterior](steward_guidelines.md#feature-request).
+2. Los criterios de inclusión para las mejoras de función son similares a los de las solicitudes de nuevas funcionalidades, pero se debe prestar especial atención a los posibles cambios incompatibles.
+   - Si se están modificando funcionalidades existentes, todas las firmas de funcionalidades válidas y documentadas previamente deben comportarse de la misma manera.
+3. Las mejoras de funcionalidades deben ser aprobadas por al menos un administrador o responsable de mantenimiento antes de que comience el trabajo hacia una PR. El proceso de revisión de PR para mejoras de funcionalidades está documentado a continuación.
 
 
 ### Discusión
 
-Este tipo de issue tiene una plantilla mínima de discusión y debería ser utilizada para recopilar comentarios y retroalimentaciones sobre un tema en general antes de consolidarlo en algo más específico, como una solicitud de función. Estos "issues" de discusión pueden cerrarse cuando finaliza la conversación y se han creado los "issues" más específicos resultantes:
+Este tipo de _issue_ tiene una plantilla mínima de discusión y debería ser utilizada para recopilar comentarios y retroalimentaciones sobre un tema en general antes de consolidarlo en algo más específico, como una solicitud de función. Estos _issues_ de discusión pueden cerrarse cuando finaliza la conversación y se han creado los _issues_ más específicos resultantes:
 
-- Si se abre un "issue" como una discusión pero debería ser, por ejemplo, un "bug report"(informe de error), se debe aplicar la etiqueta correcta y quitar la etiqueta de "discusión". Además, se debe solicitar información adicional sobre el error al autor si aún no se ha incluido.
-- Si se abre un issue como una discusión pero no es relevante para la contribución de código fuente o de otra manera relevante para los repositorios de GitHub/el proceso de contribución/la comunidad de contribución, deberían ser redirigidos al foro o a Discord y el problema cerrado.
-- Si es relevante, se deben agregar etiquetas adicionales a los "issues" de discusión para señalar aún más qué tipo de discusión es con solo mirarla.
+- Si se abre un _issue_ como una discusión pero debería ser, por ejemplo, un _bug report_(informe de error), se debe aplicar la etiqueta correcta y quitar la etiqueta de "discusión". Además, se debe solicitar información adicional sobre el error al autor si aún no se ha incluido.
+- Si se abre un _issue_ como una discusión pero no es relevante para la contribución de código fuente o de otra manera relevante para los repositorios de GitHub/el proceso de contribución/la comunidad de contribución, deberían ser redirigidos al foro o a Discord y el _issue_ cerrado.
+- Si es relevante, se deben agregar etiquetas adicionales a los _issues_ de discusión para señalar aún más qué tipo de discusión es con solo mirarla.
 
 ---
 
 
-## "Pull Requests"
+## _Pull Requests_
 
-Casi todas las contribuciones de código a los repositorios de p5.js se realizan a través de Pull Request. Los administradores y los encargados de mantenimiento pueden tener "push access" (acceso de escritura) a los repositorios, pero aún se les anima a seguir el mismo proceso de issue > PR > proceso de revisión al contribuir con código. Aquí están los pasos para revisar una PR:
+Casi todas las contribuciones de código a los repositorios de p5.js se realizan a través de Pull Request. Los administradores y los responsables de mantenimiento pueden tener "push access" (acceso de escritura) a los repositorios, pero aún se les anima a seguir el mismo proceso de _issue_ > PR > proceso de revisión al contribuir con código. Aquí están los pasos para revisar una PR:
 
 - La plantilla de pull request se puede encontrar [Aquî](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md).
-- Casi todas las solicitudes de pull requests deben tener problemas asociados abiertos y discutidos primero, lo que significa que los relevantes ["issue workflow"](steward_guidelines.md#issues) deben haber sido seguidos primero antes de que una PR sea revisada por cualquier administrador o encargado de mantenimiento.
-  - Las únicas instancias donde esto no se aplica son correcciones muy menores de errores tipográficos, las cuales no requieren un "issue" abierto y pueden ser fusionadas por cualquier persona con acceso para aplicar "merge" (fusionar) al repositorio, incluso si no son administradores de una área en particular.
-  - Si bien esta excepción existe, la aplicaremos en la práctica solo mientras se siga alentando a los contribuyentes a abrir nuevos "issues" primero. En otras palabras, si tienes dudas sobre si esta excepción se aplica, simplemente abre un "issue" de todos modos.
-- Si una "pull request"no resuelve completamente el "issue" referenciado, puedes editar la publicación original y cambiar "Resolves #OOOO" a "Addresses #OOOO" para que no cierre automáticamente el problema original cuando la PR aplique "merge" (se fusione).
-
+- Casi todas las solicitudes de pull requests deben tener _issues_ asociados abiertos y discutidos primero, lo que significa que los["flujos de trabajo de los _issues_ mås relevantes ](steward_guidelines.md#issues) deben haber sido seguidos primero antes de que una PR sea revisada por cualquier administrador o responsable de mantenimiento.
+  - Las únicas instancias donde esto no se aplica son correcciones muy menores de errores tipográficos, las cuales no requieren un _issue_ abierto y pueden ser fusionadas por cualquier persona con acceso para aplicar "merge" (fusionar) al repositorio, incluso si no son administradores de una área en particular.
+  - Si bien esta excepción existe, la aplicaremos en la práctica solo mientras se siga alentando a los contribuyentes a abrir nuevos _issues_ primero. En otras palabras, si tienes dudas sobre si esta excepción se aplica, simplemente abre un _issue_ de todos modos.
+- Si una "pull request"no resuelve completamente el _issue_ referenciado, puedes editar la publicación original y cambiar "Resolves #OOOO" a "Addresses #OOOO" para que no cierre automáticamente el _issue_ original cuando la PR aplique "merge" (se fusione).
 
-### "Simple fix" (arreglo simple/soluciøn sencilla)
 
-Los "simple fix", como la corrección de un pequeño error tipográfico, pueden "be merged" (fusionarse) directamente por cualquier persona con acceso para aplicar "merge"(fusionar). Verifica en la pestaña "Files Changed" de la PR para asegurarte de que la prueba automatizada de integración continua (CI) pase.
+### Correción Sencilla
 
-![La pestaña "File changed" al ver una solicitud de extracción en GitHub](images/files-changed.png)
+Los "simple fix"(correción Sencilla), como la corrección de un pequeño error tipográfico, pueden "be merged"(fusionarse) directamente por cualquier persona con acceso para aplicar "merge"(fusionar). Verifica en la pestaña "Files Changed" de la PR para asegurarte de que la prueba automatizada de integración continua (CI) pase.
 
-![El indicador "All checks have passed" en una solicitud de PR  de GitHub, resaltado encima del botón de fusión](images/all-checks-passed.png)
+![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" (Corrección de error) 
+### Corrección de Error
 
-1. "Bug fixes" deberían ser revisado por el administrador del área relevante, idealmente el mismo que aprobó el "issue" referenciado para su corrección.
-2. La pestaña "Files Changed" de la PR se puede utilizar para revisar inicialmente si el "fix" se implementa según lo descrito en la discusión del issue.
+1. "Bug fixes"(Corrección de errores) deberían ser revisado por el administrador del área relevante, idealmente el mismo que aprobó el _issue_ referenciado para su corrección.
+2. La pestaña "Files Changed" de la PR se puede utilizar para revisar inicialmente si el _fix_ (la ccorrección) se implementa según lo descrito en la discusión del _issue_.
 3. El PR Debería ser probado localmente siempre que sea posible y relevante. El GitHub CLI puede ayudar a agilizar parte del proceso. Ver más abajo en [Consejos y trucos](steward_guidelines.md#tips-tricks).
-   - [ ] El "fix"(Corrección) debe abordar suficientemente el problema original.
-   - [ ] El "fix" no debe cambiar ningún comportamiento existente a menos que se acuerde en el problema original.
-   - [ ] El "fix" no debe tener un impacto significativo en el rendimiento de p5.js.
-   - [ ] El "fix" no debe tener ningún impacto en la accesibilidad de p5.js.
-   - [ ] El "fix" debe utilizar el estándar moderno de codificación en JavaScript.
-   - [ ] El "fix" debe pasar todas las pruebas automatizadas e incluir nuevas pruebas(tests) si son relevantes.
+   - [ ] "La Corrección" debe abordar suficientemente el _issue_ original.
+   - [ ] "La Corrección" no debe cambiar ningún comportamiento existente a menos que se acuerde en el _issue_ original.
+   - [ ] "La Corrección" no debe tener un impacto significativo en el rendimiento de p5.js.
+   - [ ] "La Corrección" no debe tener ningún impacto en la accesibilidad de p5.js.
+   - [ ] "La Corrección" debe utilizar el estándar moderno de codificación en JavaScript.
+   - [ ] "La Corrección" debe pasar todas las pruebas automatizadas e incluir nuevas pruebas(tests) si son relevantes.
 4. Si se requieren cambios adicionales, se deben agregar comentarios en línea a las líneas relevantes según se describió anteriormente [aquí](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).
    - Un bloque de sugerencias también puede ser usado para sugerir cambios específicos:\
-     ![El botón "Suggest Change " al escribir un comentario sobre el código en una solicitud de pull request de GitHub](images/suggest-change.png)\
-     ![Un cambio sugerido que aparece dentro de bloques de código con la etiqueta "suggestion"](images/suggested-value-change.png)\
-     ![Un cambio sugerido previsualizado como una diferencia (diff)](images/suggestion-preview.png)
+     ![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)
    - Si se requieren múltiples cambios, no agregues comentarios de una sola línea muchas veces. En su lugar, sigue el procedimiento documentado [aquí](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request) para hacer comentarios de varias líneas y una sola solicitud de cambios (change request).
    - Si los comentarios en línea son solo para aclaraciones o discusión, elige "Comment" en lugar de "Request changes":\
-     ![La opción "coment" marcada dentro del menú "Finish Review" de GitHub](images/comment-review.png)
-5. Una vez que la PR haya sido revisada y no se requieran cambios adicionales, un administrador puede marcar la PR como "Aprobada" eligiendo la opción "Approve" en el paso anterior, con o sin comentarios adicionales. El administrador puede luego solicitar una revisión adicional por otro administrador o encargado de mantenimiento si lo desea, fusionar(merge) la PR si tiene acceso para fusionar(merge access), o solicitar "merge" (fusión) de un encargado de mantenimiento.
+     ![The "comment" option circled within the GitHub Finish Review menu](images/comment-review.png)
+5. Una vez que la PR haya sido revisada y no se requieran cambios adicionales, un administrador puede marcar la PR como "Aprobada" eligiendo la opción "Approve" en el paso anterior, con o sin comentarios adicionales. El administrador puede luego solicitar una revisión adicional por otro administrador o responsable de mantenimiento si lo desea, fusionar(merge) la PR si tiene acceso para fusionar(merge access), o solicitar "merge" (fusión) de un responsable de mantenimiento.
 6. @[all-contributors](https://allcontributors.org/docs/en/emoji-key)El bot debería ser llamado para agregar cualquier nuevo colaborador a la lista de colaboradores en el archivo README.md. Cada tipo de contribución puede ser indicado en lugar de `[contribution` `type]` a continuación, se puede encontrar la lista completa de tipos de contribuciones disponibles en el enlace anterior.
 
 `@all-contributors` `please` `add` `@[GitHub` `handle]` `for` `[contribution` `type]`
 
 
-### "New feature/feature enhancement" (Nueva función/mejora de función)
+### Nuevas funcionalidades/Mejora de Funcionalidades
 
-El proceso para una nueva función o mejora de función en una PR es similar a la de "bug fixes" (correcciones de errores) con una diferencia notable:
+El proceso para una PR de _new feature_ (nuevas funcionalidades),o _feature_enhacement_(mejora de funcionalidades) es similar a las correcciones de errores,pero solo con una diferencia notable:
 
-- Una PR de nueva función o mejora de función debe ser revisada y aprobada por al menos dos administradores o mantenedores antes de que pueda ser fusionada.
+- Una PR de nueva funcionalidad o mejora de funcionalidad debe ser revisada y aprobada por al menos dos administradores o responsables de mantenimiento antes de que pueda ser fusionada.
 
 
 ### Dependabot
@@ -164,8 +162,8 @@ Las PRs de Dependabot generalmente solo son visibles para los administradores de
 
 - Las PRs de Dependabot pueden fusionarse directamente si la actualización de la versión es una [semver](https://semver.org/) versión de parche y la prueba automatizada de CI ha pasado.
 - Las PRs de Dependabot con cambios de versión semver menor generalmente se pueden fusionar directamente siempre y cuando la prueba automatizada de CI pase. Se recomienda hacer una rápida verificación en el registro de cambios de la dependencia actualizada.
-- Las PRs de Dependabot con cambios de versión semver mayor probablemente afectarán el proceso de compilación o las funcionalidades de p5.js. En este caso, se anima al revisor a revisar el registro de cambios desde la versión actual hasta la versión objetivo, si es posible, y probar la PR localmente para asegurarse de que todos los procesos estén funcionando y realizar los cambios necesarios debido a posibles cambios que puedan romper las dependencias.
-  - Muchas dependencias aumentan los números de versión principales solo porque dejan de admitir versiones muy antiguas de Node.js. En muchos casos, los cambios de versión principales no necesariamente significan cambios que rompan debido a cambios en la API de la dependencia.
+- Los PR de Dependabot con cambios de versión principal de semver pueden afectar probablemente el proceso de compilación o las funcionalidades de p5.js. Se anima al revisor, en este caso, a revisar el registro de cambios desde la versión actual hasta la versión objetivo si es posible y probar el PR localmente para asegurarse de que todos los procesos estén funcionando y realizar cualquier cambio necesario debido a posibles cambios disruptivos en las dependencias.
+- Muchas dependencias aumentan los números de versión principales solo porque dejan de admitir oficialmente versiones muy antiguas de Node.js. En muchos casos, los cambios de versión principal no necesariamente implican cambios disruptivos resultantes de cambios en la API de dependencias.
 
 ---
 

From 41e99625c956304352a0153c2c2c12ad0072e617 Mon Sep 17 00:00:00 2001
From: Marce <ml.008@outlook.com>
Date: Mon, 18 Mar 2024 17:05:36 -0600
Subject: [PATCH 14/19] Update steward_guidelines.md

Adding _sketches_
---
 contributor_docs/es/steward_guidelines.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
index 44205529c0..bc41f4b81a 100644
--- a/contributor_docs/es/steward_guidelines.md
+++ b/contributor_docs/es/steward_guidelines.md
@@ -77,7 +77,7 @@ Los _issues_ para solicitar funcionalidades deberían utilizar la plantilla "New
      - Si no está claro si encaja o no, puede ser una buena idea sugerir hacer una biblioteca complementaria como una prueba de concepto. Esto ayuda a dar a los usuarios una forma de usar la funcionalidad, proporciona un ejemplo mucho más concreto de su uso e importancia, y no necesariamente necesita ser una solución tan completa como una función completamente integrada. Puede integrarse en el núcleo de p5.js más adelante si corresponde. 
    - ¿Es probable que la funcionalidad propuesta cause un cambio incompatible?
      - ¿Entrará en conflicto con las funcionalidades y variables existentes de p5.js?
-     - ¿Entrará en conflicto con los bocetos típicos ya escritos para p5.js?
+     - ¿Entrará en conflicto con los _sketches_ (bocetos) típicos ya escritos para p5.js?
      - Las funcionalidades que probablemente causen conflictos, como las mencionadas anteriormente, se consideran cambios incompatibles. Sin un [Lanzamiento de versión mayor](https://docs.npmjs.com/about-semantic-versioning),no deberíamos realizar cambios incompatibles en p5.js.
    - ¿Se puede lograr la nueva función propuesta utilizando las funcionalidades existentes ya en p5.js,código JavaScript nativo relativamente simple, o bibliotecas existentes fáciles de usar?
      - Por ejemplo, en lugar de proporcionar una función de p5.js para unir una matriz de cadenas como `join(["Hello","world!"])`, debería preferirse el JavaScript nativo `["Hello","world!"].join()`.

From d477312c61a5de790c9b5f2905a009383f78404d Mon Sep 17 00:00:00 2001
From: Marce <ml.008@outlook.com>
Date: Mon, 18 Mar 2024 19:35:09 -0600
Subject: [PATCH 15/19] Update steward_guidelines.md

Replacing PR by _pull request_
---
 contributor_docs/es/steward_guidelines.md | 30 +++++++++++------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
index bc41f4b81a..987374d8fd 100644
--- a/contributor_docs/es/steward_guidelines.md
+++ b/contributor_docs/es/steward_guidelines.md
@@ -81,7 +81,7 @@ Los _issues_ para solicitar funcionalidades deberían utilizar la plantilla "New
      - Las funcionalidades que probablemente causen conflictos, como las mencionadas anteriormente, se consideran cambios incompatibles. Sin un [Lanzamiento de versión mayor](https://docs.npmjs.com/about-semantic-versioning),no deberíamos realizar cambios incompatibles en p5.js.
    - ¿Se puede lograr la nueva función propuesta utilizando las funcionalidades existentes ya en p5.js,código JavaScript nativo relativamente simple, o bibliotecas existentes fáciles de usar?
      - Por ejemplo, en lugar de proporcionar una función de p5.js para unir una matriz de cadenas como `join(["Hello","world!"])`, debería preferirse el JavaScript nativo `["Hello","world!"].join()`.
-3. Si el requisito de acceso y otras consideraciones han sido cumplidas, al menos dos administradores o responsables de mantenimiento deben aprobar la nueva solicitud de función antes de que comience el trabajo hacia una PR. El proceso de revisión de PR para nuevas funcionalidades está documentado a continuación.
+3. Si el requisito de acceso y otras consideraciones han sido cumplidas, al menos dos administradores o responsables de mantenimiento deben aprobar la nueva solicitud de función antes de que comience el trabajo hacia una PR. El proceso de revisión de _pull request_ para nuevas funcionalidades está documentado a continuación.
 
 
 ### Mejora de funcionalidades
@@ -91,7 +91,7 @@ Las solicitudes de _issues_ de mejora de función deberían utilizar la plantill
 1. Similar a las solicitudes de nuevas funcionalidades, las mejoras de función solo deben ser aceptadas si aumentan el acceso a p5.js. Por favor, consulta el punto 1 de la [sección anterior](steward_guidelines.md#feature-request).
 2. Los criterios de inclusión para las mejoras de función son similares a los de las solicitudes de nuevas funcionalidades, pero se debe prestar especial atención a los posibles cambios incompatibles.
    - Si se están modificando funcionalidades existentes, todas las firmas de funcionalidades válidas y documentadas previamente deben comportarse de la misma manera.
-3. Las mejoras de funcionalidades deben ser aprobadas por al menos un administrador o responsable de mantenimiento antes de que comience el trabajo hacia una PR. El proceso de revisión de PR para mejoras de funcionalidades está documentado a continuación.
+3. Las mejoras de funcionalidades deben ser aprobadas por al menos un administrador o responsable de mantenimiento antes de que comience el trabajo hacia una _pull request_. El proceso de revisión de _pull request_ para mejoras de funcionalidades está documentado a continuación.
 
 
 ### Discusión
@@ -107,18 +107,18 @@ Este tipo de _issue_ tiene una plantilla mínima de discusión y debería ser ut
 
 ## _Pull Requests_
 
-Casi todas las contribuciones de código a los repositorios de p5.js se realizan a través de Pull Request. Los administradores y los responsables de mantenimiento pueden tener "push access" (acceso de escritura) a los repositorios, pero aún se les anima a seguir el mismo proceso de _issue_ > PR > proceso de revisión al contribuir con código. Aquí están los pasos para revisar una PR:
+Casi todas las contribuciones de código a los repositorios de p5.js se realizan a través de Pull Request. Los administradores y los responsables de mantenimiento pueden tener "push access" (acceso de escritura) a los repositorios, pero aún se les anima a seguir el mismo proceso de _issue_ > _pull request_ > proceso de revisión al contribuir con código. Aquí están los pasos para revisar una _pull request_:
 
 - La plantilla de pull request se puede encontrar [Aquî](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md).
-- Casi todas las solicitudes de pull requests deben tener _issues_ asociados abiertos y discutidos primero, lo que significa que los["flujos de trabajo de los _issues_ mås relevantes ](steward_guidelines.md#issues) deben haber sido seguidos primero antes de que una PR sea revisada por cualquier administrador o responsable de mantenimiento.
+- Casi todas las solicitudes de pull requests deben tener _issues_ asociados abiertos y discutidos primero, lo que significa que los["flujos de trabajo de los _issues_ mås relevantes ](steward_guidelines.md#issues) deben haber sido seguidos primero antes de que una _pull request_ sea revisada por cualquier administrador o responsable de mantenimiento.
   - Las únicas instancias donde esto no se aplica son correcciones muy menores de errores tipográficos, las cuales no requieren un _issue_ abierto y pueden ser fusionadas por cualquier persona con acceso para aplicar "merge" (fusionar) al repositorio, incluso si no son administradores de una área en particular.
   - Si bien esta excepción existe, la aplicaremos en la práctica solo mientras se siga alentando a los contribuyentes a abrir nuevos _issues_ primero. En otras palabras, si tienes dudas sobre si esta excepción se aplica, simplemente abre un _issue_ de todos modos.
-- Si una "pull request"no resuelve completamente el _issue_ referenciado, puedes editar la publicación original y cambiar "Resolves #OOOO" a "Addresses #OOOO" para que no cierre automáticamente el _issue_ original cuando la PR aplique "merge" (se fusione).
+- Si una "pull request"no resuelve completamente el _issue_ referenciado, puedes editar la publicación original y cambiar "Resolves #OOOO" a "Addresses #OOOO" para que no cierre automáticamente el _issue_ original cuando la _pull request_ aplique _merge_ (se fusione).
 
 
 ### Correción Sencilla
 
-Los "simple fix"(correción Sencilla), como la corrección de un pequeño error tipográfico, pueden "be merged"(fusionarse) directamente por cualquier persona con acceso para aplicar "merge"(fusionar). Verifica en la pestaña "Files Changed" de la PR para asegurarte de que la prueba automatizada de integración continua (CI) pase.
+Los "simple fix"(correción Sencilla), como la corrección de un pequeño error tipográfico, pueden "be merged"(fusionarse) directamente por cualquier persona con acceso para aplicar "merge"(fusionar). Verifica en la pestaña "Files Changed" de la _pull request_ para asegurarte de que la prueba automatizada de integración continua (CI) pase.
 
 ![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)
@@ -127,8 +127,8 @@ Los "simple fix"(correción Sencilla), como la corrección de un pequeño error
 ### Corrección de Error
 
 1. "Bug fixes"(Corrección de errores) deberían ser revisado por el administrador del área relevante, idealmente el mismo que aprobó el _issue_ referenciado para su corrección.
-2. La pestaña "Files Changed" de la PR se puede utilizar para revisar inicialmente si el _fix_ (la ccorrección) se implementa según lo descrito en la discusión del _issue_.
-3. El PR Debería ser probado localmente siempre que sea posible y relevante. El GitHub CLI puede ayudar a agilizar parte del proceso. Ver más abajo en [Consejos y trucos](steward_guidelines.md#tips-tricks).
+2. La pestaña "Files Changed" de la _pull request_ se puede utilizar para revisar inicialmente si el _fix_ (la ccorrección) se implementa según lo descrito en la discusión del _issue_.
+3. La _pull request_ Debería ser probada localmente siempre que sea posible y relevante. El GitHub CLI puede ayudar a agilizar parte del proceso. Ver más abajo en [Consejos y trucos](steward_guidelines.md#tips-tricks).
    - [ ] "La Corrección" debe abordar suficientemente el _issue_ original.
    - [ ] "La Corrección" no debe cambiar ningún comportamiento existente a menos que se acuerde en el _issue_ original.
    - [ ] "La Corrección" no debe tener un impacto significativo en el rendimiento de p5.js.
@@ -143,7 +143,7 @@ Los "simple fix"(correción Sencilla), como la corrección de un pequeño error
    - Si se requieren múltiples cambios, no agregues comentarios de una sola línea muchas veces. En su lugar, sigue el procedimiento documentado [aquí](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request) para hacer comentarios de varias líneas y una sola solicitud de cambios (change request).
    - Si los comentarios en línea son solo para aclaraciones o discusión, elige "Comment" en lugar de "Request changes":\
      ![The "comment" option circled within the GitHub Finish Review menu](images/comment-review.png)
-5. Una vez que la PR haya sido revisada y no se requieran cambios adicionales, un administrador puede marcar la PR como "Aprobada" eligiendo la opción "Approve" en el paso anterior, con o sin comentarios adicionales. El administrador puede luego solicitar una revisión adicional por otro administrador o responsable de mantenimiento si lo desea, fusionar(merge) la PR si tiene acceso para fusionar(merge access), o solicitar "merge" (fusión) de un responsable de mantenimiento.
+5. Una vez que la _pull request_ haya sido revisada y no se requieran cambios adicionales, un administrador puede marcar la _pull request_ como "Aprobada" eligiendo la opción "Approve" en el paso anterior, con o sin comentarios adicionales. El administrador puede luego solicitar una revisión adicional por otro administrador o responsable de mantenimiento si lo desea, fusionar(merge) la _pull request_ si tiene acceso para fusionar(merge access), o solicitar "merge" (fusión) de un responsable de mantenimiento.
 6. @[all-contributors](https://allcontributors.org/docs/en/emoji-key)El bot debería ser llamado para agregar cualquier nuevo colaborador a la lista de colaboradores en el archivo README.md. Cada tipo de contribución puede ser indicado en lugar de `[contribution` `type]` a continuación, se puede encontrar la lista completa de tipos de contribuciones disponibles en el enlace anterior.
 
 `@all-contributors` `please` `add` `@[GitHub` `handle]` `for` `[contribution` `type]`
@@ -151,18 +151,18 @@ Los "simple fix"(correción Sencilla), como la corrección de un pequeño error
 
 ### Nuevas funcionalidades/Mejora de Funcionalidades
 
-El proceso para una PR de _new feature_ (nuevas funcionalidades),o _feature_enhacement_(mejora de funcionalidades) es similar a las correcciones de errores,pero solo con una diferencia notable:
+El proceso para una _pull request_ de _new feature_ (nuevas funcionalidades),o _feature_enhacement_(mejora de funcionalidades) es similar a las correcciones de errores,pero solo con una diferencia notable:
 
-- Una PR de nueva funcionalidad o mejora de funcionalidad debe ser revisada y aprobada por al menos dos administradores o responsables de mantenimiento antes de que pueda ser fusionada.
+- Una _pull request_ de nueva funcionalidad o mejora de funcionalidad debe ser revisada y aprobada por al menos dos administradores o responsables de mantenimiento antes de que pueda ser fusionada.
 
 
 ### Dependabot
 
-Las PRs de Dependabot generalmente solo son visibles para los administradores del repositorio, así que si esto no aplica a ti, por favor omite esta sección.
+Las _pull requests_ de Dependabot generalmente solo son visibles para los administradores del repositorio, así que si esto no aplica a ti, por favor omite esta sección.
 
-- Las PRs de Dependabot pueden fusionarse directamente si la actualización de la versión es una [semver](https://semver.org/) versión de parche y la prueba automatizada de CI ha pasado.
-- Las PRs de Dependabot con cambios de versión semver menor generalmente se pueden fusionar directamente siempre y cuando la prueba automatizada de CI pase. Se recomienda hacer una rápida verificación en el registro de cambios de la dependencia actualizada.
-- Los PR de Dependabot con cambios de versión principal de semver pueden afectar probablemente el proceso de compilación o las funcionalidades de p5.js. Se anima al revisor, en este caso, a revisar el registro de cambios desde la versión actual hasta la versión objetivo si es posible y probar el PR localmente para asegurarse de que todos los procesos estén funcionando y realizar cualquier cambio necesario debido a posibles cambios disruptivos en las dependencias.
+- Las _pull request_ de Dependabot pueden fusionarse directamente si la actualización de la versión es una [semver](https://semver.org/) versión de parche y la prueba automatizada de CI ha pasado.
+- Las _pull requests_ de Dependabot con cambios de versión semver menor generalmente se pueden fusionar directamente siempre y cuando la prueba automatizada de CI pase. Se recomienda hacer una rápida verificación en el registro de cambios de la dependencia actualizada.
+- Las _pull requests_ de Dependabot con cambios de versión principal de semver pueden afectar probablemente el proceso de compilación o las funcionalidades de p5.js. Se anima al revisor, en este caso, a revisar el registro de cambios desde la versión actual hasta la versión objetivo si es posible y probar la _pull request_ localmente para asegurarse de que todos los procesos estén funcionando y realizar cualquier cambio necesario debido a posibles cambios disruptivos en las dependencias.
 - Muchas dependencias aumentan los números de versión principales solo porque dejan de admitir oficialmente versiones muy antiguas de Node.js. En muchos casos, los cambios de versión principal no necesariamente implican cambios disruptivos resultantes de cambios en la API de dependencias.
 
 ---

From 6b2d2629b7c7a73f3d03e53a8415ce5c012ea826 Mon Sep 17 00:00:00 2001
From: Marce <ml.008@outlook.com>
Date: Mon, 18 Mar 2024 20:31:03 -0600
Subject: [PATCH 16/19] Update steward_guidelines.md

---
 contributor_docs/es/steward_guidelines.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
index 987374d8fd..e9cb70af55 100644
--- a/contributor_docs/es/steward_guidelines.md
+++ b/contributor_docs/es/steward_guidelines.md
@@ -107,7 +107,7 @@ Este tipo de _issue_ tiene una plantilla mínima de discusión y debería ser ut
 
 ## _Pull Requests_
 
-Casi todas las contribuciones de código a los repositorios de p5.js se realizan a través de Pull Request. Los administradores y los responsables de mantenimiento pueden tener "push access" (acceso de escritura) a los repositorios, pero aún se les anima a seguir el mismo proceso de _issue_ > _pull request_ > proceso de revisión al contribuir con código. Aquí están los pasos para revisar una _pull request_:
+Casi todas las contribuciones de código a los repositorios de p5.js se realizan a través de Pull Request. Los administradores y los responsables de mantenimiento pueden tener _push access_ (acceso de escritura) a los repositorios, pero aún se les anima a seguir el mismo proceso de _issue_ > _pull request_ > proceso de revisión al contribuir con código. Aquí están los pasos para revisar una _pull request_:
 
 - La plantilla de pull request se puede encontrar [Aquî](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md).
 - Casi todas las solicitudes de pull requests deben tener _issues_ asociados abiertos y discutidos primero, lo que significa que los["flujos de trabajo de los _issues_ mås relevantes ](steward_guidelines.md#issues) deben haber sido seguidos primero antes de que una _pull request_ sea revisada por cualquier administrador o responsable de mantenimiento.
@@ -118,7 +118,7 @@ Casi todas las contribuciones de código a los repositorios de p5.js se realizan
 
 ### Correción Sencilla
 
-Los "simple fix"(correción Sencilla), como la corrección de un pequeño error tipográfico, pueden "be merged"(fusionarse) directamente por cualquier persona con acceso para aplicar "merge"(fusionar). Verifica en la pestaña "Files Changed" de la _pull request_ para asegurarte de que la prueba automatizada de integración continua (CI) pase.
+_Simple fix_ (Correcciones simples),  como la corrección de un pequeño error tipográfico, pueden fusionarse directamente por cualquier persona con acceso para fusionar. Después, revisa la pestaña "Files Changed" de _pull request_ para asegurarte de que la prueba automatizada de integración continua (CI) haya pasado.
 
 ![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)

From b57d060f0d05415f7d7220d1508dad06b870cdc0 Mon Sep 17 00:00:00 2001
From: Marce <ml.008@outlook.com>
Date: Mon, 18 Mar 2024 20:48:15 -0600
Subject: [PATCH 17/19] Update steward_guidelines.md

---
 contributor_docs/es/steward_guidelines.md | 34 +++++++++++------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
index e9cb70af55..8701317883 100644
--- a/contributor_docs/es/steward_guidelines.md
+++ b/contributor_docs/es/steward_guidelines.md
@@ -1,7 +1,7 @@
-# Directrices para Administradores  
+# Directrices para Supervisores  
 
 
-Ya sea que recién te hayas unido a nosotros como administrador, seas un responsable de mantenimiento experimentado de p5.js, o estés en algún punto intermedio, esta guía contiene información, así como consejos y trucos que te ayudarán a contribuir de manera efectiva a p5.js. La mayor parte de lo que se escribe aquí son pautas a menos que se indique lo contrario, lo que significa que puedes adaptar las prácticas mostradas aquí para que se ajusten a tu flujo de trabajo.
+Ya sea que recién te hayas unido a nosotros como supervisor, seas un responsable de mantenimiento experimentado de p5.js, o estés en algún punto intermedio, esta guía contiene información, así como consejos y trucos que te ayudarán a contribuir de manera efectiva a p5.js. La mayor parte de lo que se escribe aquí son pautas a menos que se indique lo contrario, lo que significa que puedes adaptar las prácticas mostradas aquí para que se ajusten a tu flujo de trabajo.
 
 
 ## Tabla de Contenidos
@@ -20,7 +20,7 @@ Ya sea que recién te hayas unido a nosotros como administrador, seas un respons
   - [Tarea Principal de Construcción](steward_guidelines.md#tarea-principal-de-construcción)
   - [Tarea Variada](steward_guidelines.md#tarea-variada)
 - [Proceso de Lanzamiento](steward_guidelines.md#proceso-de-lanzamiento)
-- [Consejos y Trucos](steward_guidelines.md#tips--consejos-y-trucos)
+- [Consejos y Trucos](steward_guidelines.md#consejos-y-trucos)
   - [Plantillas de Respuesta](steward_guidelines.md#plantillas-de-respuesta)
   - [GitHub CLI](steward_guidelines.md#github-cli)
   - [Gestión de Notificaciones](steward_guidelines.md#gestión-de-notificaciones)
@@ -81,7 +81,7 @@ Los _issues_ para solicitar funcionalidades deberían utilizar la plantilla "New
      - Las funcionalidades que probablemente causen conflictos, como las mencionadas anteriormente, se consideran cambios incompatibles. Sin un [Lanzamiento de versión mayor](https://docs.npmjs.com/about-semantic-versioning),no deberíamos realizar cambios incompatibles en p5.js.
    - ¿Se puede lograr la nueva función propuesta utilizando las funcionalidades existentes ya en p5.js,código JavaScript nativo relativamente simple, o bibliotecas existentes fáciles de usar?
      - Por ejemplo, en lugar de proporcionar una función de p5.js para unir una matriz de cadenas como `join(["Hello","world!"])`, debería preferirse el JavaScript nativo `["Hello","world!"].join()`.
-3. Si el requisito de acceso y otras consideraciones han sido cumplidas, al menos dos administradores o responsables de mantenimiento deben aprobar la nueva solicitud de función antes de que comience el trabajo hacia una PR. El proceso de revisión de _pull request_ para nuevas funcionalidades está documentado a continuación.
+3. Si el requisito de acceso y otras consideraciones han sido cumplidas, al menos dos supervisores o responsables de mantenimiento deben aprobar la nueva solicitud de función antes de que comience el trabajo hacia una PR. El proceso de revisión de _pull request_ para nuevas funcionalidades está documentado a continuación.
 
 
 ### Mejora de funcionalidades
@@ -91,7 +91,7 @@ Las solicitudes de _issues_ de mejora de función deberían utilizar la plantill
 1. Similar a las solicitudes de nuevas funcionalidades, las mejoras de función solo deben ser aceptadas si aumentan el acceso a p5.js. Por favor, consulta el punto 1 de la [sección anterior](steward_guidelines.md#feature-request).
 2. Los criterios de inclusión para las mejoras de función son similares a los de las solicitudes de nuevas funcionalidades, pero se debe prestar especial atención a los posibles cambios incompatibles.
    - Si se están modificando funcionalidades existentes, todas las firmas de funcionalidades válidas y documentadas previamente deben comportarse de la misma manera.
-3. Las mejoras de funcionalidades deben ser aprobadas por al menos un administrador o responsable de mantenimiento antes de que comience el trabajo hacia una _pull request_. El proceso de revisión de _pull request_ para mejoras de funcionalidades está documentado a continuación.
+3. Las mejoras de funcionalidades deben ser aprobadas por al menos un supervisor o responsable de mantenimiento antes de que comience el trabajo hacia una _pull request_. El proceso de revisión de _pull request_ para mejoras de funcionalidades está documentado a continuación.
 
 
 ### Discusión
@@ -107,11 +107,11 @@ Este tipo de _issue_ tiene una plantilla mínima de discusión y debería ser ut
 
 ## _Pull Requests_
 
-Casi todas las contribuciones de código a los repositorios de p5.js se realizan a través de Pull Request. Los administradores y los responsables de mantenimiento pueden tener _push access_ (acceso de escritura) a los repositorios, pero aún se les anima a seguir el mismo proceso de _issue_ > _pull request_ > proceso de revisión al contribuir con código. Aquí están los pasos para revisar una _pull request_:
+Casi todas las contribuciones de código a los repositorios de p5.js se realizan a través de Pull Request. Los supervisores y los responsables de mantenimiento pueden tener _push access_ (acceso de escritura) a los repositorios, pero aún se les anima a seguir el mismo proceso de _issue_ > _pull request_ > proceso de revisión al contribuir con código. Aquí están los pasos para revisar una _pull request_:
 
 - La plantilla de pull request se puede encontrar [Aquî](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md).
-- Casi todas las solicitudes de pull requests deben tener _issues_ asociados abiertos y discutidos primero, lo que significa que los["flujos de trabajo de los _issues_ mås relevantes ](steward_guidelines.md#issues) deben haber sido seguidos primero antes de que una _pull request_ sea revisada por cualquier administrador o responsable de mantenimiento.
-  - Las únicas instancias donde esto no se aplica son correcciones muy menores de errores tipográficos, las cuales no requieren un _issue_ abierto y pueden ser fusionadas por cualquier persona con acceso para aplicar "merge" (fusionar) al repositorio, incluso si no son administradores de una área en particular.
+- Casi todas las solicitudes de pull requests deben tener _issues_ asociados abiertos y discutidos primero, lo que significa que los["flujos de trabajo de los _issues_ mås relevantes ](steward_guidelines.md#issues) deben haber sido seguidos primero antes de que una _pull request_ sea revisada por cualquier supervisor o responsable de mantenimiento.
+  - Las únicas instancias donde esto no se aplica son correcciones muy menores de errores tipográficos, las cuales no requieren un _issue_ abierto y pueden ser fusionadas por cualquier persona con acceso para aplicar "merge" (fusionar) al repositorio, incluso si no son supervisores de una área en particular.
   - Si bien esta excepción existe, la aplicaremos en la práctica solo mientras se siga alentando a los contribuyentes a abrir nuevos _issues_ primero. En otras palabras, si tienes dudas sobre si esta excepción se aplica, simplemente abre un _issue_ de todos modos.
 - Si una "pull request"no resuelve completamente el _issue_ referenciado, puedes editar la publicación original y cambiar "Resolves #OOOO" a "Addresses #OOOO" para que no cierre automáticamente el _issue_ original cuando la _pull request_ aplique _merge_ (se fusione).
 
@@ -126,15 +126,15 @@ _Simple fix_ (Correcciones simples),  como la corrección de un pequeño error t
 
 ### Corrección de Error
 
-1. "Bug fixes"(Corrección de errores) deberían ser revisado por el administrador del área relevante, idealmente el mismo que aprobó el _issue_ referenciado para su corrección.
+1. "Bug fixes"(Corrección de errores) deberían ser revisado por el supervisor del área relevante, idealmente el mismo que aprobó el _issue_ referenciado para su corrección.
 2. La pestaña "Files Changed" de la _pull request_ se puede utilizar para revisar inicialmente si el _fix_ (la ccorrección) se implementa según lo descrito en la discusión del _issue_.
 3. La _pull request_ Debería ser probada localmente siempre que sea posible y relevante. El GitHub CLI puede ayudar a agilizar parte del proceso. Ver más abajo en [Consejos y trucos](steward_guidelines.md#tips-tricks).
-   - [ ] "La Corrección" debe abordar suficientemente el _issue_ original.
-   - [ ] "La Corrección" no debe cambiar ningún comportamiento existente a menos que se acuerde en el _issue_ original.
-   - [ ] "La Corrección" no debe tener un impacto significativo en el rendimiento de p5.js.
-   - [ ] "La Corrección" no debe tener ningún impacto en la accesibilidad de p5.js.
-   - [ ] "La Corrección" debe utilizar el estándar moderno de codificación en JavaScript.
-   - [ ] "La Corrección" debe pasar todas las pruebas automatizadas e incluir nuevas pruebas(tests) si son relevantes.
+   - [ ] La Corrección debe abordar suficientemente el _issue_ original.
+   - [ ] La Corrección no debe cambiar ningún comportamiento existente a menos que se acuerde en el _issue_ original.
+   - [ ] La Corrección no debe tener un impacto significativo en el rendimiento de p5.js.
+   - [ ] La Corrección no debe tener ningún impacto en la accesibilidad de p5.js.
+   - [ ] La Corrección debe utilizar el estándar moderno de codificación en JavaScript.
+   - [ ] La Corrección debe pasar todas las pruebas automatizadas e incluir nuevas pruebas(tests) si son relevantes.
 4. Si se requieren cambios adicionales, se deben agregar comentarios en línea a las líneas relevantes según se describió anteriormente [aquí](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).
    - Un bloque de sugerencias también puede ser usado para sugerir cambios específicos:\
      ![The Suggest Change button while writing a comment on code in a GitHub pull request](images/suggest-change.png)\
@@ -143,7 +143,7 @@ _Simple fix_ (Correcciones simples),  como la corrección de un pequeño error t
    - Si se requieren múltiples cambios, no agregues comentarios de una sola línea muchas veces. En su lugar, sigue el procedimiento documentado [aquí](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request) para hacer comentarios de varias líneas y una sola solicitud de cambios (change request).
    - Si los comentarios en línea son solo para aclaraciones o discusión, elige "Comment" en lugar de "Request changes":\
      ![The "comment" option circled within the GitHub Finish Review menu](images/comment-review.png)
-5. Una vez que la _pull request_ haya sido revisada y no se requieran cambios adicionales, un administrador puede marcar la _pull request_ como "Aprobada" eligiendo la opción "Approve" en el paso anterior, con o sin comentarios adicionales. El administrador puede luego solicitar una revisión adicional por otro administrador o responsable de mantenimiento si lo desea, fusionar(merge) la _pull request_ si tiene acceso para fusionar(merge access), o solicitar "merge" (fusión) de un responsable de mantenimiento.
+5. Una vez que la _pull request_ haya sido revisada y no se requieran cambios adicionales, un supervisor puede marcar la _pull request_ como "Aprobada" eligiendo la opción "Approve" en el paso anterior, con o sin comentarios adicionales. El supervisor puede luego solicitar una revisión adicional por otro supervisor o responsable de mantenimiento si lo desea, fusionar(merge) la _pull request_ si tiene acceso para fusionar(merge access), o solicitar "merge" (fusión) de un responsable de mantenimiento.
 6. @[all-contributors](https://allcontributors.org/docs/en/emoji-key)El bot debería ser llamado para agregar cualquier nuevo colaborador a la lista de colaboradores en el archivo README.md. Cada tipo de contribución puede ser indicado en lugar de `[contribution` `type]` a continuación, se puede encontrar la lista completa de tipos de contribuciones disponibles en el enlace anterior.
 
 `@all-contributors` `please` `add` `@[GitHub` `handle]` `for` `[contribution` `type]`
@@ -153,7 +153,7 @@ _Simple fix_ (Correcciones simples),  como la corrección de un pequeño error t
 
 El proceso para una _pull request_ de _new feature_ (nuevas funcionalidades),o _feature_enhacement_(mejora de funcionalidades) es similar a las correcciones de errores,pero solo con una diferencia notable:
 
-- Una _pull request_ de nueva funcionalidad o mejora de funcionalidad debe ser revisada y aprobada por al menos dos administradores o responsables de mantenimiento antes de que pueda ser fusionada.
+- Una _pull request_ de nueva funcionalidad o mejora de funcionalidad debe ser revisada y aprobada por al menos dos supervisores o responsables de mantenimiento antes de que pueda ser fusionada.
 
 
 ### Dependabot

From f63f3ac781202cab2ef4e2c760950d4f88fee687 Mon Sep 17 00:00:00 2001
From: Marce <ml.008@outlook.com>
Date: Mon, 18 Mar 2024 22:02:21 -0600
Subject: [PATCH 18/19] Update steward_guidelines.md

---
 contributor_docs/es/steward_guidelines.md | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
index 8701317883..901e9fe522 100644
--- a/contributor_docs/es/steward_guidelines.md
+++ b/contributor_docs/es/steward_guidelines.md
@@ -99,7 +99,7 @@ Las solicitudes de _issues_ de mejora de función deberían utilizar la plantill
 Este tipo de _issue_ tiene una plantilla mínima de discusión y debería ser utilizada para recopilar comentarios y retroalimentaciones sobre un tema en general antes de consolidarlo en algo más específico, como una solicitud de función. Estos _issues_ de discusión pueden cerrarse cuando finaliza la conversación y se han creado los _issues_ más específicos resultantes:
 
 - Si se abre un _issue_ como una discusión pero debería ser, por ejemplo, un _bug report_(informe de error), se debe aplicar la etiqueta correcta y quitar la etiqueta de "discusión". Además, se debe solicitar información adicional sobre el error al autor si aún no se ha incluido.
-- Si se abre un _issue_ como una discusión pero no es relevante para la contribución de código fuente o de otra manera relevante para los repositorios de GitHub/el proceso de contribución/la comunidad de contribución, deberían ser redirigidos al foro o a Discord y el _issue_ cerrado.
+- Si se abre un _issue_ como una discusión pero no es relevante para la contribución de código fuente o de otra manera relevante para los repositorios de GitHub, el proceso de contribución o la comunidad de contribución, deberían ser redirigidos al foro o a Discord y el _issue_ cerrado.
 - Si es relevante, se deben agregar etiquetas adicionales a los _issues_ de discusión para señalar aún más qué tipo de discusión es con solo mirarla.
 
 ---
@@ -118,10 +118,10 @@ Casi todas las contribuciones de código a los repositorios de p5.js se realizan
 
 ### Correción Sencilla
 
-_Simple fix_ (Correcciones simples),  como la corrección de un pequeño error tipográfico, pueden fusionarse directamente por cualquier persona con acceso para fusionar. Después, revisa la pestaña "Files Changed" de _pull request_ para asegurarte de que la prueba automatizada de integración continua (CI) haya pasado.
+Correcciones simples, como la corrección de un pequeño error tipográfico, pueden fusionarse directamente por cualquier persona con acceso para fusionar. Después, revisa la pestaña "Files Changed" de _pull request_ para asegurarte de que la prueba automatizada de integración continua (CI) haya pasado.
 
-![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)
+![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)
 
 
 ### Corrección de Error
@@ -137,14 +137,14 @@ _Simple fix_ (Correcciones simples),  como la corrección de un pequeño error t
    - [ ] La Corrección debe pasar todas las pruebas automatizadas e incluir nuevas pruebas(tests) si son relevantes.
 4. Si se requieren cambios adicionales, se deben agregar comentarios en línea a las líneas relevantes según se describió anteriormente [aquí](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).
    - Un bloque de sugerencias también puede ser usado para sugerir cambios específicos:\
-     ![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)
+     ![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)
    - Si se requieren múltiples cambios, no agregues comentarios de una sola línea muchas veces. En su lugar, sigue el procedimiento documentado [aquí](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request) para hacer comentarios de varias líneas y una sola solicitud de cambios (change request).
    - Si los comentarios en línea son solo para aclaraciones o discusión, elige "Comment" en lugar de "Request changes":\
-     ![The "comment" option circled within the GitHub Finish Review menu](images/comment-review.png)
+     ![The "comment" option circled within the GitHub Finish Review menu](../images/comment-review.png)
 5. Una vez que la _pull request_ haya sido revisada y no se requieran cambios adicionales, un supervisor puede marcar la _pull request_ como "Aprobada" eligiendo la opción "Approve" en el paso anterior, con o sin comentarios adicionales. El supervisor puede luego solicitar una revisión adicional por otro supervisor o responsable de mantenimiento si lo desea, fusionar(merge) la _pull request_ si tiene acceso para fusionar(merge access), o solicitar "merge" (fusión) de un responsable de mantenimiento.
-6. @[all-contributors](https://allcontributors.org/docs/en/emoji-key)El bot debería ser llamado para agregar cualquier nuevo colaborador a la lista de colaboradores en el archivo README.md. Cada tipo de contribución puede ser indicado en lugar de `[contribution` `type]` a continuación, se puede encontrar la lista completa de tipos de contribuciones disponibles en el enlace anterior.
+6. El bot @[all-contributors](https://allcontributors.org/docs/en/emoji-key) debería ser llamado para agregar cualquier nuevo colaborador a la lista de colaboradores en el archivo README.md. Cada tipo de contribución puede ser indicado en lugar de `[contribution` `type]` a continuación, se puede encontrar la lista completa de tipos de contribuciones disponibles en el enlace anterior.
 
 `@all-contributors` `please` `add` `@[GitHub` `handle]` `for` `[contribution` `type]`
 
@@ -371,7 +371,7 @@ There are many other commands available in the GitHub CLI as well that you may o
 
 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)
+![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.
 

From 389ab653cf44f401a0b0b91c5424c5cb50abab2e Mon Sep 17 00:00:00 2001
From: Marce <ml.008@outlook.com>
Date: Tue, 19 Mar 2024 03:32:06 -0600
Subject: [PATCH 19/19] Update steward_guidelines.md

---
 contributor_docs/es/steward_guidelines.md | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/contributor_docs/es/steward_guidelines.md b/contributor_docs/es/steward_guidelines.md
index 901e9fe522..415c0fc28e 100644
--- a/contributor_docs/es/steward_guidelines.md
+++ b/contributor_docs/es/steward_guidelines.md
@@ -52,12 +52,12 @@ Los _issues_ de informes de errores deberían utilizar la plantilla de _Issue_ "
      - Intente solucionarlo usted mismo o agregue la etiqueta `help wanted` para señalar que es un _issue_ que necesita solución.
 3. Si el error no se puede replicar:
    - Solicite información adicional si aún no se ha proporcionado en la plantilla (versión de p5.js, versión del navegador, versión del sistema operativo, etc).
-   - Si su entorno de prueba difiere de lo que se informa en el _issue_(por ejemplo,un navegador o sistema operativo diferente):
+   - Si su entorno de prueba difiere de lo que se informa en el _issue_ (por ejemplo,un navegador o sistema operativo diferente):
      - Deje un comentario diciendo que no puede replicar en su entorno específico.
      - Agregue una etiqueta `help wanted` al _issue_ incidente y pida a alguien más con la configuración especificada en el _issue_ que intente replicar el error.
-   - A veces, los "bugs"(errores) solo ocurren al usar el editor web y no al probar localmente. En este caso, el _issue_ debería ser redirigido al [repositorio del editor web](https://github.com/processing/p5.js-web-editor).
+   - A veces, los _bugs_ (errores) solo ocurren al usar el editor web y no al probar localmente. En este caso, el _issue_ debería ser redirigido al [repositorio del editor web](https://github.com/processing/p5.js-web-editor).
    - Si la replicación es posible más tarde, regrese al paso 2.
-4. Si el error se origina en el código que el usuario proporcionó en el informe de error y no en el comportamiento de p5.js:
+1. Si el error se origina en el código que el usuario proporcionó en el informe de error y no en el comportamiento de p5.js:
    - Determine si la documentación de p5.js, la implementación de código o el sistema de errores amigable pueden mejorarse para evitar que se cometa el mismo error.
    - Redirija amablemente cualquier pregunta adicional al [foro](https://discourse.processing.org/) o al [Discord](https://discord.com/invite/SHQ8dH25r9) y cierre el _issue_ si no se van a realizar más cambios en p5.js.
    
@@ -86,7 +86,7 @@ Los _issues_ para solicitar funcionalidades deberían utilizar la plantilla "New
 
 ### Mejora de funcionalidades
 
-Las solicitudes de _issues_ de mejora de función deberían utilizar la plantilla de incidentes de "Existing Feature Enhancement" (Mejora de Funcionalidades Existentes). El proceso es muy similar a las solicitudes de nuevas funcionalidades. La diferencia entre una "new feature request" (solicitud de nueva funcionalidad) y una "feature request" (Mejora de Funcionalidad) puede ser confusa a veces. La mejora de función principalmente trata sobre las funcionalidades existentes de p5.js, mientras que una solicitud de nueva función podría estar solicitando la adición de funcionalidades completamente nuevas.
+Las solicitudes de _issues_ de mejora de función deberían utilizar la plantilla de incidentes de "Existing Feature Enhancement" (Mejora de Funcionalidades Existentes). El proceso es muy similar a las solicitudes de nuevas funcionalidades. La diferencia entre una _new feature request_ (solicitud de nueva funcionalidad) y una _feature request_ (Mejora de Funcionalidad) puede ser confusa a veces. La mejora de función principalmente trata sobre las funcionalidades existentes de p5.js, mientras que una solicitud de nueva función podría estar solicitando la adición de funcionalidades completamente nuevas.
 
 1. Similar a las solicitudes de nuevas funcionalidades, las mejoras de función solo deben ser aceptadas si aumentan el acceso a p5.js. Por favor, consulta el punto 1 de la [sección anterior](steward_guidelines.md#feature-request).
 2. Los criterios de inclusión para las mejoras de función son similares a los de las solicitudes de nuevas funcionalidades, pero se debe prestar especial atención a los posibles cambios incompatibles.
@@ -98,7 +98,7 @@ Las solicitudes de _issues_ de mejora de función deberían utilizar la plantill
 
 Este tipo de _issue_ tiene una plantilla mínima de discusión y debería ser utilizada para recopilar comentarios y retroalimentaciones sobre un tema en general antes de consolidarlo en algo más específico, como una solicitud de función. Estos _issues_ de discusión pueden cerrarse cuando finaliza la conversación y se han creado los _issues_ más específicos resultantes:
 
-- Si se abre un _issue_ como una discusión pero debería ser, por ejemplo, un _bug report_(informe de error), se debe aplicar la etiqueta correcta y quitar la etiqueta de "discusión". Además, se debe solicitar información adicional sobre el error al autor si aún no se ha incluido.
+- Si se abre un _issue_ como una discusión pero debería ser, por ejemplo, un _bug report_ (informe de error), se debe aplicar la etiqueta correcta y quitar la etiqueta de "discussión". Además, se debe solicitar información adicional sobre el error al autor si aún no se ha incluido.
 - Si se abre un _issue_ como una discusión pero no es relevante para la contribución de código fuente o de otra manera relevante para los repositorios de GitHub, el proceso de contribución o la comunidad de contribución, deberían ser redirigidos al foro o a Discord y el _issue_ cerrado.
 - Si es relevante, se deben agregar etiquetas adicionales a los _issues_ de discusión para señalar aún más qué tipo de discusión es con solo mirarla.
 
@@ -111,7 +111,7 @@ Casi todas las contribuciones de código a los repositorios de p5.js se realizan
 
 - La plantilla de pull request se puede encontrar [Aquî](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md).
 - Casi todas las solicitudes de pull requests deben tener _issues_ asociados abiertos y discutidos primero, lo que significa que los["flujos de trabajo de los _issues_ mås relevantes ](steward_guidelines.md#issues) deben haber sido seguidos primero antes de que una _pull request_ sea revisada por cualquier supervisor o responsable de mantenimiento.
-  - Las únicas instancias donde esto no se aplica son correcciones muy menores de errores tipográficos, las cuales no requieren un _issue_ abierto y pueden ser fusionadas por cualquier persona con acceso para aplicar "merge" (fusionar) al repositorio, incluso si no son supervisores de una área en particular.
+  - Las únicas instancias donde esto no se aplica son correcciones muy menores de errores tipográficos, las cuales no requieren un _issue_ abierto y pueden ser fusionadas por cualquier persona con acceso para aplicar _merge_ (fusionar) al repositorio, incluso si no son supervisores de una área en particular.
   - Si bien esta excepción existe, la aplicaremos en la práctica solo mientras se siga alentando a los contribuyentes a abrir nuevos _issues_ primero. En otras palabras, si tienes dudas sobre si esta excepción se aplica, simplemente abre un _issue_ de todos modos.
 - Si una "pull request"no resuelve completamente el _issue_ referenciado, puedes editar la publicación original y cambiar "Resolves #OOOO" a "Addresses #OOOO" para que no cierre automáticamente el _issue_ original cuando la _pull request_ aplique _merge_ (se fusione).
 
@@ -126,7 +126,7 @@ Correcciones simples, como la corrección de un pequeño error tipográfico, pue
 
 ### Corrección de Error
 
-1. "Bug fixes"(Corrección de errores) deberían ser revisado por el supervisor del área relevante, idealmente el mismo que aprobó el _issue_ referenciado para su corrección.
+1. _Bug fixes_ (Corrección de errores) deberían ser revisado por el supervisor del área relevante, idealmente el mismo que aprobó el _issue_ referenciado para su corrección.
 2. La pestaña "Files Changed" de la _pull request_ se puede utilizar para revisar inicialmente si el _fix_ (la ccorrección) se implementa según lo descrito en la discusión del _issue_.
 3. La _pull request_ Debería ser probada localmente siempre que sea posible y relevante. El GitHub CLI puede ayudar a agilizar parte del proceso. Ver más abajo en [Consejos y trucos](steward_guidelines.md#tips-tricks).
    - [ ] La Corrección debe abordar suficientemente el _issue_ original.
@@ -134,7 +134,7 @@ Correcciones simples, como la corrección de un pequeño error tipográfico, pue
    - [ ] La Corrección no debe tener un impacto significativo en el rendimiento de p5.js.
    - [ ] La Corrección no debe tener ningún impacto en la accesibilidad de p5.js.
    - [ ] La Corrección debe utilizar el estándar moderno de codificación en JavaScript.
-   - [ ] La Corrección debe pasar todas las pruebas automatizadas e incluir nuevas pruebas(tests) si son relevantes.
+   - [ ] La Corrección debe pasar todas las pruebas automatizadas e incluir nuevas pruebas (tests) si son relevantes.
 4. Si se requieren cambios adicionales, se deben agregar comentarios en línea a las líneas relevantes según se describió anteriormente [aquí](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).
    - Un bloque de sugerencias también puede ser usado para sugerir cambios específicos:\
      ![The Suggest Change button while writing a comment on code in a GitHub pull request](../images/suggest-change.png)\
@@ -143,7 +143,7 @@ Correcciones simples, como la corrección de un pequeño error tipográfico, pue
    - Si se requieren múltiples cambios, no agregues comentarios de una sola línea muchas veces. En su lugar, sigue el procedimiento documentado [aquí](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request) para hacer comentarios de varias líneas y una sola solicitud de cambios (change request).
    - Si los comentarios en línea son solo para aclaraciones o discusión, elige "Comment" en lugar de "Request changes":\
      ![The "comment" option circled within the GitHub Finish Review menu](../images/comment-review.png)
-5. Una vez que la _pull request_ haya sido revisada y no se requieran cambios adicionales, un supervisor puede marcar la _pull request_ como "Aprobada" eligiendo la opción "Approve" en el paso anterior, con o sin comentarios adicionales. El supervisor puede luego solicitar una revisión adicional por otro supervisor o responsable de mantenimiento si lo desea, fusionar(merge) la _pull request_ si tiene acceso para fusionar(merge access), o solicitar "merge" (fusión) de un responsable de mantenimiento.
+5. Una vez que la _pull request_ haya sido revisada y no se requieran cambios adicionales, un supervisor puede marcar la _pull request_ como "Aprobada" eligiendo la opción "Approve" en el paso anterior, con o sin comentarios adicionales. El supervisor puede luego solicitar una revisión adicional por otro supervisor o responsable de mantenimiento si lo desea, fusionar la _pull request_ si tiene acceso para fusionar (merge access), o solicitar _merge_ (fusión) de un responsable de mantenimiento.
 6. El bot @[all-contributors](https://allcontributors.org/docs/en/emoji-key) debería ser llamado para agregar cualquier nuevo colaborador a la lista de colaboradores en el archivo README.md. Cada tipo de contribución puede ser indicado en lugar de `[contribution` `type]` a continuación, se puede encontrar la lista completa de tipos de contribuciones disponibles en el enlace anterior.
 
 `@all-contributors` `please` `add` `@[GitHub` `handle]` `for` `[contribution` `type]`
@@ -151,7 +151,7 @@ Correcciones simples, como la corrección de un pequeño error tipográfico, pue
 
 ### Nuevas funcionalidades/Mejora de Funcionalidades
 
-El proceso para una _pull request_ de _new feature_ (nuevas funcionalidades),o _feature_enhacement_(mejora de funcionalidades) es similar a las correcciones de errores,pero solo con una diferencia notable:
+El proceso para una _pull request_ de _new feature_ (nuevas funcionalidades),o _feature_enhacement_ (mejora de funcionalidades) es similar a las correcciones de errores,pero solo con una diferencia notable:
 
 - Una _pull request_ de nueva funcionalidad o mejora de funcionalidad debe ser revisada y aprobada por al menos dos supervisores o responsables de mantenimiento antes de que pueda ser fusionada.