200 PTS - Bounty Rules and Procedures Document [Closed]

[wasthatawolf]

I stand by my basic premise that the bounty system in its current form creates a lot of wasted effort by those whose submissions are not chosen and has not resulted in the highest quality products. 

All I'm attempting to do with this proposal is maximize the utility of all work done by members of the community while getting the highest quality, best value product on time and keeping everyone informed every step of the way.  I think we can all agree these things are important to us as stakeholders.

Being as this is just an informal idea, I expect certain aspects to be changed and better defined.  In the interest of being clear and concise here are my key points:

- Developers submit a proposal with some proof of ability to complete the task (I'm not suggesting disclosing your real identity, that's not what I meant by resume/references) -> best quality
- Project cost is not defined upfront, it is submitted as part of the proposal -> best value
- Once a proposal is chosen by the community, the developer is paid incrementally as work is completed (increments do not have to be time driven per say, but I think there should be a firm date for final project completion) -> incentivize "risk averse" talent to submit proposals
- Project is transparent and open to comment from inception to completion (I can agree we are basically at this point) -> community driven

I'm sure there are methods to facilitate a process like this that I haven't thought of.  I'm just throwing this all out there to see what other members of the community think.

Also, I don't think the bounty system is all bad and I think it can/does work great for smaller, specific tasks.  I just don't think it has been working that great for the larger more complex ones.

[barwizi]

The size of the payout makes the risk worth your time, although this raises some questions.
Also you'll find that all bounties regardless of their size already have groundwork being laid out, read through them.

Also, in the end, the process is centralized.  The final decision is just a judgement call by bytemaster with no real measurable metrics (as most submissions meet the basic requirements).  Obviously, it's his company and he has the ultimate decision, but, why not create a new process that facilitates that decision to the point that by the end of the process its obvious to everyone what the final product will be.

Did you really read through the document? if so you'd note the insistence on publicity, this is to ensure open development processes kind of like conversation you have joined, showing that the system works. If it was not open, all you would have seen was a set of rules whose creation you could not trace, contest or help to form.

Instead of asking developers to create completed content, why not create a transparent RFP (request for proposal) process and get the input of the community to decide on the the path we should take (what developer/informal group of developers/company should be chosen to complete the task).

This is called a Tender and the only difference between the current system is name. Asking the community to decide who to choose to complte the task defeats the purpose, we are looking for someone who can complete the task. How do we decide without seeing their version of it? Keep in mind please that III is not the only entity that can post a bounty.

Submitter's will include relevant samples of previous work, resume/references, a rough mock up of their design (if applicable), cost to complete the work, and some type of cover letter.

lol, this is the crypto industry where we like our privacy. There are only two people on this forum that know who i really am, one of them being bytemaster, i'd like to keep it that way thanks. Trying to force disclosure like that will fall flat on it's face.

This should:

Eliminate the need to set an arbitrary price (the market will decide)
Open the process to top talent
Give whoever is chosen the compensation they need to stay focused on the task at hand
Allow for community input throughout the entire process

Lol, the thing that makes bounties get completed quickly is that number you want to remove. And trust me, i know a few of the guys here from other forums, you'd need college proffesors to beat some of them.

As a bounty hunter all i need to know is how much i am getting paid to produce a good quality product that will meet the posters requirement and when i should be done. If i have queries, i always ask, and along the way i open up my development process to the community for input kind of like what we are doing now.

The RFP should define the project due date and incremental goals (each goal paired with a percentage of the total project cost) that must be shared with the community on a weekly basis for a comment and suggestion period (no longer than 24-48 hrs).  At the result of that period, the developer will make any necessary changes and submit that portion for final Approval.  Barring any major objections (or a veto by bytemaster), that portion is Approved, the developer is paid the portion of project cost associated with that goal and then moves on to the next task.  The development should be as open source as possible (easy with coding/writing, harder with graphic design) to allow for comments along the way to limit surprises during the more formal comment/suggestion period.

As a person who is in full support of DACs and their uniqueness, also as a bounty hunter i reject the idea of "comment and suggestion periods" set in time, I want my customer to have full access to my work and be free to comment at anytime, i even tend to give them editing rights on my works which i post publicly. And piece-meal payments as good as that sounds would complicate the process, which we are hoping to be simple and straight forward.

Worst case, if the selected developer isn't producing, it will be obvious from the start and the RFP process can be re-opened to more proposals with a minimum loss of capital.  Best case, the developer produces great consistent content and the community is aware of the status of each project at all times.  Because the developer is being paid in PTS, it is in their best interest to stay on task and on time while producing quality work.

