(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" bawolff@gmail.com wrote:
On 2/21/15, Pine W wiki.pine@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 just don't like there being only 1 stakeholder). One way for there to be a more diverse group of interests is to allow grants to groups with goals consistent with Wikimedia's. While not exactly super diverse (all groups have similar goals), at least there would then be more groups, and hopefully result in more interesting and radical projects.
--bawolff
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 2/21/15, Pine W wiki.pine@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
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
On Sat, Feb 21, 2015 at 4:19 PM, MZMcBride z@mzmcbride.com wrote:
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.
I don't think one size fits all -- every case needs to be judged on its merits, though in the case of GLAMWikiToolset I am definitely arguing for considering separation from the MediaWiki codebase because it is so highly specialized. I also think we sometimes still have a tendency to underestimate the value of non-MediaWiki tools and apps, even though they've contributed millions of edits to Wikimedia wikis already (though to be fair, without Magnus Manske the tally would not be nearly as awesome).
Regarding the criteria for grantmaking, I think this initial blanket prohibition against all MediaWiki extension development is indeed something we ought to revisit. These grants can cover tens of thousands of dollars of paid work, so we shouldn't treat the review and integration burden lightly, and avoiding stalled projects that are going nowhere was a reason I advocated for this restriction to begin with. But as long as there is a good plan in place -- either not significantly dependent on WMF or with clear commitments negotiated upfront -- I do agree that the risks can be significantly mitigated.
Damon, Luis and members of their teams will need to weigh in on this, and will want to think through the implications for their respective areas, but it's a good conversation to have -- keeping in mind that Luis is just starting in his new role, so please give him at least a few days to get up to speed. ;-)
Erik
On Sat, Feb 21, 2015 at 5:39 PM, Erik Moeller erik@wikimedia.org wrote:
Damon, Luis and members of their teams will need to weigh in on this, and will want to think through the implications for their respective areas, but it's a good conversation to have -- keeping in mind that Luis is just starting in his new role, so please give him at least a few days to get up to speed. ;-)
Thanks for at least a few hours of cushion, Erik ;)
I'm a big believer in the power of/need for software tools, and at least philosophically I'm very open to funding software development outside the Foundation (though obviously there are lots of pragmatic difficulties - code review, etc.) So, yes, as part of our broader review of how we support communities and contributor growth, CE will look at funding code very seriously.
Luis
Hi Luis,
Thank you for agreeing to consider grant funding for software projects.
It sounds like you also plan a broader review of funding for community needs and growth. I have a list of requests for changes, which boil down to removing policy barriers and greatly improving communications and workflows so that community growth is fostered and volunteer time is used wisely. I imagine that we will have an opportunity to discuss these matters in person in Berlin. I look forward to seeing you there, and I greatly appreciate your interest in supporting communities and contributor growth.
Pine On Feb 21, 2015 6:12 PM, "Luis Villa" lvilla@wikimedia.org wrote:
On Sat, Feb 21, 2015 at 5:39 PM, Erik Moeller erik@wikimedia.org wrote:
Damon, Luis and members of their teams will need to weigh in on this, and will want to think through the implications for their respective areas, but it's a good conversation to have -- keeping in mind that Luis is just starting in his new role, so please give him at least a few days to get up to speed. ;-)
Thanks for at least a few hours of cushion, Erik ;)
I'm a big believer in the power of/need for software tools, and at least philosophically I'm very open to funding software development outside the Foundation (though obviously there are lots of pragmatic difficulties - code review, etc.) So, yes, as part of our broader review of how we support communities and contributor growth, CE will look at funding code very seriously.
Luis
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *"Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment."* _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Sun, Feb 22, 2015 at 12:24 PM, Pine W wiki.pine@gmail.com wrote:
Hi Luis,
Thank you for agreeing to consider grant funding for software projects.
It sounds like you also plan a broader review of funding for community needs and growth.
Yes. The timeline is still somewhat up in the air, but "soon" - likely sooner than Berlin.
I have a list of requests for changes, which boil down to removing policy barriers and greatly improving communications and workflows so that community growth is fostered and volunteer time is used wisely.
I'd be interested to hear those, though probably on meta rather than here.
I greatly appreciate your interest in supporting communities and contributor growth.
Thanks. Of course, the Foundation has long been active on those areas (we spend millions of dollars a year doing them!) but I think we're always interested in doing it better.
Luis
Pine On Feb 21, 2015 6:12 PM, "Luis Villa" lvilla@wikimedia.org wrote:
On Sat, Feb 21, 2015 at 5:39 PM, Erik Moeller erik@wikimedia.org
wrote:
Damon, Luis and members of their teams will need to weigh in on this, and will want to think through the implications for their respective areas, but it's a good conversation to have -- keeping in mind that Luis is just starting in his new role, so please give him at least a few days to get up to speed. ;-)
Thanks for at least a few hours of cushion, Erik ;)
I'm a big believer in the power of/need for software tools, and at least philosophically I'm very open to funding software development outside the Foundation (though obviously there are lots of pragmatic difficulties - code review, etc.) So, yes, as part of our broader review of how we
support
communities and contributor growth, CE will look at funding code very seriously.
Luis
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *"Imagine a world in which every single human being can freely share in
the
sum of all knowledge. That's our commitment."* _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hoi, I alone have contributed millions of edits thanks to Magnus's tools. The whole GLAM phenomenon relies on our volunteers and on the GLAM-wiki toolset. When you consider their proven importance it is difficult, if not impossible, to understand why all such tools have been given the Cinderella treatment.
When I consider the way the WMF treats prerequisites like Labs, I find it is given the same treatment. We know that there is not sufficient staffing and hardware and the priorities of the big sister projects takes staffing easily away. When you consider down time of Labs and Labs applications things have been getting worse.
I do not blame, Magnus, the Labs team nor the Wikidata team I blame the WMF that could so easily be mistaken for the en,WPF. This is systemic just consider the recent report of 2014 where the "other" Cinderella projects like Wikisource, Wikidata, Wikibooks were not mentioned at all.
When you think this is not true, please let us know what plans there are to support the Cinderella projects. How much funding, human resources are available for them. How do you think I, as a long time Wikimedian, became this harsh in my opinion? I ask for plans because what else is there ?
I find that the WMF is self absorbed and while it considers itself clear in its objectives what options are there so that the Cinderella's can go to the ball as well in the off chance of glass slippers and a prince. Thanks,
On 22 February 2015 at 02:39, Erik Moeller erik@wikimedia.org wrote:
On Sat, Feb 21, 2015 at 4:19 PM, MZMcBride z@mzmcbride.com wrote:
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.
I don't think one size fits all -- every case needs to be judged on its merits, though in the case of GLAMWikiToolset I am definitely arguing for considering separation from the MediaWiki codebase because it is so highly specialized. I also think we sometimes still have a tendency to underestimate the value of non-MediaWiki tools and apps, even though they've contributed millions of edits to Wikimedia wikis already (though to be fair, without Magnus Manske the tally would not be nearly as awesome).
Regarding the criteria for grantmaking, I think this initial blanket prohibition against all MediaWiki extension development is indeed something we ought to revisit. These grants can cover tens of thousands of dollars of paid work, so we shouldn't treat the review and integration burden lightly, and avoiding stalled projects that are going nowhere was a reason I advocated for this restriction to begin with. But as long as there is a good plan in place -- either not significantly dependent on WMF or with clear commitments negotiated upfront -- I do agree that the risks can be significantly mitigated.
Damon, Luis and members of their teams will need to weigh in on this, and will want to think through the implications for their respective areas, but it's a good conversation to have -- keeping in mind that Luis is just starting in his new role, so please give him at least a few days to get up to speed. ;-)
Erik
Erik Möller VP of Product & Strategy, Wikimedia Foundation
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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 bawolff@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.
wikimedia-l@lists.wikimedia.org