[Koha-devel] Signing-off a patch for a customer

[Jared Camins-Esakov]

Marc,

But, if the patch we speak about, has been tested at the library, that
> makes it already two involved parties, I would say.
>

Neither of the parties is disinterested. I think having the sign-off by the
library is probably okay for this type of patch where there are only a
certain number of parties who can test the feature, but in that case, Chris
and Katrin suggested that QA should be done by someone other than party 1.
For the patches where the only person who could do QA works for party 1
(not that I can imagine any situation in which case this would be true), a
sign-off from someone without a financial interest in the patch should be
required.

Speaking as a Koha service provider, I am strongly in support of the
requirement that at least one step in the approval process should be done
by a disinterested party. It would certainly make developments commissioned
by customers easier if I could mark the tested patch "signed off" on the
basis of their testing, but I (and every other developer) rely on outside
feedback for identifying the edge cases and bugs that just don't come up
for our particular customers.

If there isn't enough interest in a certain patch that's been "sitting
around" too long, perhaps the solution is for the sponsor to place a
non-monetary "bounty" on the patch. For example, "I will send half a batch
of fudge to the first two people who provide useful feedback on the patch."
We don't want rubber stamping. Often, I think, the reason a patch sits
around too long is that no one else understands what the patch does. This
is certainly the case for some of the patches that I've looked at. I can't
figure out exactly what the patch does, so I don't want to *fail* it, but
at the same time, I can't really sign off on it because I don't know if
it's working.

Regards,
Jared

-- 
Jared Camins-Esakov
Bibliographer, C & P Bibliography Services, LLC
(phone) +1 (917) 727-3445
(e-mail) jcamins at cpbibliography.com
(web) http://www.cpbibliography.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120528/3d8a89f2/attachment.htm>