Again please read through the document and some of the Bounties and check their processes, the very mechanism of bounties does all that without need for supervision.

The biggest group of stakeholders are holders of protoshares and angelshares and with this process Invictus can empower those stakeholders to help make the decisions that will affect their wealth and ROI as an investor.

Software, graphics and other bounties emanate from ideas and suggestions that are already floating about in the community, some of the more III ones come from things they need to meet certain objectives. You'll find that quite a few of the ones on this subforum were requested by the community. Perhaps we can move this  conversation to the bounty discussion thread.. as you are also suggesting we scrap bounties.


As the person who is wrote this document and a bounty hunter, i have tried my best to stick to the rules i've written as a means of encouraging their adoption and thus far they seem to be working. Should there be need to chnage the system then that is another thing altogether but this document is about the rules and procedures of the bounty syatem, not the development of a new system. The reasons the bounty system is used not only by the crypto industry but by most huge tech and security firms are numerous, apart from creativity and speed they create a hiring pool for easier pickings later, which is worth more than you can imagine.

A lot of the people asking to change the system are not bounty hunters themselves, most are not even developers. Using the mind and working on these projects is time consuming and requires a certain temperament, otherwise nothing gets done. Before you start judging how much their paid, walk in their shoes a bit. 

[wasthatawolf]

The entire bounty system in its current form doesn't seem to be producing top quality products with any type of efficiency (i.e. the Invictus website).  I think everyone has great intentions and there is a lot of talent in the community but the process for disseminating, organizing and focusing that talent for complex tasks is so loose that we end up with a lot of accuracy and no precision.

I think betax nailed it here,

I have lots of spare money (pts), give me something quick, I don't know how to price it but I will give you what I consider what is fair considering the risk you take

These large bounties can be a huge risk to those that create submissions because in the end only one will be chosen and the others will not be compensated for their work.  At worst, it weeds out the best talent because they can't risk putting in the time to produce a final product that may not result in any compensation, and at best it results in a lack of focus because submitters must spend more time and focus on other projects that provide compensation necessary for their cost of living in the event their submission isn't chosen.   What we end up getting is a few average and above average submissions which are all accurate in that they meet the basic requirements of the project.  Also, in the end, the process is centralized.  The final decision is just a judgement call by bytemaster with no real measurable metrics (as most submissions meet the basic requirements).  Obviously, it's his company and he has the ultimate decision, but, why not create a new process that facilitates that decision to the point that by the end of the process its obvious to everyone what the final product will be.

Here's my solution:

Instead of asking developers to create completed content, why not create a transparent RFP (request for proposal) process and get the input of the community to decide on the the path we should take (what developer/informal group of developers/company should be chosen to complete the task).  Protoshare/Angelshare holders can vote for a proposal proportionally based on the number of shares they hold (not sure if this is possible...).  It is in the best interest of Protoshare/Angelshare holders to decide on the best value product that will grow the community and increase the value of their holdings.

Submitter's will include relevant samples of previous work, resume/references, a rough mock up of their design (if applicable), cost to complete the work, and some type of cover letter.

This should:

• Eliminate the need to set an arbitrary price (the market will decide)
• Open the process to top talent
• Give whoever is chosen the compensation they need to stay focused on the task at hand
• Allow for community input throughout the entire process

The RFP should define the project due date and incremental goals (each goal paired with a percentage of the total project cost) that must be shared with the community on a weekly basis for a comment and suggestion period (no longer than 24-48 hrs).  At the result of that period, the developer will make any necessary changes and submit that portion for final Approval.  Barring any major objections (or a veto by bytemaster), that portion is Approved, the developer is paid the portion of project cost associated with that goal and then moves on to the next task.  The development should be as open source as possible (easy with coding/writing, harder with graphic design) to allow for comments along the way to limit surprises during the more formal comment/suggestion period. 

Worst case, if the selected developer isn't producing, it will be obvious from the start and the RFP process can be re-opened to more proposals with a minimum loss of capital.  Best case, the developer produces great consistent content and the community is aware of the status of each project at all times.  Because the developer is being paid in PTS, it is in their best interest to stay on task and on time while producing quality work.

The biggest group of stakeholders are holders of protoshares and angelshares and with this process Invictus can empower those stakeholders to help make the decisions that will affect their wealth and ROI as an investor.

 

[barwizi]

If you have read my last response, please make let me know if i should move forward and begin redefining how it all works and the processes.

[barwizi]

