Removed the checklist item for ensuring CI is passing. We don't really have CI as of yet and it's confusing to list that requirement. If we do add CI, we'll make it required instead of adding it to the template checklist.
Adds clarification around our expectations for contributions and
how contributions will be handled when they don't meet our requirements.
Updates template to lean into our contribution guidelines.
Cleans up duplicate wording around our contribution guidelines.
Historically R users have used the .Renviron file for storing environmental variables such as secrets, credentials, API keys etc. However, I believe there are several compelling reasons for adding .env to the .gitignore too:
1. The dotenv R package was created to allow users to use .env instead of .Renviron. The package has a significant number of downloads. https://github.com/gaborcsardi/dotenv
2. .env files are standard in many other programming languages. It wouldn't be that out of the unexpected to think R users might end up with an .env file because a python user on their team contributed files to the repo, the R user started programming in nodejs and is used to working with .env file, or a repo is in the process of being translated from a language that uses .env to R.
3. LLMs are making programming accessible to people who may not have much previous experience handling credentials and security. One of the first steps many of these users have to do is store LLM provider API keys somewhere. I worry about a new R user adapting a python workflow or an R workflow that recommends using an .env file and then accidentally committing their LLM API keys to a public repo.
4. I can't think of why an R user would create an .env file for any other reason other than storing credentials and environmental variables. If, for whatever reason, they need to commit an .env file, they can remove that part from the template, but I think the risk of accidentally exposing sensitive credentials justifies adding .env files to the template and not commenting it out by default.
This pull request adds a .gitignore file specifically designed for projects using Bun as a package manager. The bun.gitignore file includes rules to ignore common files and directories generated during development with Bun, as well as other tools and frameworks frequently used in conjunction with Bun.
We are planning to add a [new output path format](https://github.com/dotnet/designs/pull/281) to .NET projects which will by default put output in an `.artifacts` folder. So this PR adds that folder to the Visual Studio .gitignore file.
The first support for this will be in .NET 8 Preview 3. We will be looking for feedback through the preview process, so it's possible that the folder name or other aspects of the design could change as a result.
@@ -8,16 +15,18 @@ Please provide some background for this change.
### Links to documentation supporting these rule changes
_TODO_
<!---
Link to the project docs, any existing .gitignore files that project may have in it's own repo, etc
Link to the project docs, any existing .gitignore files that project may have in its own repo, etc
--->
### If this is a new template
Link to application or project’s homepage: TODO
### Merge and Approval Steps
- [ ] Confirm that you've read the [contribution guidelines](https://github.com/github/gitignore/tree/main?tab=readme-ov-file#contributing-guidelines) and ensured your PR aligns
- [ ] Ensure CI is passing
- [ ] Get a review and Approval from one of the maintainers
<!---
Please ensure you accomplish these tasks in order to get your contribution accepted
--->
- [ ] I have read the [contribution guidelines](https://github.com/github/gitignore/tree/main?tab=readme-ov-file#contributing-guidelines) and understand my PR will be closed if it doesn't meet these guidelines
<!---
Once done, please wait for a GitHub maintainer to review your PR and if necessary,
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.