Skip to content

Latest commit

 

History

History
113 lines (74 loc) · 6.72 KB

CONTRIBUTING.md

File metadata and controls

113 lines (74 loc) · 6.72 KB
Raw

Contributing to OWASP Dependency-Track

Thank you for contributing to Dependency-Track! We appreciate and are thankful for contributions in all shapes and sizes.

Asking Questions

  • Use either Slack or GitHub Discussions to ask questions.
  • Do not open issues for questions. Questions submitted through GitHub issues will be closed.
  • Consult the community-maintained FAQ to see whether your question has already been answered.
  • Avoid contacting individual contributors directly; ask questions in public instead. A well-worded question will help serve as a resource to others searching for help.

The #proj-dependency-track channel in the OWASP Slack space is the best place to ask questions and get in touch with other users and contributors. We provide an invitation to the Slack space here. Please do create an issue if either channel link or invitation do not work anymore.

Filing Issues

Looking for existing Issues

Before you create a new issue, please do a search in open issues to see if the defect or enhancement request has already been filed.

If you find your issue already exists, add relevant comments to the existing issue.

Optionally indicate your interest by reacting with thumbs up (👍). Issues with higher community attention are more likely to be addressed sooner.

If you cannot find an existing issue for your bug or feature request, create a new issue using the guidelines below.

Requesting Enhancements

File a single issue per enhancement request. Do not list multiple enhancement requests in the same issue.

Describe your use case and the value you will get from the requested enhancement.

Reporting Defects

File a single issue per defect. Do not list multiple defects in the same issue.

The more information you can provide, the more likely we will be successful at reproducing the bug and finding a fix.

API server logs (including errors) are logged to the following locations per default:

  • ~/.dependency-track/dependency-track.log (/data/.dependency-track/dependency-track.log within Docker containers)
  • Standard output (use docker logs -f <CONTAINER_NAME> when using Docker)

Errors in the frontend are logged to your browser's developer console (see here for Google Chrome). Issues in the communication between frontend and API server will be visible in the Network tab of your browser's developer tools (see here for Google Chrome).

Depending on the defect, we may ask you for a sample BOM that triggers your issue.

Before sharing BOMs, logs, screenshots or any other resources with us, please ensure that you blank, pseudonymise or remove all references that may leak internals of your organization.

Reporting Vulnerabilities

Please refer to our security policy in SECURITY.md for how to responsibly disclose vulnerabilities to us.

Improving Documentation

Beside extending existing documentation or correcting any errors it may contain, another great way to contribute is to update the FAQ with questions and answers that benefit the community.

Refer to the Documentation section of DEVELOPING.md for a guide on how to build the documentation locally.

Testing Snapshot Versions

Every time a commit is pushed to the master branch, container images are built and published to the snapshot tag. This is true for both API server and frontend:

Testing snapshot versions and providing early feedback helps in improving the quality of new releases. The private #proj-dependency-track-beta Slack channel is intended for discussions about and feedback for snapshot versions. If you are interested in participating, please let us know in #proj-dependency-track.

Contributing Code

Before raising pull requests, please file a defect or enhancement request first.

  • We use GitHub milestones to plan what will be included in the next release.
    • Depending on the size of your PR and whether it introduces breaking changes, we may schedule your change for a later release.
  • Issues for which community contributions are explicitly requested are labeled with help wanted.
  • Issues suitable for first-time contributors are labeled with good first issue.

DEVELOPING.md provides a detailed guide on how to get started with working on Dependency-Track.

Pull Requests

  • Pull requests that do not merge easily with the tip of the master branch will be declined.
    • The author will be asked to merge with tip and submit a new pull request.
  • Code should follow standard code style conventions for whitespace, indentation and naming.
    • In the case of style differences between existing code and language standards, consistency with existing code is preferred.
  • New functionality should have corresponding tests added to the existing test suite if possible.
  • Avoid new dependencies if the functionality that is being used is trivial to implement directly or is available in standard libraries.
  • Avoid checking in unrelated whitespace changes with code changes.
  • Commits must be signed off to indicate agreement with Developer Certificate of Origin (DCO).
  • Optionally include visualizations like screenshots, videos or diagrams in the pull request description.

Commit Messages

Please follow these rules when writing a commit message:

  • Separate subject from body with a blank line
  • Limit the subject line to 50 characters
  • Capitalize the subject line
  • Do not end the subject line with a period
  • Use the imperative mood in the subject line
  • Wrap the body at 72 characters
  • Use the body to explain what and why vs. how