Go on you know you want to [Nick said he would do this and he has, cheers @nicklambert ]
MAIDSAFE CODE BOUNTY PROGRAM
We have mentioned the introduction of a code bounty programme a few times recently and, in the true spirit of Open Source software, we want the community to be able to take an active role in helping MaidSafe roll out the SAFE Network. This will not only decentralise and spread knowledge of how the network functions, it will also enable SAFE to be released more quickly. The following post will provide a bit more detail on how we see MaidSafeās code bounty programme working initially.
MaidSafe will publish tasks at the start (and potentially during) a development sprint. These tasks will be listed in Jira where anyone with a Jira ID will be able to claim and start a task. The tasks will be fully specced out by the maintainer of that library whose e-mail address is published in that libraryās GitHub readme. If you feel the task description is not clear then you should contact the library maintainer prior to accepting the task in Jira. The fact that it is not clear could be a sign that it isnāt well suited to your skill set. Here is a rundown of the terms:
The terms
Participation will be on a first come first serve basis
The bounty only applies to open Jira tasks identified by the MaidSafe team
The developer that claims the task will be given a sufficient amount of time to complete it. For example, a task that is scheduled for 8 points (around 8 hours work) should be completed in one day. However, if a GitHub pull request is not received at the end of this period, or the task is not correct (doesnāt pass tests/ other task requirements as specified in the task description), it will be made available to the rest of the community. We will need to be strict about timescales and work quality to avoid delays
All submissions should take the form of a GitHub pull request
If the task is complete (meets the spec and passes all tests ((including coverage)), MaidSafe will pay the bounty (in bitcoin) to the successful developer
MaidSafeās core development team and employees are not eligible for rewards
The rewards
$20 per story point (paid in bitcoin only). Story points are used by MaidSafe to estimate task timescales
1 story point is typically calculated to be around 1 hours work
The reward will be paid on the merge of a contributors pull request to a btc account of their choosing. We would also donate the bounty to the preferred charity (one that accepts bitcoin) of the developer should they prefer. Contributors should enter the bitcoin address they would like the bounty paid to into the pull request description field
An exclusive and limited SAFE Network core dev t-shirt (this is a one off reward and is limited to one shirt per developer)
The developers name added to the main SAFE Network repositories
This is a process that is likely to change over time as the bounty programme develops and grows. We plan on starting the programme slowly and in about 2 weeks time we will identify the tasks from the current sprint (RUST-3) that are eligible. Over time, we anticipate opening up all Jira tasks to the community, but we would like to trial the process first. In future, we may start to pick much bigger pieces of work, such as the addition of specific network features, and ask community members to compete for them. These types of projects would obviously carry many more story points and be much more lucrative, but we should learn to walk before we can run!
So, hopefully this provides some more detail about the bounty scheme as a whole and we will start to announce applicable tasks in the next couple of weeks. We canāt wait to start working with you all more closely!
Iām looking forward to contribute in the project and this way is quite exciting. And I want that T-Shirt !!
Although the āfirst come first serve basisā implies to be all time looking for new tasks. Maybe a subscription system can be betterā¦
I want you to have a wardrobe of these tee shirts I would love us to get this up to speed where we can still plan, architect and minimum get code done like this more and more and then creep into the other areas as well. You will see the pattern where we push knowledge out as fast as we can and love it. Looks like a business plan to put us out of business, but in fact the exact opposite is the case. This makes us super human and the community stronger than insulted Spartans
I am very hopeful for this and I hope it engages and encourages the SAFE Pods and curious individuals, everyone really, they need it and now I believe we are laying some concrete foundations with lesser ownership by the day, very comforting.
Welcome aboard (youāre already a core contributor, so off to a great start).
The t-shirt is very cool. @Shona has done a really great job designing them and we are just about to place the order, weāll post pics when they arrive.
Yes and folks please get into reviews as well, spot anything even typoās in comments jump on it! Your critique will be welcome. Bear in mind we have a technical debt and another security sprint in the pipeline but after we get bundle 3 out the door. So you will find things to pick at for sure.
Thinking about the practicalities of joining in, I think it would help if you can consider the situation of new people, unfamiliar with the code, processes etc.
So, for example, expecting an 8 point job to be completed in 8 hours might be fine for the library maintainer who knows everything inside out, but way too quick for someone else who is getting up to speed.
Iām not sure how this can be made more attractive for new folk without slowing the project, but the prospect of putting in a dayās work and then having the task taken off you would be discouraging.
Also, people do work at different rates, estimates are often optimistic compared to reality, so this could easily become a significant barrier to external devs. External devs will often not be full time, but working in their spare time. Etc.
One way to alleviate it would be to stretch the timescales for tasks not on the critical path, and to encourage new devs to go for these until they are fully up to speed.
Can anyone think of any other ways to alleviate this?
No seriously there will be some tasks with low number of points and these are best to start with, also really reviews help. I use reviewable.io which you will see links for. It means you get used to debating and querying in the code, we are self critical and openly critical of things we donāt like. Much of that is personal preference so not so valid, but good to get used to being directly asked questions that seem harsh. Itās never harsh (or I jump in ) but logical and fast I hope.
So nice to get used to knowing itās not scary and actually when we are picking on each others code we are friendly, but may not look like it as we go for speed so seems curt. Itās good though there is much at stake and every bug we find is brilliant.
Even getting up and running on other devices and adding into CI etc. is helpful. Initially dev bounties, I really want to push that out though to cover all help that is valuable. We keep doing this a bit t a time and make all the mistakes we need to and we may end up with being able to handle that core dev 5% bounty as fairly as we can.
Wish i could join on in now but alas am not yet comfortable with my rust coding. For now will just stick into reading the code and take what i can learn from there. All the best to the developers who will jump into this should be exciting
Itās been suggested to me to join slack if Iād like to help on the core development, but it seems to require a maidsafe email account. Is there a right way to get involved from the outside? Is the slack email domain restriction not really the case? Iām on atlassian already, btw. Thanks!
@dirvine what are the stats for this if you donāt mind. How many contributions to the tasks on Jira has the project received? If any how smooth was the acceptance of the pull request into a merge from the contributor?
AFAIK there have been no sprint specific tasks complete by the community so far (I may be wrong). you can see for yourself in Jirs etc. We hope the next sprint will allow more participation, this one was manically fast and many internal logic changes, so harder perhaps. We will keep trying though, itās worth it
@dirvine Yeah i guess there was a lot of refactoring in this sprint plus new repos out of it. My guess is a lot of the tasks where based on internal discussions of the main dev team.
Also it would be good to have more info on the tasks. More than a paragraph where possible. When task is not self explanatory.
Right now am just reading the code i think it will help a lot to as i try to catch up to you guys by the next Sprint
[Nick said he would do this and he has, cheers @nicklambert 
I would love us to get this up to speed where we can still plan, architect and minimum get code done like this more and more and then creep into the other areas as well. You will see the pattern where we push knowledge out as fast as we can and love it. Looks like a business plan to put us out of business, but in fact the exact opposite is the case. This makes us super human and the community stronger than insulted Spartans 
brave 