No doubt that is part of the solution.  In this case I'm performing that function for one small bounty while trying to do my day job.  So I'm sure that our new bounty manger will have about the same amount of time to spend on each of all the rest of the bounties.  Since that will always be the limitation to how fast we can grow this industry while staying decentralized, we need to try our best with this bounty to come up with rules and procedures to help the poor guy handle more bounties per second without causing undue friction among the various stakeholders.

Those are the kind of innovations we hope to see when this document reaches its full potential.

Thanks for everyone's efforts in getting us to the point where we can have this conversation.   

While we talk of the bounties being like "customer walks into a shop", let that not obscure the fact that most of the work done here is be-spoke, ie these are custom jobs done to fit a purpose. The rules differ from walking into walmart.

The rules and procedures document does just that. Quality control as you stated in the aerospace industry involves different teams for different chains of command. However the decentralized crypto-equity industry is entirely different. As far as III works, quality assessment is and should remain an internal issue, this is stuff you guys will put your name on and I personally would only use it if you guys are the ones who have gone through it and given it the approval stamp. It is part of your product and as such needs your input at every turn. While time consuming it is part of what makes people trust you and your work. Trying to change this may have the adverse effect on confidence. Remember, III is leading the drive to define this industry, it's a pain (lol) but that is how huge industries were built, by hand.

Scalability of Bounties offered by III, that is easily answered by moving from either one part time hire to two, or a full time employee like larger institutions do. Although given default trust in the document that is an internal issues, it has to do with how you guys will offer the bounties, manage them and the quality produced, nothing to do with how bounties are done. Attempting to integrate all that in the document, means i am now writing Internal Guidelines,  i'd have to set up rules for III and then for third parties so much so that the document could be a hundred pages long as I try to anticipate every situation, and they are countless since there are things we are yet to encounter. Individuals can post bounties, so can other DACs even an outsider can require something completely unrelated to III or DACs done and post it there, the rules I've written are applicable in all cases and account for that.

If i structure the rules in a way based on III, what if you guys run broke but third party DACs are going strong? The document is Bounty centred, the internal operations of III and other similar forthcoming companies is not discussed or even related to the document.

In essence i am saying the document should only state how bounties are carried out and the rules that apply. Making a complicated system that is based on how III's internal workings on quality assessment takes out the balances and checks between customer and producer will have disastrous effects on the trust between them. This is becoming less be-spoke and more like another wing of your company which it is not, because in that case you are trying to redefine Bounties. This will badly affect how bounties are executed, even I a frequenter of this subforum will have to rethink my position. Think of how large companies handle bounties, they simply tell people what they want and let them run wild. The company itself will test the entries when they are submitted.

bytemaster insisted that bounties should not constitute a contract and has helped me structure the document in a way that fosters trust and encourages teamwork and quality products. The system is based on the bounty system that has always been existent but simply put on paper lol (screen) modified to suit our required end result. Third parties have been instructed to use escrow since III has default trust and that is how it should be since the few cases of problems with bounties emanate from payments.

This document is not meant to be the be  all and is all forever, I think it is meant to lay out the rules and procedures. The issues you are bringing to light seem more to do with how posters will individually assess the work they requested and less with how the work is done. Perhaps we can move this to the Bounties discussion thread.

But should you insist, i will add all that to the document though it will change the essence of the document and we'll have to start redefining Bounties on those terms.

[Stan]

The document I have been reviewing seems like a good start on a spec for what we were hoping for.

The rules are there but they don't seem to be self-enforcing.

The art of game theory is to engineer the right outcome by constructing the incentives in such a way that people do the right thing naturally in their own self interest without requiring an outside party to have to enforce the rules.  Enforcement by an outside force always leads to conflict and hard feelings - what we are hoping to avoid.

A simple example:  The Quality Assurance function (missing from the current process) might be set up such that the QA person gets a share of the developer's share proportional to the number of bugs found.  This incentivizes the developer not to have bugs when the product is submitted to QA.  And the buyer knows that the product is probably bug free if a properly incentivized QA person couldn't collect a big payout.  But the process still has to reward the QA person for trying, lest they be discouraged by receiving perfect code too often.  The best QA person might be a competitor who has plenty of motivation for finding fault.  If your competitor can't find a fault, you've got a really great product.

Game theory logic like this is largely missing from the product so far.  I like the fact that the document hasn't become bloated, but it seems to put the burden on the customer to determine if all the rules have been followed or not.

If we are to maximize the number of bounties available to the community, we can't be refereeing all the internal steps of the process.   

For example:  "Submissions with bugs may be penalized and may result in complete disqualification." How does the customer know that there are no bugs and are we expecting the customer to do the penalizing instead of the natural processes built into the system?  If we have to do that ourselves, we won't have enough time available to sponsor many bounties!

