Hi all, thanks Jared! That's what I meant.
To bring this discussion back to Paul's initial question: I think we should encourage libraries to get involved in testing and participating in the community. The sandboxes are a tool to lower the barrier for libraries, which is great. I would like to see the library itself note the sign-off in bugzilla. It would be great if there were some notes about the testing (what, how, which configuration), but a short note would be a good start. It would be great if the credit could go to the library. We have talked about adding the 'sign offers' to the release notes as an additional encouragement for testers. I would love to see the names of lots of libraries showing up there. The other thing that would be a condition for me is "third party" (as Jared explained it) QA for those patches. Hope that makes sense, Katrin -----Ursprüngliche Nachricht----- Von: [email protected] im Auftrag von Jared Camins-Esakov Gesendet: Mo 28.05.2012 17:40 An: Marc Balmer Cc: [email protected] Betreff: Re: [Koha-devel] Signing-off a patch for a customer 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) [email protected] (web) http://www.cpbibliography.com/
_______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
