Contributing to TDP
We appreciate your interest and efforts to contribute to TDP.
Contributions go far beyond pull requests and commits. We would be thrilled to receive a variety of other contributions including the following:
- Write and publish your own actions
- Write articles and blog posts, create a tutorial, and spread the words
- Submit new ideas of features and documentation
- Submitting documentation updates, enhancements, designs, or bugfixes
- Submitting spelling or grammar fixes
- Additional unit or functional tests
- Help to answer questions and issues on GitHub
There is currently no channel dedicated to discussing TDP. For now, you may simply open a new issue.
Expressing your opinions and desires is encouraged to influence the work on TDP. You can submit new issues on GitHub and upvote existing features.
Where to Find Known Issues
TDP is using GitHub issues to manage public bugs. We keep a close eye on this and try to make it clear when we have an internal fix in progress.
Before filing a new issue, try to ensure your problem is not already reported.
Reporting New Issues
The best way to get your bug fixed is to provide a reduced test case. You can get inspiration from our current tests’ suite. Note, tests are filtered by tags and some tests require a specific environment which is provided through Docker or LXD environments.
All work on TDP happens directly on GitHub. Both core team members and external contributors send pull requests which go through the same review process.
This project, and everyone participating in it, are governed by the TDP code of conduct which adopts Contributor Covenant version 1.4, available at (https://contributor-covenant.org/version/1/4). Before participating, you must read and acknowledge its content. Later, you are expected to respect it.
…to be discussed…
As stated in our PULL_REQUEST_TEMPLATE on every repository, you must accept to:
- That your contribution is to be licenced under the Apache License Version 2.0, January 2004
- To grant TOSIT a copyright license to use my contributions.
This can performed by checking the boxes in the PULL_REQUEST_TEMPLATE while opening a Pull request.
Managing an open source project a huge time sink and most of us are non-native English speakers. We greatly appreciate any time spent fixing typos or clarifying sections in the documentation.
Pull requests related to fixing documentation for the latest release should be directed towards the documentation repository.
We will do our best to keep the
main branch in good shape, with tests passing at all times. The objective is to preserve the
main branch in a releasable state. But in order to move fast, we will make API changes that your application might not be compatible with. We recommend that you use the latest stable version of TDP.
If you send a pull request, please do it against the
main branch. We maintain stable branches for major versions separately but we don’t accept pull requests to them directly. Instead, we cherry-pick non-breaking changes from
main to the latest stable major version.
TDP follows Semantic Versioning (aka SemVer). We release patch versions for bug fixes, minor versions for new features, and major versions for any breaking changes. When we make breaking changes, we also introduce deprecation warnings in a minor version so that our users learn about the upcoming changes and migrate their code in advance.
Every significant change is documented in the Changelog file.
- CI/CD tooling
- Devops/ Open source advocate
- Knowledgable in Hadoop services deployment, maintenance and upgrading
- Python2/Python3 scripting
- Bash scripting
Before sending a pull request for a feature, be sure to have tests to cover your code.
If you intend to change the public API or make any non-trivial changes to the implementation, we recommend filing an issue. This lets us reach an agreement on your proposal before you put significant effort into it.
If you’re only fixing a bug, it’s fine to submit a pull request right away but we still recommend filing an issue detailing what you’re fixing. This is helpful in case we don’t accept that specific fix but want to keep track of the issue.
The TDP git repositories follows the Conventional Commits specification that provides an easy set of rules for creating an explicit commit history.
Here’s how a commit message looks like:
<type>[optional scope]: <description> [optional body] [optional footer(s)]
<type> message follows the Angular convention and must be one from the list:
[optional scope] message is associated to the directory name of the available packages. A scope is optional and is contained within parentheses, e.g.,
feat(engine): ability to parse arrays. Follow the specification to learn more about Conventional Commits.
Commit messages are automatically validated using a GitHub Action, in case of any mistake the error message is prompted.