search

Pryaxis / handbook

📒 The guide to running, operating, and being a part of Pryaxis.
MIT License
0 stars 2 forks source link

RFC: Bounties #4

Open hakusaro opened 6 years ago

hakusaro commented 6 years ago

I would like to implement a reward system for working on tasks on the TShock codebase.

Trusted collaborators (members in Pryaxis initially, but then expanded outside) can bid on large scale issues working towards TShock 5 or Orion.

Essentially: I plan to drastically cut expenses down to bare minimums for TShock and create a pool of money available for people to be compensated with. Then, developers submit bids on projects that are undesirable to work on (like adding XML comments for the 785 un-XML commented public members). When pull requests are merged, developers are paid out according to their bid.

If 2-3 people want to work on a task, they can submit a bid and each person can pick their theoretical share. Prior to starting, others can bid and we can give feedback on whether or not the price + proposal are fair.

To prevent a race to the bottom, people cannot bid $0, and people can only submit two bids per project. Basically, a gentlemen's agreement can be worked out until someone starts work. When the PR is submitted and approved the payout is made per the agreement.

The goal is to reward people who want to contribute to TShock but who are also not as motivated to work on hard to do issues (like code cleanup). And also to share TShock development income with you all.

Thoughts?

bartico6 commented 6 years ago

LGTM. Additional incentive to keep the project going is always good. :+1:

hakusaro commented 6 years ago

@bartico6 to be clear, my end goal is to expand this to approved collabs who are outside of our team (like you) too. We just want to make sure that if we get a PR we won't immediately have to reject it because the code is hakusaro-levels of bad

bartico6 commented 6 years ago

So in other words, you want to increase overall code quality by incentivising people to work harder by offering payouts per task, right?

hakusaro commented 6 years ago

Well, not even really code quality so much as codebase maintenance. Code quality would be one goal, but so would development of newer APIs, documentation, new features, etc.

QuiCM commented 6 years ago

Needs discussion on structured rules around how this will work - possibly a handbook addition. Idea seems sound to me

QuiCM commented 6 years ago

I realise now that this is already in handbook. Oops