Welcome ! 🙏 Thank you for proposing to contribute to the X-Cash Foundation
Further down are presented a set of guidelines to help you contribute to X-Cash and its derived programs, hosted in the X-Cash Foundation organization on GitHub.
This set of guidelines is not mandatory, although it will greatly help the organizations and maintainers job and keep the contributing environment clean 🧼.
The project is governed by the X-Cash Foundation Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to the project team at [email protected].
When contributing to any X-Cash Foundation repository, please first discuss the change you wish to make via issues, email to [email protected], or any other method with the owners of this repository before making a change.
You are also expected to check the current and previously closed issue for duplicate before opening a new one.
First of all, you will need to determine which program repository relates to your bug (do not post an issue on xcash-core if you are experiencing a problem with the desktop-wallet).
When you are creating a bug report, please include as many details as possible. Fill out the required template. The provided information helps us targeting the issue quicker.
Before creating but reports, please check the repository's issues to see if the problem has already been reported.
Note: If you find a Closed issue that seems like it is the same thing that you're experiencing, open a new issue and include a link to the original issue in the body of your new one.
Bugs are tracked alongside new features request as GitHub issues. After you have determined which repository your bug is relating to, create an issue on that repository and provide the necessary information by filling in the required template.
Explain the problem and include as many details as possible to help the project team to reproduce the problem:
- Use a clear and descriptive title for the issue to identify the problem.
- Describe the exact steps which reproduce the problem in as many details as possible.
- Provide specific examples to demonstrate the steps. Include links to files or GitHub projects, or copy/pasteable snippets, which you use in those examples. If you're providing snippets in the issue, use Markdown code blocks.
- Describe the behavior you observed after following the steps and point out what exactly is the problem with that behavior.
- Explain which behavior you expected to see instead and why.
- Include screenshots if it helps describing the issue.
- If the problem wasn't triggered by a specific action, describe what you were doing before the problem happened.
First of all, you will need to determine which program repository would profit from the proposed enhancement.
When you are creating a new feature request, please include as many details as possible. Fill out the required template, the information it asks for helps us see clearly what you are referring to.
Before creating a new feature request, please check the repository's issues to see if the feature has already been requested or if it's already integrated.
Note: If you plan to work on a new feature, please make sure it has been discussed with the core team
Feature request are tracked alongside bug reports as GitHub issues. After you have determined which repository your feature request is relating to, create an issue on that repository and provide the necessary information by filling in the required template.
Explain the problem and include as many details as possible to help the project team to reproduce the problem:
- Use a clear and descriptive title for the issue to identify the suggestion.
- Describe the current behavior and explain which behavior you expected to see instead and why.
- Include screenshots to help describe the suggested improvment.
- Describe a possible solution if you have an idea already.
While everyone is free to participate in the development and undertake issues, we are proposing bounties to give rewards to some contributions.
These rewarded issues will have a bounty tag, and can be undertaken by anyone in the community after the team assigned the issue through the issue assignation process.
The process of code contribution will go as follow:
- Creating an issue for bug report or a feature request;
- Assigning the issue to a contributor;
- Branching from the
developbranch to work on the feature/bug fix; - Merging back to
developafter the team review.
When an issue is submitted to the repository, the team will review it and assign it a tag to provide an easy reading and classification. An issue that is not being worked on will have the tag Status: Open.
Contributors that wish to start working on an issue will have to write a short application on said issue discussion thread to describe how they plan on undertaking the bug/feature.
The application message should contain:
- A short summary of the contributor skills & experience;
- A broad idea of the approach to correct the issue, estimated time to completion.
An X-Cash Foundation team member will then review the application and assign the issue to one contributor.
To avoid redundancy and people working on the same issue, please refrain to work on bug/feature until the issue has been attributed to you.
Once the issue has been assigned, the contributor can start working locally on its own branch of the repository.
First of all, it is recommended to fork the develop branch of the repository to your local GitHub account, then create a new branch in your local repository.
Pull changes from the upstream branch regularly to avoid merges conflict and to stay up to date. You can follow a tutorial here
The contributor will need to create a new branch based of the develop branch of the current repository.
The new branch should follow the X-Cash Foundation naming convention:
<type>/<subject>where <type> can be:
- feat for features
- fix (bug fix)
- docs (documentation)
- style (formatting, missing semicolons, …)
- refactor
- test (when adding missing tests)
- chore (maintain repository, changed CI configuration, ...)
And <subject> is the title or a four (4) words maximum summary of the issue.
Branch Name Example:
feat/currency-conversionBefore creating a PR: Make sure that your pull request is fixing and issue or is relating to a feature request listed in the repository's issues. If not, please create an issue prior to creating the PR. You can also create a PR even if your changes are not completely done, if you need an early review.
Please follow these steps to have your contribution considered by the maintainers:
- Follow all instructions in the template
- Follow the commit styleguides
- After you submit your pull request, verify that all status checks are passing
What if the status checks are failing?
If a status check is failing, and you believe that the failure is unrelated to your change, please leave a comment on the pull request explaining why you believe the failure is unrelated. A maintainer will re-run the status check for you. If we conclude that the failure was a false positive, then we will open an issue to track that problem with our status check suite.
While the prerequisites above must be satisfied prior to having your pull request reviewed, the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted.
This is not mandatory but highly recommended for every project you are working on.
Please sign your commits when you are pushing new changes to your branch. You can follow a tutorial here.
When you sign your commit, you can prove that the code you submitted came from you and wasn't altered while you were transferring it. You also can prove that you submitted the code and not someone else.
These guidelines are based on the Angular Convention commit guideline
Please use the following guidelines to format all your commit. This helps the maintaners quickly gathering what the commit relates to, and bring some readibility to the overall project:
<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>The commit title should start with the <type>, which can be:
- feat for features
- fix (bug fix)
- docs (documentation)
- style (formatting, missing semicolons, …)
- refactor
- test (when adding missing tests)
- chore (maintain repository, changed CI configuration, ...)
The commit <subject> should follow the following guidelines:
- Use the imperative, present tense ("change" not "changed" nor "changes")
- Don't capitalize the first letter
- Do not end the line with a dot (.)
- Limit to 50 characters or less
The message <body> should follow the same guidelines as the <subject>, with small variations:
- Use the imperative, present tense ("change" not "changed" nor "changes")
- Don't capitalize the first letter
- Do not end the line with a dot (.)
- Limit to 72 characters or less
- Seperate subject from body with a blank line
- Explain what and why vs. how
- Can use multiple lines with "-" for bullet points in body
The <footer> should indicate the referenced GitHub issues that this commit closes.
Commit Message Example:
fix: add delegate name
- add handler for delegate name
- fix display behavior for delegate field
fixes issue #1245