The Silent Pay project operates an open contributor model where anyone is welcome to contribute towards development in the form of peer review, testing and patches. This document explains the practical process and guidelines for contributing.
If you have questions about how to use Silent Pay direct these to Discord.
The project is divided into four modules.
├── packages
│ ├── core
│ │ ├── src
│ │ └── test
│ ├── esplora
│ │ ├── src
│ │ └── test
│ ├── level
│ │ ├── src
│ │ └── test
│ └── wallet
│ ├── src
│ └── test
Directory | Description |
---|---|
packages/core |
Contains core library functions that are needed to support silent payment integration in a wallet. |
packages/esplora |
Provides an Esplora client which implements the network interface. |
packages/level |
Provides a file-based key value database which implements the db interface. |
packages/wallet |
Encompasses the wallet class which is responsible for all wallet-operations. |
Make sure you have Node.js LTS version and npm (or Yarn) installed. Clone the repository and run npm install
(or yarn
) to get started.
This section guides you through submitting a bug report. Following these guidelines helps maintainers and the community understand your report, reproduce the behavior, and find related reports.
- Ensure the bug was not already reported by searching on GitHub under Issues.
- If you're unable to find an open issue addressing the problem, open a new one. Be sure to include a title and clear description, as much relevant information as possible, and a code sample or an executable test case demonstrating the expected behavior that is not occurring.
Feature requests are welcome. But take a moment to find out whether your idea fits with the scope and aims of the project. It's up to you to make a strong case to convince the project's developers of the merits of this feature. Please provide as much detail and context as possible.
- Do not include issue numbers in the PR title
- Follow the coding style (Prettier/ESLint)
- Separate unrelated changes into different PRs
- All PRs must add tests for the proposed changes
- Write meaningful commit messages
- Use the present tense ("Add feature" not "Added feature")
- Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
- Limit the first line to 72 characters or less
- Use description to add more context to the commit message
- The core library should only contain pure functions and should not contain classes.
- Use
const
for all variables that should not be reassigned. - Use
readonly
for all fields that should not be mutable. - Use PascalCase for types, interfaces and classes, camelCase for variables and functions.
- Use TsDoc for documenting code
- Use Markdown for READMEs and other documentation files
- Adding documentation is a must for every PR
The maintainers look at pull requests on a regular basis and will provide feedback. After feedback has been given, it is up to the PR author to continue the conversation or make changes.
The project uses GitHub Actions for CI/CD. All PRs are required to pass the CI/CD checks before they can be merged.
This section lists the labels we use to help us track and manage issues and pull requests.
bug
: A bug or errordocumentation
: Improvements or additions to documentationenhancement
: New feature or request for enhancementgood first issue
: Good for newcomershelp wanted
: Extra attention is neededquestion
: Further information is requestedwontfix
: This will not be worked onduplicate
: This issue or pull request already exists
If you need help with anything related to contribution, feel free to ask questions or seek guidance from the community or maintainers.