Check out the Issue Explorer
Looking to fund some work? You can submit a new Funded Issue here.
### User Story
As a **Developer** contributing to buidlbox
I want to have fully groomed and thought out Github issues on features to work on
So that I can put my software engineering skills right to work building great features
The main idea behind the ticket is that uPort will be providing ideas that will then be groomed out by a Bounty Hunter by providing a User Story, Background, Acceptance Criteria, and Technical Details. This is essentially crowdsourcing the Project Management task of ticket grooming.
This issue is designed to incentivize the OSS community to help contribute fully fleshed out issues for features for the buidlbox project. This issue is NOT for the fulfillment (coding) of these issues, that is out of scope :)
It will be funded with 100 DAI ($100 USD) with successful completion of Acceptance Criteria rewarding the Author with 25 DAI ($25 USD) for fleshing out an issue that builds on a `bounty candidate` (see below). The study will run for 2 weeks from Wednesday 4/18 at 8 PM EST or until the funds are exhausted, whichever comes first 👍🏻
If successful, the idea is that this will be lead to a continuous program bountying program for buidlbox. Happy writing!
Note: creation of this issue uses concepts learned from the successful `Bug Bounty` issue at https://github.com/gitcoinco/web/issues/760 👍🏻
### Bounty Candidates
**Bounty Hunter** creates a Github issues that uses one of the `Bounty Candidate`'s belows as a base:
1. Intermediate Smart Contract - Add Smart Contract function call to transfer admin privileges.
2. Intermediate Smart Contract - Change Smart Contract initialization function to include an admin parameter so the default admin can be set on smart contract initialize that is NOT the creator.
@KamesCG as these `bounty candidates` are on the https://github.com/KamesCG/meshconnect repo, I think it makes sense to have this **Issue Feature Bounty Program** issue on that repo. Does that make sense? 🤔
### Acceptance Criteria
Github issue has
- A **Title** describing the feature
- A **User Story** with the template of "As a.../I want..../So That..."
- A **Background**, a few sentences on what the project is about and why the feature is necessary.
- **Acceptance Criteria**, in bullet points, everything that is needed for this ticket to be considered finished (sometimes referred to the "Definition of Done")
- **Technical Details** informing the process of ways the developer could approach the solution. This isn't at the level of specifying individual lines of code, but things like recommendations on which libraries/packages to use, where models should live, folder structure, etc.
- **In Scope/Out of Scope** what should be affected and what shouldn't be.
- **Test Cases** (optional) are end-to-end tests that will pass after desired functionality is built out. Optional but could help inform some issues.
For an example, please refer to this issue itself which has all of the above requirements except for **Technical Details** and **Test Cases** as this isn't a technical issue. Meta 😎
### In Scope
0. Delivering fully fleshed out Github issues for features for the buidlbox project.
### Out of Scope
0. Fulfillment (coding) of these Github issues
Very interested and receptive to feedback 💪🏻🤠👍🏻@abitrolly if you've got some spare cycles would love to hear what you have to think!