In short - the current document does not define a process that is scalable to the number of bounties we hope to offer.

Innovations are needed here.  How does this document put in place a system that delivers a quality product that an already overloaded customer can buy with confidence?

I see your point but i think the idea of middlemen will hamper the trust system that is used with Bounties, especially with regard to coding. If i deliver a product and the QA guy fails to see a bug, but it appears later on when the program is in use, I may say that such a bug was not there when I gave it to you and it was introduced later. Whereas the trust system encourages cooperation, see the only Bounty listed as [Paid], me toast and Freetrade did that and were paid. Even before Dan offered to pay, we were still addressing any issues on any board that are related to it.

Bounties shouldn't need enforcement, simply, you ask for something and I work to produce it. I hand in an entry, you check it out and it if does the required task well then I get paid, if there are issues, you point them out and I go back to work on them, kind of like what we are doing now.

You already mention that enforcement by outsiders leads to hard feelings, isnt a middleman an outsider? Also the inclusion of a middleman open up the possibility of corruption. There are sometimes huge funds involved and that could cause collusion.

I was  under the impression that this document was to encourage team work and quality, but if competitors are at each others neck trying to find fault in the other's work, we'll never get anything done.

However, if this is the new direction you wish for i will make it so.

My intention was to show an example of engineering a process so everyone working in their own self-interest wind up naturally producing a desired result.  This doesn't necessarily mean that the example is the right way to do it.

But I would like to see how we can get to bytemaster's model of having people produce a product that a customer can just buy.  Apple doesn't expect its customers to participate in the development and QA (although it may use focus groups to refine requirements which is comparable to what we are doing right now.)  If they can produce insanely great products for customers that didn't even know they wanted an iPod, how can we replicate that process?

Again, you cite success when bytemaster is deeply involved but that doesn't scale because there is not enough of bytemaster. 

How do we define a process that demands less of his time so that we can move the industry forward faster?

(Obviously we could grow Invictus with a whole staff that does that, but that path leads to centralization and the Dark Side.)

Lol, that is true. We once spoke about that with bytemaster, this was his response

I have hired someone (cannot announce until he notifies his existing employer) who's job it will be to turn my high-level needs into detailed bounties and manage it to completion.  He will be paid a commission on whether or not a valid submission is made for the bounty (I will be the judge).  This should motivate him to set up the bounty rules, spec, etc, in a way that makes it most likely to get a result. 

I think that it will require someone working with me on a partial payroll basis to pull this off.   That said, I could imagine hiring a few such people who will be bounty managers responsible for delivering the final product.    Under the current system, these would be the team leaders who then allocate sub bounties and keep a cut for themselves.

The overall goal as he put it once before was that you guys were looking for talent, which would later be used on a regular basis as part time work force and that bounties bring people out of the wood work while completing tasks quickly.

Quality control should never cause problem with bounty execution, i think he had the right idea hiring someone to handle it even part time. As you have CEO, COO and CFO, you should create a position CDO , chief development officer who handles those issues. It is far more efficient and creates a viable environment. The CDO, frequents the forum and tests current products, noting all complaints by users and noting all suggestions, these are then used to create the bounties.

Also if you guy need specific things done you tell him and he breaks the tasks up and manages the development via bounties. The very idea of having a bounties dedicated person will improve efficiency, communication and quality all at once.

Also the bounty manager could assist third party bounties since it's only a matter of time before they start appearing.

No doubt that is part of the solution.  In this case I'm performing that function for one small bounty while trying to do my day job.  So I'm sure that our new bounty manger will have about the same amount of time to spend on each of all the rest of the bounties.  Since that will always be the limitation to how fast we can grow this industry while staying decentralized, we need to try our best with this bounty to come up with rules and procedures to help the poor guy handle more bounties per second without causing undue friction among the various stakeholders.

Those are the kind of innovations we hope to see when this document reaches its full potential.

Thanks for everyone's efforts in getting us to the point where we can have this conversation.   

[Stan]

lets wrap things up.

Here's a good test of your product:

How does it facilitate "wrapping things up"?

Should you produce a checklist of all of the customer's published desirements and how they have been satisfied or do you expect the customer to do that function (and, if so, why?)

Or do you have a process where someone else is called in to do that QA function on your product?

Please apply your document to your own bounty and see if it works.   

