200 PTS - Bounty Rules and Procedures Document [Closed]

[barwizi]

PDF on google now

https://drive.google.com/file/d/0BxCtiOzdwvPyYzdlR1hnWFdQeWM/edit?usp=sharing

happy new year guys!!!

[AJ_]

I've set up a google site (https://sites.google.com/site/invictusbounties/home) displaying our set of rules, as well as an idea of a submission form and a sample bounty and form

[barwizi]

https://drive.google.com/file/d/0BxCtiOzdwvPyYzdlR1hnWFdQeWM/edit?usp=sharing

I've uploaded a PDF for your perusal, it includes the above mentioned fixes and a cheapo diagram...i'm not good with those.

[barwizi]

https://docs.google.com/document/d/1bONQMtAFlpJO3T4MDAW-fXZBrE6iSBp4LWZ2RYX3Zc8/edit?usp=sharing

I copied phoenix work then tried my hand on his almost complete work, great job by the way.

We are also incorporating the tips for bounty posters to our version

Thanks for the submission.  I am providing feedback now, but want to make one thing very clear.  The price tag I placed on this particular bounty is reflective of the amount of work I expect it to take to really nail down solid bounty rules and to present them in a professional manner (more than a plaintext document).   

That said here are some questions:
1) How are mediators selected and what authority do they have?   How does this conflict with 'customer is always right'? 
2) How do you measure compliance with clear expectations?  Obviously it is in the best interest of the submitter to attempt to provide as much clarity as possible, but sometimes what the submitter is looking for is someone who will help define the specific requirements and explore options.   I think bounties are not contracts, but an expression of interest to buy.   Take the bounty for this document, I expect to buy bounty rules/procedures that are worth every PTS we pay for them.    To achieve that threshold the rules must be very good at preventing conflict, managing expectations, and encouraging collaboration.    Rules that cause conflict by establishing the expectation of a contract or particular outcome in need of dispute resolution are less valuable than rules that avoid most of these conflicts before they start.

3) For software bounties there should be a procedure for quality control that encourages people to find bugs and coding violations as well as test the build on multiple platforms.  Software bounties are probably going to require the most rigorous procedures to ensure proper code review.   Bugs discovered are deducted from the submission payout or my result in the submission being rejected until bugs are fixed.  How do we structure the rules so that there is proper incentive for proactive quality control?

That is the thoughts I have for now.

I believe that mediators should be reputable people on this forum. We can start a poll thread where Posters, Applicants and other everyday users can vote for who they believe is fair and most qualified for the positions. It is community centred and i believe will be effective as there can be no bias.

In response to (2) perhaps we can implement another status ( Construction ) where the submitter converses with those interested in the bounty and they agree on the terms of compliance and what is expected. If the submitter requires someone to professionally define the requirements, they would agree on a fee. As for exploring options, i think that should be part of the conversation as the applicants offer their ideas, until the submitter finds one that suits him.

You are right an expression of interest to buy would be the best way to put it. I'll try to get the rules to not conflict while maintaining a non-restrictive document.

I think perhaps i will attempt to group the bounties by general area and set additional rules for each group. I will think on all you have said and bring a proposed solution.

[bytemaster]

https://docs.google.com/document/d/1bONQMtAFlpJO3T4MDAW-fXZBrE6iSBp4LWZ2RYX3Zc8/edit?usp=sharing

I copied phoenix work then tried my hand on his almost complete work, great job by the way.

We are also incorporating the tips for bounty posters to our version

Thanks for the submission.  I am providing feedback now, but want to make one thing very clear.  The price tag I placed on this particular bounty is reflective of the amount of work I expect it to take to really nail down solid bounty rules and to present them in a professional manner (more than a plaintext document).   

That said here are some questions:
1) How are mediators selected and what authority do they have?   How does this conflict with 'customer is always right'? 
2) How do you measure compliance with clear expectations?  Obviously it is in the best interest of the submitter to attempt to provide as much clarity as possible, but sometimes what the submitter is looking for is someone who will help define the specific requirements and explore options.   I think bounties are not contracts, but an expression of interest to buy.   Take the bounty for this document, I expect to buy bounty rules/procedures that are worth every PTS we pay for them.    To achieve that threshold the rules must be very good at preventing conflict, managing expectations, and encouraging collaboration.    Rules that cause conflict by establishing the expectation of a contract or particular outcome in need of dispute resolution are less valuable than rules that avoid most of these conflicts before they start.

3) For software bounties there should be a procedure for quality control that encourages people to find bugs and coding violations as well as test the build on multiple platforms.  Software bounties are probably going to require the most rigorous procedures to ensure proper code review.   Bugs discovered are deducted from the submission payout or my result in the submission being rejected until bugs are fixed.  How do we structure the rules so that there is proper incentive for proactive quality control?

That is the thoughts I have for now.   

[AJ_]

https://docs.google.com/document/d/1bONQMtAFlpJO3T4MDAW-fXZBrE6iSBp4LWZ2RYX3Zc8/edit?usp=sharing

I copied phoenix work then tried my hand on his almost complete work, great job by the way.

We are also incorporating the tips for bounty posters to our version

[phoenix]

