Hey Robin, On 11.11.10 13.27, ext Robin Burchell wrote: > As a project, if you want to encourage contribution and collaboration, > then you need to minimise the number of hurdles and barriers that people > face when getting changes integrated. Technical barriers should be the > only clearly visible ones when trying to integrate a contribution. Legal > or political barriers are a good way to ensure that you won't have > repeat contributors sticking around, and should be minimised for that > reason.
Sure, the goal would always be to minimize barriers. That does not necessarily mean that you won't have both technical and legal barriers that you can't solve or work around. > For instance, Something I'm working on right now, Qt on Skia, is too big > a task for me to handle personally (as I'm totally new to graphics), so > I"m collaborating with a close friend of mine who has significantly more > experience in the area. > > Thanks to this rule, I'm having to be the one doing the actual commits, > thus getting my name on their work, for no good reason. If both of us > weren't a so passionate about Qt, we might just not bother. I agree, the current "one-author"-barrier is bad. We can work around the technical part by having other ways to ensure that each contributor has signed a contribution agreement, but we can't solve/work around that fact that we do need a contribution agreement. > > But, if you apply that principle to the integrators as well, you might > > want to "summon" a bot for doing static analysis, or a full build, or a > > build on a slow platform, so that you (as a contributor), can find and > > fix any errors _before_ the patch gets through to a > > maintainer/integrator, possibly wasting his or hers time by blowing up > > in the final quality gate. > > > > In that sense the EWS is more like a network of try-bots. > > I don't think you necessarily need to automate it quite this far. Human > interaction is, after all, how communities get built, and how people > learn to do better. It also means that false positives won't mean that > someone's hard work gets chucked in the trash without an easy recourse > for getting it in. I'm not sure what you mean here. My point was that if the contributor has a suspicion his change might break on platform Y that he does not have access too, and that if that platform is not part of the set of bots that will automatically jump on a patch and build it (because building on that platform is slow), then he might want to summon the platform-Y-bot for a try-run to catch a build break early. The alternative would be that the integrator batches up 10 changes for a full run, and then the one patch breaks on platform-Y (as expected), blocking the other 9 patches from going in, and leaving the integrator with the job of figuring out which of the 10 patches broke, feeding this back to the contributors, etc. > The idea of automation is great, but at the end of the day, I think > there should be humans making the final calls in most cases. Right, the bots are advisory. So if you want advice from the platform-Y bot, you'll summon it. The human reviewer will notice that there's a bot still churning on a result, and not r+ it until the results are in. Tor Arne _______________________________________________ Opengov mailing list Opengov@qt-labs.org http://lists.qt-labs.org/listinfo/opengov
