I agree with Pine. The way I read the IEG strictures was that they would reject projects that required might need any code review at all; whether that's true or not it definitely discourages some projects that might be really useful.
As it stands, most of the projects I read through in the last round seemed to tend towards on-wiki exclusively, and to me it seemed that limited their usefulness. For instance, there was one project which was on-wiki/labs only which was similar to my FOSS OPW project, and a few responses to that was that the more integrated approach was preferred- given that the OPW round was already complete and the project still ongoing at that time it seems fair, but if the two projects had been up for funding/approval at the same time, then the issue of code review would have made it a fundamentally un-level playing field. Why not loosen the strictures by saying projects with *some* minor amount of code review would be allowed, with the added caveat that the proposal would be rejected if the staff who would support it felt they couldn't sustain the expected level of code review? That approach might be flexible enough to include more interesting/useful projects as well as hopefully not produce too dramatic of an impact on staff. I also think Brian's idea of including a volunteer with +2 to do code review on the grant application is a wonderful idea; I would add in that it would also be possible for part-time contractors to do this as well. Even if the person didn't have +2 on the repository, having a dedicated person with experience in mediawiki do code review could lesson the load considerably on staffers who would +2 it. On Sat, Feb 21, 2015 at 9:26 PM, Brian Wolff <[email protected]> wrote: > On 2/21/15, Pine W <[email protected]> wrote: > > (Now continuing this discussion on Wikimedia-l also, since we are > > discussing grant policies.) > > > > For what it's worth, I repeatedly advocated for allowing IEG to support a > > broader range of tech projects when I was on IEGCom. I had the impression > > that there was a lot of concern about limited code review staff time, but > > it serms to me that WMF has more than enough funds to to pay for staffing > > for code review if that is the bottleneck for tech-focused IEGs (as well > as > > other code changes). > > > > I also think that the grant scope policies in general seem too > conservative > > with regard to small grants (roughly $30k and under). WMF has millions of > > dollars in reserves, there is plenty of mission-aligned work to be done, > > and WMF itself frequently hires contractors to perform technical, > > administrative, communications, legal and organizing work. It seems to me > > that the scope of allowed funding for grants should be similar to the > scope > > of allowed work for contractors, and it would serve the purposes that > > donors have in mind when they donate to WMF if the scope of allowed > > purposes for grants is expanded, particularly given WMF's and the > > community's increasing skills with designing and measuring projects for > > impact. > > That's actually debatable. There's grumbling about WMF code review > practices not being sufficient for WMFs own code (or as sufficient as > some people would like), and code review is definitely a severe > bottleneck currently for existing volunteer contributions. > > However that's not a reason to have no IEG grants for tech projects > ever, its just a reason for code review to be specifically addressed > in the grant proposal, and for the grantee to have a plan. Maybe that > plan involves having a (volunteer) friend who has +2 do most of the > code review. Maybe that plan involves a staff member getting his > manager to allow him/her to have 1 day a week to review code from this > grant (Assuming that the project aligns with whatever priorities that > staff member's team has, such an arrangement does not seem > unreasonable). Maybe the grant includes funds for hiring code review > resources (ie non-wmf people with +2. We exist!). Maybe there is some > other sort of arrangement that can be made that's specific to the > project in question. Every project is different, and has different > needs. > > I do not think expecting WMF engineering to devote significant > resources to IEG grants is viable, as I simply doubt its something > that WMF engineering is willing to do (And honestly I don't blame > them. They have their own projects to concentrate on.). IEG's are > independent projects, and must be able to stand mostly on their own > with minimal help. I do think getting WMF to perform the final once > over for security/performance of a project prior to deployment, at the > end, is reasonable (provided the code follows MW standards, is clean, > and has been mostly already reviewed for issues by someone in "our" > community). At most, I think bringing back 20% time, with that time > devoted to doing code review of IEGs, would be the most that we could > reasonably expect WMF to devote (but even if they didn't want to do > that, I don't think that's a reason not to do IEG tech grants). > > Code review is an inherent risk to project success, much like user > acceptability. It should be planned around, and considered. We should > not give up just because there is risk. There is always risk. Instead > we must manage risk as best we can. > > > --bawolff > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
