CONTRIBUTING.md
Rama main · réplica de lectura del repositorio original.
## Filing Bugs
If you're experiencing behavior that appears to be a bug in RStudio, you're welcome to [file an issue](https://github.com/rstudio/rstudio/issues/new). Before you do, please go through this pre-flight checklist:
1. Is the RStudio IDE itself the source of the error or problem? Many errors you see inside RStudio come from R or R packages. If you're having trouble with R, read [Getting Help with R](https://www.r-project.org/help.html) for pointers.
2. Is your issue a bug rather than a question? If you're having general trouble with RStudio or have questions for the RStudio community, the [RStudio Community Forum](https://forum.posit.co/c/rstudio-ide) is an excellent resource.
3. Are you the first person to report this issue? [Search the issue list](https://github.com/rstudio/rstudio/issues) to find out. If you aren't, the most helpful thing you can do is vote for the existing issue (add a +1 reaction to it), and optionally add a comment describing your own experience.
When you're ready to file an issue, see our [guide to writing good bug reports](https://github.com/rstudio/rstudio/wiki/Writing-Good-Bug-Reports) for more on how to write a great bug report.
## Enhancements
You're also welcome to submit ideas for enhancements to RStudio. When doing so, please [search the issue list](https://github.com/rstudio/rstudio/issues) to see if the enhancement has already been filed. If it has, vote for it (add a reaction to it) and optionally add a comment with your perspective on the idea.
See our [guide to writing feature requests](https://github.com/rstudio/rstudio/wiki/Writing-Good-Feature-Requests) for more on how to write a great feature request.
## RStudio Pro
This repo contains the open source version of RStudio and RStudio Server; its issue tracker is scoped to that version. To report issues or request new features for the professional version of RStudio, please get in touch with the Posit Support team at <support@posit.co>.
## Contributing Code
We welcome contributions to RStudio. To submit a contribution:
1. [Fork](https://github.com/rstudio/rstudio/fork) the repository and make your changes.
2. Ensure that you have signed the [individual](https://posit.co/individual-contributor-agreement) or [corporate](https://posit.co/corporate-contributor-agreement) contributor agreement as appropriate. You can send the signed copy to <contribute@posit.co>.
3. Submit a [pull request](https://help.github.com/articles/using-pull-requests).
We'll try to be as responsive as possible in reviewing and accepting pull requests. We appreciate your contributions very much!
## Pull Request Guidelines
Reviewing pull requests (PRs) takes real time from a small team, so we ask that every contribution meets the bar described below. PRs that don't will be closed.
### Build and Test Locally
Every pull request is expected to have been built and tested locally before it is opened. In the PR description, please include:
- **What you tested**: the scenarios, workflows, or behaviors you verified, including any edge cases you considered
- **Which platforms you tested on**: macOS, Windows, or Linux
If you were unable to test on a particular platform, say so explicitly. We'd much rather know up front than discover it during review or after merge.
### Limit on Open Pull Requests
We ask that external contributors keep at most two open pull requests at a time. Additional PRs opened while two are already open will be closed without review, but may be re-opened at later time.
Once a contributor has established a track record of thoughtful, high-quality contributions, we're happy to lift this limit on a case-by-case basis.
### AI-Assisted Contributions
Using AI tools to help write code or PR descriptions is not prohibited, but the responsibility for the contribution is yours. Before submitting, please:
- Read every line of the change and make sure you understand it
- Confirm the change actually addresses a real problem, not a hypothetical one inferred from the code
- Verify the change fits the surrounding code style and conventions
- Make sure the PR description matches what the diff actually does
PRs that read as unedited AI output will be closed. Examples include speculative refactors, fabricated issue descriptions, changes that don't match the linked issue, and generic "improvements" with no concrete motivation.
## Code of Conduct
As contributors and maintainers of this project, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, or religion.
Examples of unacceptable behavior by participants include the use of sexual language or imagery, derogatory comments or personal attacks, trolling, public or private harassment, insults, or other unprofessional conduct.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. Project maintainers who do not follow the Code of Conduct may be removed from the project team.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or contacting one or more of the project maintainers.
This Code of Conduct is adapted from the Contributor Covenant, version 1.0.0, available at <https://www.contributor-covenant.org/version/1/0/0/code-of-conduct.html>.