During the Construction process, the customer and i discuss what is required, in this case a set of rules for bounties, i got a feel for what was required and wrote in that spirit. As i handed in draft, the customer would point out what they felt was wrong and also add or subtract some parts until it was complete. There is nowhere a QA person can fit in because the quality is produced by the efforts of the customer and producer through communication. By wrapping things up in this case was in your hands as it had been quite a while since i had got feedback from the customer. If you look at the document, you'll note it's emphasis on communication, there is no need for a checklist because the customers needs published or not are worked on with their input, the very idea of checklists creates room for shoddy work. If you look through the revision history, you'll see that not only was i using the customer's ideas, but I integrated my own, the Ethics portion for example.

The moment you encourage outside QA especially by competitors you open up a can of worms.
1) Competitor may just keep pointing out issues that have nothing to do with the bounty, but because it is an issue the customer will want it fixed. for example, i have completed this bounty https://bitsharestalk.org/index.php?topic=1986.0 (I am waiting on you guys on that one as well). We have all heard about the issue on Mac with the client, a competitor could point that out and affect the outcome. Is it part of the Bounty?, no! The customer would then want that fixed too still.

2) I wrote the SCSL, if you brought in QA person and they communicated with me, what is there to stop us from agrreing to share the funds if we tell you it's perfect? The customer must be the one to assess the product, and if they require assiatance in testing they can ask for outside help, that is not in anyway partaking in the bounty.

Those are good points.  I think you have a good set of rules but I'm not sure I understand the corresponding procedures that will ensure they are followed other than the default of consuming lots of customer time.

I have worked with and for most of the major aerospace companies on our continent and we never submitted a proposal or a product without making it as easy as possible for our customers to check whether we have met all our requirements. It was part of the job.

We had our own QA teams that reported up a different independent management chains.  I hated them, but that's how the aerospace industry engineered the process.  I'm sure the decentralized crypto-equity industry needs completely different processes.  What are they?

Trust and close interaction works when the customer has lots time to dedicate to one project.  But it doesn't scale very well because that much interaction cannot be applied to every project.  So we are seeking ideas on how to make the process more decentralized and scalable. 

[barwizi]

The document I have been reviewing seems like a good start on a spec for what we were hoping for.

The rules are there but they don't seem to be self-enforcing.

The art of game theory is to engineer the right outcome by constructing the incentives in such a way that people do the right thing naturally in their own self interest without requiring an outside party to have to enforce the rules.  Enforcement by an outside force always leads to conflict and hard feelings - what we are hoping to avoid.

A simple example:  The Quality Assurance function (missing from the current process) might be set up such that the QA person gets a share of the developer's share proportional to the number of bugs found.  This incentivizes the developer not to have bugs when the product is submitted to QA.  And the buyer knows that the product is probably bug free if a properly incentivized QA person couldn't collect a big payout.  But the process still has to reward the QA person for trying, lest they be discouraged by receiving perfect code too often.  The best QA person might be a competitor who has plenty of motivation for finding fault.  If your competitor can't find a fault, you've got a really great product.

Game theory logic like this is largely missing from the product so far.  I like the fact that the document hasn't become bloated, but it seems to put the burden on the customer to determine if all the rules have been followed or not.

If we are to maximize the number of bounties available to the community, we can't be refereeing all the internal steps of the process.   

For example:  "Submissions with bugs may be penalized and may result in complete disqualification." How does the customer know that there are no bugs and are we expecting the customer to do the penalizing instead of the natural processes built into the system?  If we have to do that ourselves, we won't have enough time available to sponsor many bounties!

In short - the current document does not define a process that is scalable to the number of bounties we hope to offer.

Innovations are needed here.  How does this document put in place a system that delivers a quality product that an already overloaded customer can buy with confidence?

I see your point but i think the idea of middlemen will hamper the trust system that is used with Bounties, especially with regard to coding. If i deliver a product and the QA guy fails to see a bug, but it appears later on when the program is in use, I may say that such a bug was not there when I gave it to you and it was introduced later. Whereas the trust system encourages cooperation, see the only Bounty listed as [Paid], me toast and Freetrade did that and were paid. Even before Dan offered to pay, we were still addressing any issues on any board that are related to it.

Bounties shouldn't need enforcement, simply, you ask for something and I work to produce it. I hand in an entry, you check it out and it if does the required task well then I get paid, if there are issues, you point them out and I go back to work on them, kind of like what we are doing now.

You already mention that enforcement by outsiders leads to hard feelings, isnt a middleman an outsider? Also the inclusion of a middleman open up the possibility of corruption. There are sometimes huge funds involved and that could cause collusion.

I was  under the impression that this document was to encourage team work and quality, but if competitors are at each others neck trying to find fault in the other's work, we'll never get anything done.

