Re: [Wikitech-l] Types of allowed projects for grant funding (renamed)
I also think that we should revisit this policy. Any IEG should have a feasibility plan. In GSoC / Outreachy usually the mentors are the ones guaranteeing code review. In IEG that guarantee should be provided in other ways, but it is possible to provide it. For what is worth, https://www.mediawiki.org/wiki/Outreach_programs/Possible_projects are already defined as project ideas that might also be good candidates for Individual Engagement Grants. I wish IEG brokers would subscribe to https://phabricator.wikimedia.org/tag/possible-tech-projects/ to find inspiration; projects listed there are going through a community filter that ;looks for wanted projects with a good size foir an IEG. On Sat, Feb 21, 2015 at 10:26 PM, Brian Wolff bawo...@gmail.com wrote: code review is definitely a severe bottleneck currently for existing volunteer contributions. Yes, and addressing this problem is becoming a priority for the Engineering Community team. See/join https://phabricator.wikimedia.org/T78768. But again, well planned IEG could avoid this problem entirely by finding the right partners. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Types of allowed projects for grant funding (renamed)
Brian Wolff wrote: Maybe the grant includes funds for hiring code review resources (ie non-wmf people with +2. We exist!). For what it's worth, you're exactly the type of person I would like to have working at the Wikimedia Foundation. I love your posts here; thank you for taking the time to write them. Figuring out what level of technical support we can give to non-Wikimedia Foundation projects is a really important issue, in my opinion. Brian Wolff wrote (in a related thread): Ostensibly this is done in the name of: Any technical components must be standalone or completed on-wiki. Projects are completed without assistance or review from WMF engineering, so MediaWiki Extensions or software features requiring code review and integration cannot be funded. On-wiki tech work (templates, user scripts, gadgets) and completely standalone applications without a hosting dependency are allowed. Which on one hand is understandable. WMF-tech has its own priorities, and can't spend all its time babysitting whatever random ideas get funded. So I understand the fear that brought this about. On the other hand it is silly, since a grant to existing tech contributors is going to have much less review burden than gsoc/opw, and many projects might have minimal review burden, especially because most review could perhaps be done by non-wmf employees with +2, requiring only a final security/performance sign off. In fact, we do already provide very limited review to whatever randoms submit code to us over the internet (regardless of how they are funded, or lack thereof). Erik seems to be pushing toward a model that favors using OAuth and the MediaWiki API over deep integration that comes with a MediaWiki extension. He recently mentioned this here: https://lists.wikimedia.org/pipermail/glamtools/2015-February/000343.html He may be right that development for deployment to the Wikimedia Foundation cluster may not be the best approach for every project, but I think this view overlooks all the very real benefits that extension deployment includes. There's a documented process that has safety checks such as putting the code in Gerrit and having a security review. Checklist: https://www.mediawiki.org/wiki/Review_queue#Checklist. Process: https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment. MediaWiki is the platform. Features include persistent database or file storage, user authentication, internationalization, a usable Web API and user interface, and more! If IEG grants were allowed in this area, it would be something that the grantee would have to plan and account for, with the understanding that nobody is going to provide a team of WMF developers to make someone else's grant happen. Yeah, my understanding is that Sue was behind this hard rule and times have changed. I guess this would be a matter of Siko and her team re-petitioning Damon, Erik, or Lila to soften this rule, probably by appending a or have a detailed code review plan in place with appropriate sign-off/endorsement clause. This code review plan would be some kind of template where people can do due diligence to try to ensure that their code review needs will be met. More broadly, in terms of getting code deployed to the Wikimedia Foundation server cluster, we have at least three major code review areas: security, performance, and architecture. A code review plan (for grants and non-grants alike, to be honest) that addresses at least these three areas, plus user acceptance, as you mention, would be fantastic, I think. And/or we can explore the model proposed by dan entous: --- instead of having to write a grant requests and/or seeking other forms of funding, establish a grant or funding committee that looks for projects and developers that have proven helpful and have added value to the community. then award them with funding without them having to ask for it. --- Politically, I think its dangerous how WMF seems to more and more become the only stakeholder in MediaWiki development (Not that there is anything wrong with the WMF, I just don't like there being only 1 stakeholder). Yup. Other groups such as Wikimedia Chapters are also interested, but all most of the funding streams go through the Wikimedia Foundation for redistribution at this point, as I understand it. Maybe a MediaWiki Foundation still makes sense... Brion and others have been pushing for a wiki hosting platform (that isn't the ad-plagued Wikia, heh): https://lists.wikimedia.org/pipermail/wikitech-l/2015-January/080171.html MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Types of allowed projects for grant funding (renamed)
This, all of this. On 21/02/15 21:26, Brian Wolff wrote: 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 I just don't get it. Why is there no support at all for funded tech projects outside of GSoC/Outreachy, which have very specific target audiences? Why are there only grants for non-technical things when the technical is the biggest part of what actually supports the other projects and allows them to grow over the long term, when the non-technical projects need better backend support in order to truly succeed, when there are so many things in general that need to be done around wikimedia that volunteers need and want to do, things for sister projects and multimedia and community interaction, that don't get done because nobody has the time or resources to actually make it happen? Things that the WMF wouldn't even know where to begin with, wouldn't have the know-how to do themselves, wouldn't have the connections or the languages for... and would never even prioritise to begin with? What about these? I'm actually doing an IEG currently and because of all this our only recourse for the product part of the project is basically to make template and gadget soup. Given the nature of this project, of course, that might have been the most likely outcome anyway just because it's on enwp and that's what wikipedians seem do in general, but so many other potential projects are simply stopped dead, regardless of what their potential or worth might have been. There's limitations and concerns with any kind of project, doesn't matter what it is. You should just need to have a feasible way to address them, that's all. Glargh. -I ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Types of allowed projects for grant funding (renamed)
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 bawo...@gmail.com wrote: On 2/21/15, Pine W wiki.p...@gmail.com 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
Re: [Wikitech-l] Types of allowed projects for grant funding (renamed)
(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. In the past I think there were probably some wasteful uses of grant funding, and the response at the time might have been to prohibit or refuse to fund entire categories of expenses. Now that everyone has more planning and evaluation capacity, it seems to me that this is a good time to rethink the categorical prohibitions and replace at least some of them with appropriate expectations for impact that would better serve our overall mission of creating and sharing knowledge. Pine On Feb 21, 2015 12:05 PM, Brian Wolff bawo...@gmail.com wrote: On 2/21/15, Pine W wiki.p...@gmail.com wrote: In general WMF has a conservative grant policy (with the exception of IEG, grant funding seems to be getting more conservative every year, and some mission-aligned projects can't get funding because they don't fit into the current molds of the grants programs). Spontaneous cash awards for previous work are unlikely. However, if there is an existing project that could use some developer time, it may be possible to get grant funding for future work. [Rant] I find this kind of doubtful when IEG's (which for an individual developer doing a small project is really the type of funding that applies) have been traditionally denied for anything that even remotely touches WMF infrastructure. (Arguably the original question was about toollabs things, which is far enough away from WMF infrastructure to be allowed as an IEG grant, but I won't let that stop my rant...). Furthermore, it appears that IEGs now seem to be focusing primarily on gender gap grants. I find it odd, that we have grants through GSOC and OPW to people who are largely newbies (although there are exceptions), and probably not in a position to do anything major. IEG provides grants as long as they are far enough away from the main site to not actually change much. But we do not provide grants to normal contributors who want to improve the technology of our websites, in big or important ways. Ostensibly this is done in the name of: Any technical components must be standalone or completed on-wiki. Projects are completed without assistance or review from WMF engineering, so MediaWiki Extensions or software features requiring code review and integration cannot be funded. On-wiki tech work (templates, user scripts, gadgets) and completely standalone applications without a hosting dependency are allowed. Which on one hand is understandable. WMF-tech has its own priorities, and can't spend all its time babysitting whatever random ideas get funded. So I understand the fear that brought this about. On the other hand it is silly, since a grant to existing tech contributors is going to have much less review burden than gsoc/opw, and many projects might have minimal review burden, especially because most review could perhaps be done by non-wmf employees with +2, requiring only a final security/performance sign off. In fact, we do already provide very limited review to whatever randoms submit code to us over the internet (regardless of how they are funded, or lack thereof). If IEG grants were allowed in this area, it would be something that the grantee would have to plan and account for, with the understanding that nobody is going to provide a team of WMF developers to make someone else's grant happen. We should be providing the same amount of support to IEG grantees that we would to anyone who submitted code to us. That is, not much, but perhaps a little, and the amount dependent on how good their ideas are, and how clean their code is. [End rant] Politically, I think its dangerous how WMF seems to more and more become the only stakeholder in MediaWiki development (Not that there is anything wrong with the WMF, I
Re: [Wikitech-l] Types of allowed projects for grant funding (renamed)
On 2/21/15, Pine W wiki.p...@gmail.com 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
