--- a/vendor/github.com/pelletier/go-toml/CONTRIBUTING.md Thu Sep 22 16:37:07 2022 +0200
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,132 +0,0 @@
-## Contributing
-
-Thank you for your interest in go-toml! We appreciate you considering
-contributing to go-toml!
-
-The main goal is the project is to provide an easy-to-use TOML
-implementation for Go that gets the job done and gets out of your way –
-dealing with TOML is probably not the central piece of your project.
-
-As the single maintainer of go-toml, time is scarce. All help, big or
-small, is more than welcomed!
-
-### Ask questions
-
-Any question you may have, somebody else might have it too. Always feel
-free to ask them on the [issues tracker][issues-tracker]. We will try to
-answer them as clearly and quickly as possible, time permitting.
-
-Asking questions also helps us identify areas where the documentation needs
-improvement, or new features that weren't envisioned before. Sometimes, a
-seemingly innocent question leads to the fix of a bug. Don't hesitate and
-ask away!
-
-### Improve the documentation
-
-The best way to share your knowledge and experience with go-toml is to
-improve the documentation. Fix a typo, clarify an interface, add an
-example, anything goes!
-
-The documentation is present in the [README][readme] and thorough the
-source code. On release, it gets updated on [pkg.go.dev][pkg.go.dev]. To make a
-change to the documentation, create a pull request with your proposed
-changes. For simple changes like that, the easiest way to go is probably
-the "Fork this project and edit the file" button on Github, displayed at
-the top right of the file. Unless it's a trivial change (for example a
-typo), provide a little bit of context in your pull request description or
-commit message.
-
-### Report a bug
-
-Found a bug! Sorry to hear that :(. Help us and other track them down and
-fix by reporting it. [File a new bug report][bug-report] on the [issues
-tracker][issues-tracker]. The template should provide enough guidance on
-what to include. When in doubt: add more details! By reducing ambiguity and
-providing more information, it decreases back and forth and saves everyone
-time.
-
-### Code changes
-
-Want to contribute a patch? Very happy to hear that!
-
-First, some high-level rules:
-
-* A short proposal with some POC code is better than a lengthy piece of
- text with no code. Code speaks louder than words.
-* No backward-incompatible patch will be accepted unless discussed.
- Sometimes it's hard, and Go's lack of versioning by default does not
- help, but we try not to break people's programs unless we absolutely have
- to.
-* If you are writing a new feature or extending an existing one, make sure
- to write some documentation.
-* Bug fixes need to be accompanied with regression tests.
-* New code needs to be tested.
-* Your commit messages need to explain why the change is needed, even if
- already included in the PR description.
-
-It does sound like a lot, but those best practices are here to save time
-overall and continuously improve the quality of the project, which is
-something everyone benefits from.
-
-#### Get started
-
-The fairly standard code contribution process looks like that:
-
-1. [Fork the project][fork].
-2. Make your changes, commit on any branch you like.
-3. [Open up a pull request][pull-request]
-4. Review, potential ask for changes.
-5. Merge. You're in!
-
-Feel free to ask for help! You can create draft pull requests to gather
-some early feedback!
-
-#### Run the tests
-
-You can run tests for go-toml using Go's test tool: `go test ./...`.
-When creating a pull requests, all tests will be ran on Linux on a few Go
-versions (Travis CI), and on Windows using the latest Go version
-(AppVeyor).
-
-#### Style
-
-Try to look around and follow the same format and structure as the rest of
-the code. We enforce using `go fmt` on the whole code base.
-
----
-
-### Maintainers-only
-
-#### Merge pull request
-
-Checklist:
-
-* Passing CI.
-* Does not introduce backward-incompatible changes (unless discussed).
-* Has relevant doc changes.
-* Has relevant unit tests.
-
-1. Merge using "squash and merge".
-2. Make sure to edit the commit message to keep all the useful information
- nice and clean.
-3. Make sure the commit title is clear and contains the PR number (#123).
-
-#### New release
-
-1. Go to [releases][releases]. Click on "X commits to master since this
- release".
-2. Make note of all the changes. Look for backward incompatible changes,
- new features, and bug fixes.
-3. Pick the new version using the above and semver.
-4. Create a [new release][new-release].
-5. Follow the same format as [1.1.0][release-110].
-
-[issues-tracker]: https://github.com/pelletier/go-toml/issues
-[bug-report]: https://github.com/pelletier/go-toml/issues/new?template=bug_report.md
-[pkg.go.dev]: https://pkg.go.dev/github.com/pelletier/go-toml
-[readme]: ./README.md
-[fork]: https://help.github.com/articles/fork-a-repo
-[pull-request]: https://help.github.com/en/articles/creating-a-pull-request
-[releases]: https://github.com/pelletier/go-toml/releases
-[new-release]: https://github.com/pelletier/go-toml/releases/new
-[release-110]: https://github.com/pelletier/go-toml/releases/tag/v1.1.0