However, if this is the new direction you wish for i will make it so.

My intention was to show an example of engineering a process so everyone working in their own self-interest wind up naturally producing a desired result.  This doesn't necessarily mean that the example is the right way to do it.

But I would like to see how we can get to bytemaster's model of having people produce a product that a customer can just buy.  Apple doesn't expect its customers to participate in the development and QA (although it may use focus groups to refine requirements which is comparable to what we are doing right now.)  If they can produce insanely great products for customers that didn't even know they wanted an iPod, how can we replicate that process?

Again, you cite success when bytemaster is deeply involved but that doesn't scale because there is not enough of bytemaster. 

How do we define a process that demands less of his time so that we can move the industry forward faster?

(Obviously we could grow Invictus with a whole staff that does that, but that path leads to centralization and the Dark Side.)

Lol, that is true. We once spoke about that with bytemaster, this was his response

I have hired someone (cannot announce until he notifies his existing employer) who's job it will be to turn my high-level needs into detailed bounties and manage it to completion.  He will be paid a commission on whether or not a valid submission is made for the bounty (I will be the judge).  This should motivate him to set up the bounty rules, spec, etc, in a way that makes it most likely to get a result. 

I think that it will require someone working with me on a partial payroll basis to pull this off.   That said, I could imagine hiring a few such people who will be bounty managers responsible for delivering the final product.    Under the current system, these would be the team leaders who then allocate sub bounties and keep a cut for themselves.

The overall goal as he put it once before was that you guys were looking for talent, which would later be used on a regular basis as part time work force and that bounties bring people out of the wood work while completing tasks quickly.

Quality control should never cause problem with bounty execution, i think he had the right idea hiring someone to handle it even part time. As you have CEO, COO and CFO, you should create a position CDO , chief development officer who handles those issues. It is far more efficient and creates a viable environment. The CDO, frequents the forum and tests current products, noting all complaints by users and noting all suggestions, these are then used to create the bounties.

Also if you guy need specific things done you tell him and he breaks the tasks up and manages the development via bounties. The very idea of having a bounties dedicated person will improve efficiency, communication and quality all at once.

Also the bounty manager could assist third party bounties since it's only a matter of time before they start appearing.

[Stan]

The document I have been reviewing seems like a good start on a spec for what we were hoping for.

The rules are there but they don't seem to be self-enforcing.

The art of game theory is to engineer the right outcome by constructing the incentives in such a way that people do the right thing naturally in their own self interest without requiring an outside party to have to enforce the rules.  Enforcement by an outside force always leads to conflict and hard feelings - what we are hoping to avoid.

A simple example:  The Quality Assurance function (missing from the current process) might be set up such that the QA person gets a share of the developer's share proportional to the number of bugs found.  This incentivizes the developer not to have bugs when the product is submitted to QA.  And the buyer knows that the product is probably bug free if a properly incentivized QA person couldn't collect a big payout.  But the process still has to reward the QA person for trying, lest they be discouraged by receiving perfect code too often.  The best QA person might be a competitor who has plenty of motivation for finding fault.  If your competitor can't find a fault, you've got a really great product.

Game theory logic like this is largely missing from the product so far.  I like the fact that the document hasn't become bloated, but it seems to put the burden on the customer to determine if all the rules have been followed or not.

If we are to maximize the number of bounties available to the community, we can't be refereeing all the internal steps of the process.   

For example:  "Submissions with bugs may be penalized and may result in complete disqualification." How does the customer know that there are no bugs and are we expecting the customer to do the penalizing instead of the natural processes built into the system?  If we have to do that ourselves, we won't have enough time available to sponsor many bounties!

In short - the current document does not define a process that is scalable to the number of bounties we hope to offer.

Innovations are needed here.  How does this document put in place a system that delivers a quality product that an already overloaded customer can buy with confidence?

I see your point but i think the idea of middlemen will hamper the trust system that is used with Bounties, especially with regard to coding. If i deliver a product and the QA guy fails to see a bug, but it appears later on when the program is in use, I may say that such a bug was not there when I gave it to you and it was introduced later. Whereas the trust system encourages cooperation, see the only Bounty listed as [Paid], me toast and Freetrade did that and were paid. Even before Dan offered to pay, we were still addressing any issues on any board that are related to it.

Bounties shouldn't need enforcement, simply, you ask for something and I work to produce it. I hand in an entry, you check it out and it if does the required task well then I get paid, if there are issues, you point them out and I go back to work on them, kind of like what we are doing now.

