792b4dba2c
* update github.com/blevesearch/bleve v2.0.2 -> v2.0.3 * github.com/denisenkom/go-mssqldb v0.9.0 -> v0.10.0 * github.com/editorconfig/editorconfig-core-go v2.4.1 -> v2.4.2 * github.com/go-chi/cors v1.1.1 -> v1.2.0 * github.com/go-git/go-billy v5.0.0 -> v5.1.0 * github.com/go-git/go-git v5.2.0 -> v5.3.0 * github.com/go-ldap/ldap v3.2.4 -> v3.3.0 * github.com/go-redis/redis v8.6.0 -> v8.8.2 * github.com/go-sql-driver/mysql v1.5.0 -> v1.6.0 * github.com/go-swagger/go-swagger v0.26.1 -> v0.27.0 * github.com/lib/pq v1.9.0 -> v1.10.1 * github.com/mattn/go-sqlite3 v1.14.6 -> v1.14.7 * github.com/go-testfixtures/testfixtures v3.5.0 -> v3.6.0 * github.com/issue9/identicon v1.0.1 -> v1.2.0 * github.com/klauspost/compress v1.11.8 -> v1.12.1 * github.com/mgechev/revive v1.0.3 -> v1.0.6 * github.com/microcosm-cc/bluemonday v1.0.7 -> v1.0.8 * github.com/niklasfasching/go-org v1.4.0 -> v1.5.0 * github.com/olivere/elastic v7.0.22 -> v7.0.24 * github.com/pelletier/go-toml v1.8.1 -> v1.9.0 * github.com/prometheus/client_golang v1.9.0 -> v1.10.0 * github.com/xanzy/go-gitlab v0.44.0 -> v0.48.0 * github.com/yuin/goldmark v1.3.3 -> v1.3.5 * github.com/6543/go-version v1.2.4 -> v1.3.1 * do github.com/lib/pq v1.10.0 -> v1.10.1 again ...
132 lines
4.9 KiB
Markdown
Vendored
132 lines
4.9 KiB
Markdown
Vendored
## 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
|