Repository Management
While the following guidelines are not an absolute requirement, writing your code by these standards will ensure greater compatibility with the Swipechain and increases the likelihood your pull request will be accepted.
Structure
Repositories across an organization should have a consistent basic structure to make it easy to find everything across different repositories.
At a bare minimum a repository should contain the following:
- README.md - Should contain at least a description, installation instructions and a contact address for security issues.
- LICENSE - Should contain the software license of the project, commonly the MIT License for open-source projects.
- .editorconfig - Should contain a configuration that is enforced by everyone's editor if an appropriate plugin is installed.
- .gitignore - Should contain a list of files and directories that should not be committed with
git push
. - .circleci/config.yml - Should contain a configuration for CircleCI to run tests.
Development
When a new repository is created for a project, the first thing you should do is create a develop
branch and set it as default. This will indicate to developers that this project is not stable yet. This branch should be used until the initial implementation is done, and merged to master
without squashing. master
should then be set as the default branch.
Once the initial implementation is done and merged, only squash merging should be enabled and all future PRs should be squashed with meaningful commit messages.
Squashing Pull-Requests
When working on any project all pull-requests must be squashed.
The goal of doing so first and foremost is to keep PRs small and focused on a single issue. If you think to yourself: "all my hard work and organized commits are going to be lost", then your PR is most likely out of scope and trying to solve more then one issue at a time which means you should split it up into multiple PRs that are meaningful even after being squashed.
Another benefit of squashing is to have a clean & flat git history which allows to easily blame changes without having to go through 100 commits to finally reach what you were looking for.
We only care about the net effect of the pull-requests, i.e. "feat: wallet integration". We don't care about the 30 commits of "bugfix, added, removed, refactored". We want a clear and concise history without any noise.
How to Label and Organize GitHub Issues & Pull Requests
To make everyone's life easier when looking for issues or pull requests of specific types, priority or severity it is important to make proper use of labels so it is possible to identify the status and importance without having to look into it.
Notes
- The
Type: Bug
label always has to be combined with aPriority: *
andSeverity: *
label to indicate how severe the problem caused by the bug is and how many users are affected by it. The combination of those determines how fast the bug needs to be fixed. - Bounty tiers need to be assigned before a pull request is merged. If no tier is assigned or is assigned to a team member the SwipeChain Bot will comment in the affected issue.
- For issues that are tasks a
Difficulty: *
label should be assigned to provide developers a sense of how much work it will be. - The
Complexity: *
labels should never be assigned manually as the SwipeChain Bot will evaluate the complexity of a pull request and assign a label.
Bounty
Tier 0
- Custom reward at the discretion of the team, for large projects or changes.
Tier 1
- Awarded for big features, important fixes or significant improvements. This is valued at 100 USD.
Tier 2
- Awarded for performance, minor features or substantial documentation changes. This is valued at 50 USD.
Tier 3
- Awarded for code refactoring, moderate docs changes or full translations. This is valued at 25 USD.
Tier 4
- Awarded for adding test coverage or resolving small bugs. This is valued at 10 USD.
Tier 5
- Awarded for small documentation updates or minor code refactoring. This is valued a 5 USD.
Tier 6
- Awarded for typos, text corrections, dependency updates, etc. This is valued a 1 USD.
Complexity
Undetermined
- Needs specialized, in-depth review.
High
- More than 256 lines changed.
Medium
- Less than 256 lines changed.
Low
- Less than 64 lines changed.
Difficulty
Challenging
- The issue requires an extensive understanding of the code base.
Advanced
- The issue requires an advanced understanding of the code base.
Intermediate
- The issue requires a basic understanding of the code base.
Beginner
- The issue doesn't require any specific knowledge about the code base.
Environment
Development
- The issue or pull request affects the development environment.
Production
- The issue or pull request affects the production environment.
Test
- The issue or pull request affects the test environment.
Continuous Integration
- The issue or pull request affects the continuous integration environment.
Platform
Windows
- The issue or pull request affects users on Windows.
Linux
- The issue or pull request affects users on Linux.
Android
- The issue or pull request affects users on Android.
macOS
- The issue or pull request affects users on macOS.
iOS
- The issue or pull request affects users on iOS.
Priority
Critical
- The issue or pull request will affect all users.
High
- The issue or pull request will affect most users.
Medium
- The issue or pull request will affect roughly half of users.
Low
- The issue or pull request will not affect most users.
Severity
Critical
- The issue is blocking an upcoming release.
High
- The issue causes data loss, crashes or hangs processes, makes the system unresponsive, etc.
Medium
- The issue reports incorrect functionality, a confusing user experience, etc.
Low
- The issue reports cosmetic items such as formatting, spelling, colors, etc.
Status
Abandoned
- The pull request could not be merged because it did not get any updates in a timely fashion.
Won't Fix
- The issue is legitimate, but it is not something the team is currently able or willing to work on.
Resolved
- The issue has been resolved.
Owner Approved
- A code owner has approved the pull request.
Member Approved
- A member has approved the pull request.
Collaborator Approved
- A collaborator has approved the pull request.
Contributor Approved
- A contributor has approved the pull request.
Accepted
- The proposed solution has been accepted.
Available
- The issue is not assigned to anyone and available to be worked on.
In Progress
- The issue or pull request is being worked on.
On Hold
- The issue or pull request is not being worked on for the time being.
Stale
- The pull request is in need of updates but there has not been a sufficient response.
Blocked
- The pull request is blocked from being merged for the time being.
Cannot Reproduce
- A developer of the team cannot reproduce the issue.
Reverted
- The pull request was reverted after an initial merge.
Has Merge Conflicts
- The pull request cannot be merged because it has a merge conflict.
Tests Failing
- The Circle CI build failed when running for this pull request.
Needs Information
- The issue needs more information before it can be verified and resolved.
Needs Investigation
- The issue needs more investigation before it can be verified and resolved.
Needs Review
- The issue or pull request needs a review by a developer of the team.
Needs Testcase
- The issue or pull request relates to a feature that needs test coverage.
Needs Changes
- The pull request needs additional changes before it can be merged.
Needs Discussion
- The issue or pull request needs more discussion before it can be closed or merged.
Needs Documentation
- The pull request needs additional documentation before it can be merged.
Test
General
- The issue or pull request is related to the test config, platform or setup.
Functional
- The issue or pull request is related to functional tests such as end-to-end or browser testing.
Integration
- The issue or pull request is related to integration tests between internal or external elements.
Unit
- The issue or pull request is related to unit tests for testing individual elements.
Type
Feature
- The issue is a request for new functionality.
Release
- The issue or pull request is related to an upcoming release.
Maintenance
- The pull request updates dependencies or configuration files.
Performance
- The issue or pull request relates to performance.
Refactor
- The pull request improves or enhances an existing implementation.
Duplicate
- The issue or pull request is a duplicate of another feature request or bug report.
Expected Behaviour
- The issue is a bug report, but the behavior is intended.
Breaking Change
- The issue or pull request documents or introduces a breaking change.
Bug
- The issue relates to broken or incorrect behavior.
Bugfix
- The pull request fixes an incorrect functionality or behavior.
Regression
- The issue is a bug that relates to functionality known to work in previous releases.
Security
- The issue documents functionality that could expose private data or cause harm otherwise.
Discussion
- The issue is a discussion about a generic topic.
Documentation
- The issue or pull request relates to documentation.
Information
- The issue contains information for users by a developer of the team.
Question
- The issue is more of a question than a request for new features or a report of broken features.
Task
- The issue is a request to set up third-party integrations or any general non-code related tasks.
Good First Contribution
- The issue appears to have a simple solution.
Standards
- The issue reports problems with the compliance of contribution guidelines or code standards.
Weekly Digest
- The issue is a weekly report of the latest activities.
Assigning Bounty Tiers Before Merging a Pull Request
Before a developer merges a PR, it is required to assign one of the seven bounty labels. Those labels will be used by the SwipeChain Bot to calculate bounty rewards and inform the contributors about those and other activities or requests.
Tier 1 - $100
Tier 1 pull requests cover substantial code changes that usually bring new functionality and have a higher impact on the codebase.
Examples of this include a new API endpoint, resolving structural issues that cause circular dependencies, or adding new bigger features to our codebase (an example would be settings page to the explorer, adding new indenticon package to the desktop wallet or a new small non-essential plugin in the Core).
Tier 2 - $50
This tier covers medium features and improvements to the codebase that bring in new functionality, have a big impact on the performance of the product or significant optimizations and refactors of the code.
An example would be optimizing some parts of the Core for improved performance of a specific function, implementing a medium, non-critical new feature in the desktop wallet or writing large documentation files that require an understanding of the Swipechain code.
Tier 3 - $25
These pull requests cover smaller refactors or optimizations of the code or small non-essential features.
An example of this would be reducing complexity or improving the performance of existing code, improving the readability of the code or writing new documentation files, full translations of the projects aka desktop wallet or mobile wallet.
Tier 4 - $10
Standard small tier pull requests that fix minor bugs or add a new test.
Examples of this include adding more test coverage for existing functionality or resolving small bugs that usually get reported by users.
Tier 5 - $5
Small documentation updates or improvements that don’t have much code or smaller refactors of the code.
Tier 6 - $1
The lowest tier is for items that don’t usually have much to do with the code, but rather, are considered cosmetics.
An example would be a typo, language corrections, grammar corrections, dependency update, link updates or broken links.
Tier 0 - Custom
If you want to work on much more significant changes or custom projects that you don’t think fit any of the above tiers contact us at bounty@swipechain.org.
Some examples of what a custom tier 0 could cover — developing new modules for core
that bring in new functionalities (PoW module instead of DPoS), different voting systems, proxy voting, implementing AIPs …
Some issues will also have labels with custom (usually higher) values that you can take on. Labels on those issues will have a defined monetary value, so if you see these available you can request to take point on resolving them. Upon completion and review you will receive payment in Swipechain.