Ok, so should i go ahead and put quality assesment as part of the document or do you agree that it should be a customer who decides on quality? I've outlined and elaborated on my arguments against it, now i just need confirmation from you guys that i should do it or not?
The customer ultimately decides on quality, but that doesn't eliminate the need for the developer to
prove to the customer that he/she has met all the stated requirements, including quality control. How this is done may be up to each bounty hunter, but it is still their duty and
it's in their best interest to do so, lest the customer miss recognizing how good the product really is.
We never, ever wanted to leave it to a busy customer to connect the dots on the work we had done on an aerospace project of any size. That's a good way to lose a follow-on contract (or a bounty) you deserved to win.
If you are tasked to build a missile you must prove it can hit its target. If you are tasked to build a race car, you must document its speed and reliability by showing test results and analyses. If you are writing software you must show evidence of passing unit tests and perhaps successful third-party integration.
If you are tasked to write a document you must show that the document meets the stated need.
If you are tasked to write a tutorial, have you demonstrated that several newbies can follow it successfully?
How to prove you have earned the bounty is up to the offeror.
For this bounty, it might be showing evidence that you have obtained buy-in from other bounty hunters. They are your ultimate customer and your product is useless if they don't understand, support, and use it. I would expect that for 200 PTS you would have posted or PMed your best effort onto many of the other bounty threads and asked for their feedback - perhaps offering a small share in your bounty if they help you win in some significant way or perhaps reminding them that they should speak now or forever live with what you have produced. Rave reviews or quiet adoption could be submitted as evidence that you have met their needs. Howls of protest would send you back to the drawing board and ultimately yield a product that will be accepted.
Quiet adoption must be
made observable somehow. If the document calls for certain processes to be implemented or reports to be submitted or whatever, and we see that happen, that would be evidence of community buy-in.
So would showing how you have incorporated their feedback to improve the process.
Can you convince the forum that your approach meets the stated need?
Can you generalize what you do to win your own bounty into acceptable rules or suggestions that all bounty hunters can use?
Right now the document contains lots of good advice which might be read and immediately forgotten. How do we turn it into something like a series of verifiable gates that everyone must pass to collect their bounties?
How do we make it
influential and
effective?
I will begin doing that job for you tonight, putting everything bytemaster said into a spreadsheet with notes about how well I believe each stated desirement has been achieved. But I don't want to have to do this for every bounty hunter, or the turn-around time will become unacceptable and we'll all walk away disappointed.
Perhaps you can critique what I do and generalize it to something we should expect from every offeror when they come to claim their bounties.