You already mention that enforcement by outsiders leads to hard feelings, isnt a middleman an outsider? Also the inclusion of a middleman open up the possibility of corruption. There are sometimes huge funds involved and that could cause collusion.

I was  under the impression that this document was to encourage team work and quality, but if competitors are at each others neck trying to find fault in the other's work, we'll never get anything done.

However, if this is the new direction you wish for i will make it so.

My intention was to show an example of engineering a process so everyone working in their own self-interest wind up naturally producing a desired result.  This doesn't necessarily mean that the example is the right way to do it.

But I would like to see how we can get to bytemaster's model of having people produce a product that a customer can just buy.  Apple doesn't expect its customers to participate in the development and QA (although it may use focus groups to refine requirements which is comparable to what we are doing right now.)  If they can produce insanely great products for customers that didn't even know they wanted an iPod, how can we replicate that process?

Again, you cite success when bytemaster is deeply involved but that doesn't scale because there is not enough of bytemaster. 

How do we define a process that demands less of his time so that we can move the industry forward faster?

(Obviously we could grow Invictus with a whole staff that does that, but that path leads to centralization and the Dark Side.)

[barwizi]

lets wrap things up.

Here's a good test of your product:

How does it facilitate "wrapping things up"?

Should you produce a checklist of all of the customer's published desirements and how they have been satisfied or do you expect the customer to do that function (and, if so, why?)

Or do you have a process where someone else is called in to do that QA function on your product?

Please apply your document to your own bounty and see if it works.   

During the Construction process, the customer and i discuss what is required, in this case a set of rules for bounties, i got a feel for what was required and wrote in that spirit. As i handed in draft, the customer would point out what they felt was wrong and also add or subract some parts until it was complete. There is nowhere a QA person can fit in because the quality is produced by the efforts of the customer and producer through communication. By wrapping things up in this case was in your hands as it had been quite a while since i had got feedback from the customer. If you look at the document, you'll note it's emphasis on communication, there is no need for a checklist because the customers needs published or not are worked on with their input, the very idea of checklists creates room for shoddy work. If you look through the revision history, you'll see that not only was i using the customer's ideas, but I integrated my own, the Ethics portion for example.

The moment you encourage outside QA especially by competitors you open up a can of worms.
1) Competitor may just keep pointing out issues that have nothing to do with the bounty, but because it is an issue the customer will want it fixed. for example, i have completed this bounty https://bitsharestalk.org/index.php?topic=1986.0 (I am waiting on you guys on that one as well). We have all heard about the issue on Mac with the client, a competitor could point that out and affect the outcome. Is it part of the Bounty?, no! The customer would then want that fixed too still.

2) I wrote the SCSL, if you brought in QA person and they communicated with me, what is there to stop us from agrreing to share the funds if we tell you it's perfect? The customer must be the one to assess the product, and if they require assiatance in testing they can ask for outside help, that is not in anyway partaking in the bounty. 

[Stan]

There is lots of Risk here both for the delivery person / company and for yourself and myself as an small investor. The bounties I have seen differ significantly in price (a new website, no idea what I want), json ticker and infographics, there is no measurement of work / plan for each actual bounty. Mainly I have lots of spare money (pts), give me something quick, I don't know how to price it but I will give you what I consider what is fair considering the risk you take.

I believe you need a clear and granular road map, and you should focus on very small bounties, each bounty should be rewarded for the completed work of week maximum, ideally a couple of days to reduce the risk for both parties.

You should borrow from agile methodologies, and match each bounty to a task in an iteration. For example building a website has many tasks and iterations, this should drive both collaboration between the people delivering the bounties plus also reduce the risk of knowledge management and key dependencies.

The owner of a particular work stream should publish the work required 2 weeks in advance to get the required people involved, ideally if you manage to get a team of 10 (ie developers) the work will be delivered by the same team with what I assume with a constant turnover of 2 people.

To cut the story short, small tasks, quick delivery, self organising teams, clear road map and most important good requirements for each iteration. Most important an iteration can be just a "mock up" of something to get good ideas of a requirement.

Hopefully it gives you some ideas or most probably I am just preaching to the choir.

Actually, this is a great example of the depth of thinking we are looking for.

But, of course, task decomposition and assignment is its own "small task" which generates other small tasks.  As we have said, there can be bounties for generating bounties.  This bounty is for defining the full spectrum of possibilities in a way that maximizes our ability to grow an industry by employing the donations and labor of this community.

Maybe we have to take the decomposition task in house, but our preference is to maximize the opportunities for all skills (including project managers and entrepreneurs) to take big problems and turn them into smaller ones.

In general, we are likely to spit out bounties of all sizes.  The process ought to take any size task and decompose it to the point that what you suggest can take place.

