Meltano uses an approval workflow for all pull requests.
A contributor can ask for a review on any pull request, without this pull request being done and/or ready to merge.
Asking for a review is asking for feedback on the implementation, not approval of the pull request. It is also the perfect time to familiarize yourself with the code base. If you don’t understand why a certain code path would solve a particular problem, that should be sent as feedback: it most probably means the code is cryptic/complex or that the problem is bigger than anticipated.
Merge conflicts, failing tests and/or missing checkboxes should not be used as ground for sending back a pull request without feedback, unless specified by the reviewer.
Pull requests should be named according to the conventional commit syntax to streamline changelog and release notes management. We encourage (but do not require) the use of conventional commits in commit messages as well.
In general, PR titles should follow the format “
Optionally, you may use the expanded syntax to specify a scope in the form
<type>(<scope>): <desc>. Currently scopes are:
The latest rules and settings are found within the file
Meltano makes use of ADR’s (Architectural Decision Records) to record architectural decisions roughly as described by Michael Nygard. In a nutshell, these are used to document architectural decisions and to provide a record of the decisions made by the team and contributors in regard to Meltano’s architecture. These are held in docs/adr. To propose or add a new ADR, its simplest to create a new entry using adr-tools, and then send a long a pull request for review.
Meltano uses changelog-cli to populate the CHANGELOG.md
changelog (new|change|fix|breaks) MESSAGE to describe your current work in progress.
$ poetry run changelog new "add an amazing feature" $ git add CHANGELOG.md
Make sure to add CHANGELOG entries to your pull requests.
All new features should be covered via the integration tests. In some cases a new feature or feature change may already be covered indirectly by one of the existing examples and no changes required. If you need an explicit test you can do so by either updating an existing guide (e.g. to include calling your new feature) or by creating a new guide to demo (and thus test) a more complex behavior.
If adding a net-new entry or changing the behavior of an existing example, please be sure to update the table of contents in the README.md accordingly.