https://docs.google.com/document/d/1bONQMtAFlpJO3T4MDAW-fXZBrE6iSBp4LWZ2RYX3Zc8/edit?usp=sharing

I copied phoenix work then tried my hand on his almost complete work, great job by the way.

What I originally had wasn't anywhere near as good as what AJ_ has made it, but thank you. I like your division into rules and ethics, as well as changing the spacing so things are more visually pleasing.

[barwizi]

https://docs.google.com/document/d/1bONQMtAFlpJO3T4MDAW-fXZBrE6iSBp4LWZ2RYX3Zc8/edit?usp=sharing

I copied phoenix work then tried my hand on his almost complete work, great job by the way.

[CLains]

It is difficult to read the document. I suggest clearing it up with an index, some headers, adequate spacing and a one word summary of points 1-20.

[barwizi]

Here's what we've come up with so far. It still needs a lot of revision, re-organizing, and it can probably be shortened quite a bit before we're ready to submit it. We'd love to hear what people think of it so far.

https://docs.google.com/document/d/13WcUclETG-tmlAIxdO39E56uWQnPIozGHOEP4fBGQeY/edit?usp=sharing

Can I collaborate on this?

[bytemaster]

Here's what we've come up with so far. It still needs a lot of revision, re-organizing, and it can probably be shortened quite a bit before we're ready to submit it. We'd love to hear what people think of it so far.

https://docs.google.com/document/d/13WcUclETG-tmlAIxdO39E56uWQnPIozGHOEP4fBGQeY/edit?usp=sharing

Imagine you hear a radio ad announcing $2 million worth of bounties and you want to visit a site to discover how it all works.... this document should be targeted at that audience. 

I see some things that appear conflicting (so far it seems mostly like an aggregation of ideas I have presented).

I like the requirement to RESOLVE DISPUTES PRIOR to submission. 

I think we can remove the option for arbitration based upon the new concept of buying off-the-shelf products rather than for-contract products.

I think the document should include concepts like:

1) submitter who presents a range of addresses and balances so we can issue a single multi-output transaction to pay everyone.  The allocation in this table is what may be disputed.

2) I think offers of support (to enhance the submission) should be optional, a competitive edge, etc.

3) I don't want this to be a bidding system because we have no way to evaluate the bidders skills.   We pay more to get competitive solutions rather than competitive bids. 

More thoughts later, but this is what I have thus far.

[phoenix]

Here's what we've come up with so far. It still needs a lot of revision, re-organizing, and it can probably be shortened quite a bit before we're ready to submit it. We'd love to hear what people think of it so far.

https://docs.google.com/document/d/13WcUclETG-tmlAIxdO39E56uWQnPIozGHOEP4fBGQeY/edit?usp=sharing

[bytemaster]

About how long should developers expect to have to support their contributions after the bounty has been awarded to them? Also, what kinds of support will they be expected to provide?

We should have our initial thoughts and ideas ready to show by sometime tomorrow. This will in no way be a final entry, unless you're willing to pay the full bounty for what we have already. We'll just be looking for feedback for what we have so far

With respect to voting, it is not about cheating but because I fundamentally disagree with the method for economic reasons.

With respect to support, I don't want a lot of legalese or binding contracts.  Contracts based upon future 'promise to perform' are not valid because your will is not alienable.  For more information on my view of valid contracts see: http://mises.org/rothbard/ethics/nineteen.asp

I recognize that this view on contracts runs contrary to the conception of 99.9% of people out there, but I also believe that there is wisdom in applying this view for avoiding the need for legal battles.

We are also doing international trade and contracts are generally not enforceable.  The conclusion is that the incentives and motivations should be such that enforceable contracts are not necessary.   Instead we buy a product and use it, we are not CONTRACTING for the development of a product.  We simply make our desire to buy a product that doesn't yet exist known.   

Overall I want bounties to be based upon the following premise:

1) Invictus is looking to buy complete, off the shelf solutions.
2) Invictus may or may not know exactly what we want until we see it.
3) The customer (Invictus) is always right
4) Invictus does not buy stolen work
5) Invictus does not buy work built in secret
6) We recognize we are asking the market to do work speculatively that may or may not pay, bounty prices will be higher as a result to compensate for the risk.
7) We want submitters to focus on making the customer happy by providing products we want to buy and to understand that they have no right to demand payment for something we do not decide to buy and use.
Our use of the product of a bounty is the objective criteria that we purchased it and payment is due.

In other words we want to over pay so we have the right to be picky and not do business with those who complain about our selection process or changing requirements.  It should still be profitable to participate in the ecosystem we are building and to earn these profits involves risks, efficiency, and skill.   

If we can communicate the proper mindset for bounty participants we can avoid a lot of complaining or dashed expectations. 

[phoenix]

About how long should developers expect to have to support their contributions after the bounty has been awarded to them? Also, what kinds of support will they be expected to provide?

We should have our initial thoughts and ideas ready to show by sometime tomorrow. This will in no way be a final entry, unless you're willing to pay the full bounty for what we have already. We'll just be looking for feedback for what we have so far

[bytemaster]

Sure


Sent from my iPhone using Tapatalk