On Wed, Jan 08, 2014 at 09:17:59PM +0100, Johan Engelen wrote:
On 23-12-2013 4:11, Bryce W. Harrington wrote:
On Sun, Dec 22, 2013 at 12:01:22PM -0800, Josh Andler wrote:
On Fri, Dec 20, 2013 at 4:56 PM, Bryce Harrington
- Who decides when a given job is "complete"? Do we need to have a separate reviewer role identified (analogous to GSoC mentor)? Should that person get some form of remuneration too? Should the role be interactive with the job performer, or an anonymous pass/fail?
Is this something that the fundraising coordinator should be tasked with or perhaps be the person who proposed the job be the one to review?
Possibly, although I worry that a good bit of time could pass between the proposal, the fundraiser, and the execution of the job, and both the proposer and fundraiser coordinator could drift away. Also, they may not have the technical skill or time/interest in doing the final review.
When is the work committed to trunk? ("committed to trunk" could be a very clear flag for job completion) Some refactoring projects may be best suited as a set of individual patches, instead of one big patch. That makes it much easier for bug tracking I think.
Theoretically refactoring could be done on a side branch and then merged. However, this is often easier said than done, in that if the mainline code changes even a little, it can cause a conflicted merge for the refactored code, resulting in a painful manual merge.
So, ideally it would be nice if the system was designed to permit continuous merging to mainline, throughout the development process.
The reviewer role should not be too large I feel (otherwise we will have trouble finding reviewers). One concern is that the reviewer might feel very pressured about his decision. It's about giving someone money, or not, and might end up with tough decisions. (What if the job is complete and all works well, but the coding style conflicts quite a lot with ours... and then the dev says it will take too much time to fix that and... community screams: gogo, commit already! etc...)
Very good points, and that does sound like a realistic scenario we'd probably hit a lot.
Or, they neglected to make the strings translatable. Or developed only on Linux and introduced platform issues for OSX/Windows that only show up after it's in mainline. Or adds a performance impact.
I suppose some of that is just technical debt we would absorb as a project as the cost for gaining the paid development, and handled through our regular open source community efforts, as happens with delivered GSoC projects. And ideally the developer would stick around to support their code.
For some of this, we leverage development tools. For instance, make one criterion be that it passes lint or some code style checker. And lean a lot on our test suite. So, the review job becomes more like a checklist.
Bryce