Signed-off-by: YOUR NAME <YOUR.EMAIL@EXAMPLE.COM>
```

`

You can sign-off by default in this project by creating a file
(say "git-template") that contains
some blank lines and the signed-off-by text above;
then configure git to use that as a commit template.  For example:

````sh
git config commit.template ~/best-practices-badge/git-template
```

`

It's not practical to fix old contributions in git, so if one is forgotten,
do not try to fix them.  We presume that if someone sometimes used a DCO,
a commit without a DCO is an accident and the DCO still applies.

### Proactive Approach

We proactively detect and eliminate
mistakes and vulnerabilities as soon as possible,
reducing their impact.
We use defensive design, coding styles,
various tools,
and an automatic test suite with significant coverage.
We also release the software as open source for community review.

## Vulnerability Reporting (security issues)

Please privately report vulnerabilities you find so we can fix them.

See [SECURITY.md](./SECURITY.md) for information on how to report vulnerabilities privately.

## Documentation Changes

Most documentation is in Markdown format (.md files).

Where reasonable, limit yourself to Markdown
that will be accepted by different processors
(e.g., CommonMark or original Markdown).

## Code Changes

Code should be DRY (Don’t Repeat Yourself),
clear, and obviously correct.
Some technical debt is inevitable, but avoid excessive debt.
Improving refactorings are welcome.

### Automated Tests

When adding or changing functionality, include new tests as
part of your contribution.
Ensure Go code has at least 98% statement coverage.
Additional tests are welcome.

We encourage test-driven development (TDD): create tests first, ensure they fail,
then add code to pass the tests.
Each git commit should include both
the test and the improvement to facilitate `git bisect`.

### Security, Privacy, and Performance

Pay attention to security and work with our
security hardening mechanisms.
Protect private information, especially passwords and email addresses.
Avoid tracking mechanisms where possible
and ensure third parties can’t use interactions for tracking.

We aim for decent performance for typical users.
Use benchmark testing as needed
(e.g., see <https://github.com/TomTonic/Set3/blob/main/run_benchmark.txt>).

### Continuous Integration

We use [Github Actions](https://github.com/TomTonic/Set3/actions)
for continuous integration. If problems are found, please fix them.

## Git Commit Messages

Follow these guidelines for writing git commit messages:

1. Separate subject from body with a blank line.
2. Limit the subject line to 50 characters (flexible up to 72 characters).
3. Capitalize the subject line.
4. Do not end the subject line with a period.
5. Use the imperative mood in the subject line (*command* form).
6. Wrap the body at 72 characters (`fmt -w 72`).
7. Use the body to explain what and why, not how

   (git tracks how it was changed in detail, don't repeat that).

## Reuse (Supply Chain)

### Requirements for Reused Components

We prefer reusing components over writing extensive new code.
However, please evaluate all new components before adding them,
including assessing their necessity.
This helps us minimize the risk of relying on poorly
maintained or vulnerable software.
Set3 provides a concise set of functionalities for a
fundamental [abstract data type](https://en.wikipedia.org/wiki/Abstract_data_type).
Therefore, Set3 should not require a Go project using it to pull in a significant
tree of dependencies.

#### License Requirements for Reused Components

All *required* reused software *must* be open source software (OSS).
It's okay to *optionally* use proprietary software and add
portability fixes.

### Updating Reused Components

Please update only one or a few components per commit, rather than
updating everything at once. This approach simplifies debugging.
If a problem arises later, we can
use `git bisect` to quickly identify the cause.