Skip to content

Latest commit

 

History

History
31 lines (23 loc) · 1.78 KB

bug-bounty-program.md

File metadata and controls

31 lines (23 loc) · 1.78 KB

Guidelines for bug bounty submissions

  • An issue will be considered un-claimed until a pull request has been made and the claim has been approved by a core contributor. Claiming an issue on gitcoin.co is not sufficient.

  • A good pull request might open with unit tests before any changes are written. Tests serve as good examples when discussing the scope of work to be performed.

  • Settle expectations early, either in discussion or with tests. This will save you from wasted effort. Make sure you have understood the parameters of the request before diving in.

  • Review the other sections of this tactical guide. Conforming to the team's coding style will help ensure your pull request will be integrated.

  • Some issues may prove to be bigger projects than estimated when the bounty was set. Feel free to make a case to either increase the bounty or reduce the scope of the request. It is up to a the core team whether an adjustment will be made.

  • The bounty value is set assuming a claimee who is familiar with the code base. In other words, a first time contributor is expected to take as long as they need to familiarize themselves with the project and the team's contribution guidelines. This added time is not a sufficient reason to increase the bounty.

  • Work will be considered complete when the following items have been met:

    • The submission fulfills all the parameters set forth in the initial discussion.
    • Tests have been written for any bugs described in the issue and/or all new code.
    • The project documentation has been updated to reflect changes to the api.
    • All review requests have been met or resolved.
    • The submission conforms to the team's coding style documented in this tactical guide.
    • The change has been approved and merged by a core contributor.