If "digesters" and "organizers" don't emerge, we'll eventually cancel the big bounties and do the work ourselves.  But we would like to offer them to the community first so we can grow teams into departments into subcontractors into competitors over time.

 

[barwizi]

The document I have been reviewing seems like a good start on a spec for what we were hoping for.

The rules are there but they don't seem to be self-enforcing.

The art of game theory is to engineer the right outcome by constructing the incentives in such a way that people do the right thing naturally in their own self interest without requiring an outside party to have to enforce the rules.  Enforcement by an outside force always leads to conflict and hard feelings - what we are hoping to avoid.

A simple example:  The Quality Assurance function (missing from the current process) might be set up such that the QA person gets a share of the developer's share proportional to the number of bugs found.  This incentivizes the developer not to have bugs when the product is submitted to QA.  And the buyer knows that the product is probably bug free if a properly incentivized QA person couldn't collect a big payout.  But the process still has to reward the QA person for trying, lest they be discouraged by receiving perfect code too often.  The best QA person might be a competitor who has plenty of motivation for finding fault.  If your competitor can't find a fault, you've got a really great product.

Game theory logic like this is largely missing from the product so far.  I like the fact that the document hasn't become bloated, but it seems to put the burden on the customer to determine if all the rules have been followed or not.

If we are to maximize the number of bounties available to the community, we can't be refereeing all the internal steps of the process.   

For example:  "Submissions with bugs may be penalized and may result in complete disqualification." How does the customer know that there are no bugs and are we expecting the customer to do the penalizing instead of the natural processes built into the system?  If we have to do that ourselves, we won't have enough time available to sponsor many bounties!

In short - the current document does not define a process that is scalable to the number of bounties we hope to offer.

Innovations are needed here.  How does this document put in place a system that delivers a quality product that an already overloaded customer can buy with confidence?

I see your point but i think the idea of middlemen will hamper the trust system that is used with Bounties, especially with regard to coding. If i deliver a product and the QA guy fails to see a bug, but it appears later on when the program is in use, I may say that such a bug was not there when I gave it to you and it was introduced later. Whereas the trust system encourages cooperation, see the only Bounty listed as [Paid], me toast and Freetrade did that and were paid. Even before Dan offered to pay, we were still addressing any issues on any board that are related to it.

Bounties shouldn't need enforcement, simply, you ask for something and I work to produce it. I hand in an entry, you check it out and it if does the required task well then I get paid, if there are issues, you point them out and I go back to work on them, kind of like what we are doing now.

You already mention that enforcement by outsiders leads to hard feelings, isnt a middleman an outsider? Also the inclusion of a middleman open up the possibility of corruption. There are sometimes huge funds involved and that could cause collusion.

I was  under the impression that this document was to encourage team work and quality, but if competitors are at each others neck trying to find fault in the other's work, we'll never get anything done.

However, if this is the new direction you wish for i will make it so.

[Stan]

lets wrap things up.

Here's a good test of your product:

How does it facilitate "wrapping things up"?

Should you produce a checklist of all of the customer's published desirements and how they have been satisfied or do you expect the customer to do that function (and, if so, why?)

Or do you have a process where someone else is called in to do that QA function on your product?

Please apply your document to your own bounty and see if it works.   

[betax]

There is lots of Risk here both for the delivery person / company and for yourself and myself as an small investor. The bounties I have seen differ significantly in price (a new website, no idea what I want), json ticker and infographics, there is no measurement of work / plan for each actual bounty. Mainly I have lots of spare money (pts), give me something quick, I don't know how to price it but I will give you what I consider what is fair considering the risk you take.

I believe you need a clear and granular road map, and you should focus on very small bounties, each bounty should be rewarded for the completed work of week maximum, ideally a couple of days to reduce the risk for both parties.

You should borrow from agile methodologies, and match each bounty to a task in an iteration. For example building a website has many tasks and iterations, this should drive both collaboration between the people delivering the bounties plus also reduce the risk of knowledge management and key dependencies.

The owner of a particular work stream should publish the work required 2 weeks in advance to get the required people involved, ideally if you manage to get a team of 10 (ie developers) the work will be delivered by the same team with what I assume with a constant turnover of 2 people.

To cut the story short, small tasks, quick delivery, self organising teams, clear road map and most important good requirements for each iteration. Most important an iteration can be just a "mock up" of something to get good ideas of a requirement.

Hopefully it gives you some ideas or most probably I am just preaching to the choir.

[Stan]

OK, good, I've been reading the right one.

Thanks!