Kind of misleading, unless the policy of not funding 90% of hacking projects is reversed.

In T105414#1443624, @Bawolff wrote:

Kind of misleading, unless the policy of not funding 90% of hacking projects is reversed.

+1. We need to stop encouraging people to work on things in ways that go against our development philosophies (building user features with Gadgets).

@Bawolff & @Legoktm - how do you suggest to change it to make it less misleading/more accurate?

I suggest the Grant department change their policy on IEGs for tech projects to something more logical

To expand on that, there are some more details at https://meta.wikimedia.org/wiki/Grants:IEG/Questions/Archive_1#.22Projects_should_not_be_engineering-focused.22 and https://meta.wikimedia.org/w/index.php?title=Grants:IEG/Questions&oldid=11236668#MediaWiki_extensions (unanswered). This was also more recently discussed during the May metrics meeting (https://youtu.be/gM7MnL0Y9FA?t=37m9s) and apparently at the Lyon hackathon.

And also at Wikimania in London, and on wikitech-l in Feb ( https://lists.wikimedia.org/pipermail/wikitech-l/2015-February/080955.html ). I imagine there are other discussions too. There's been lots of discussions about it, without a whole lot of results.

I suggest the Grant department change their policy on IEGs for tech projects to something more logical

This sentence unfairly threw blame at the grants department. Unconfirmed rumors I've heard indirectly suggest that engineering at the C-level carries much of the responsibility for the current policy. Either way, my previous comment was probably more snarky than constructive (And this blame sentence probably isn't doing much better).

Anyways, its very frustrating to see tech IEGs have requirements that cripple the type of projects, effectively forcing them to be low impact (Yes sometimes gadgets/tool labs/etc can be very high impact, and yes, sometimes its the best approach for some problems, and yes there's some great people doing great things in that space, and I don't mean to denigrate any of the work they do, but for many projects it makes the solution significantly less effective and forces work to be done on the side, where it mostly remains unnoticed. In essence, it forces the "hacking project" to be a hack instead of a solution).

Ultimately though, the idealab/IEG people have their program to run, and the policies in place are not their fault... So I don't really know what to suggest. But as it stands (unless something has/will change), if someone with a programming background has an *idea* to change Wikipedia that should not be done a poor JS hack, and needed mentorship, collaborators, or maybe funding (for specific demographics that meet GSOC/OPW) they would probably find more success approaching a MediaWiki developer at random, then they would at IdeaLab. And that's a sad state of affairs.

Thanks for this last comment reframing the concerns - it is true this isn't a policy that grantmaking sets on our own, and we don't really love it either. As WMF engineering strategy updates over time, I would like to look into potential adjustments to what has in the past been a bright line. What I'd suggest we might do for this next round of IEG is revisit this on a case-by-case basis, looking at, for example, whether there are enough volunteers with code review permissions to ensure that any grant-funded proposals for extensions and the like would be able to go into production in a reasonable time-frame. If we can ensure that someone is committed and able to help get grant-funded work go live, we'll be more able to fund - we just really don't want to fund something that will never get through code-review, because wasting grantee time isn't good for anyone. In the past, that hasn't been something we were able to ensure. That said, I hope that we can work together on potential solutions for this. Suggestions about what changes to the eligibility or selection criteria you think would help us better achieve this, keeping in mind that we don't control WMF engineering resources, would be welcome.

Great to see this discussion! Piling on the anecdotal feedback as an erstwhile IEG grantee:

I went to an IEG talk two years ago, and it was enormously inspiring for me. Going through the trouble to write up my crazy wiki idea in a readable and sort of systematic structure was a great outcome, so I can vouch that overall the IEG process helped me quite a bit. In hindsight, however, what I really needed at the time was a mentor with more wiki experience to help me focus my idea down to a MVP, before I even attempted to pursue a grant.

My guess is that a lot of other projects are in a similar position, and it's beyond the grantmaking department's charter to respond to everyone's half-socialized brainstorming. Perhaps we should work on setting up additional institutions to help review and support all the creative energy out there?

It sounds like feedback and support coming out of the IEG process is already far more mature than when I made my blind lunge, but to finish my story anyway, the response to my proposal was {empty set}. In case this still happens, I'll just make a quick appeal that if grantmaking staff read a proposal and think "WTF, mate?", it would actually be very helpful to the erstwhile grantee if that were posted as a short, personalized note: "Your proposal is interesting but nonetheless crazed, perhaps you should try an RFC to clarify the central idea...." etc.

Much love!

Thanks for all of the feedback here. I've spoken with Siko about the background of the current IEG eligibility criteria for tech projects, briefly outlined in her comment above and in some of the pages linked to by Legoktm. While, as Bawolff correctly indicated, there is a dependency on Engineering staff that constrains how much wiggle room the Community Resources (formerly Grantmaking) Team has to revise the criteria in question, we are interested in doing whatever we can to support innovative tech projects coming from the community. Since the Engineering Department is undergoing significant change, there may be new opportunities we can explore. During this session at the Hackathon tomorrow, I'm interested in listening to any other ideas you may want to share on this theme as I think about possibilities for the future. Thanks again for all the ideas you've already shared here!

What is the status of this task, now that Wikimania 2015 is over? Did this meeting take place? If yes: Please provide an update and potentially summarize findings / potentially provide a link to anything relevant. If no: Please edit this task by removing the #Wikimania-Hackathon-2015 project from this task / potentially close this task by editing its status. Thanks for your help and keeping this task updated!

While, as Bawolff correctly indicated, there is a dependency on Engineering staff that constrains how much wiggle room the Community Resources (formerly Grantmaking) Team has to revise the criteria in question, we are interested in doing whatever we can to support innovative tech projects coming from the community

That's actually kind of the opposite of what I'm saying. It is not necessarily true that there is a dependency on foundation staff (or at least the type of dependency being implied), and its unfair to blanket restrict the grants because some people "want" engineering to help them with their grants.

I see your point, and agree that it isn't necessarily true that technical projects have a WMF-dependency. That said, my experience is that this tends to be true in terms of many of the grant proposals we've seen for technical projects in the past...particularly in the first-ever round of IEG right before we added this criteria.

We need clear criteria that don't waste proposers time suggesting things they're not able to accomplish in a timely fashion without access to WMF engineering staff. So, concrete suggestions still needed: If we wanted to keep the no-staff-dependency rule in place, and otherwise open up technical development grants more reasonably, what's the language change that you'd suggest for doing this?

Here is the current text that we'd be looking to adjust:
"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."

First of all, did the meeting happen in Wikimania? Are there any minutes or conclusions?

My thoughts, refreshed since the last round of discussions a year ago due to all the events that happened:

IEG doesn't need to come up with a new process to define suitable tech projects. It would be simpler to rely in existing processes. We have the Possible-Tech-Projects process for GSoC and Outreach. Now Community-Tech is also defining a process to shape a backlog of interesting projects (T105942). #Engineering-Community and Community Tech are starting to talk about how to combine these efforts better. There is also T88265: Investigate sources to fund third party MediaWiki features, which is another natural neighbor. At the end this is about matching these three elements in productive ways:

• projects outlined considered useful
• developers available (volunteers, interns, paid professionals...)
• supervisors available (mentors or maintainers or both)

What counts is whether we can have a match for project-developer-supervisor with a chance for success. The fact that the developer is a hackathon participant, a potential GSoC student, an IEG applicant, a MediaWiki consultant... is all relative. The fact that the supervisor is a WMF employee or not is also relative. What matters is whether the appropriate supervisors for a project are available and willing to get involved or not. Sometimes potential volunteer supervisors will be busy and will decline. And sometimes potential potential supervisors employed at the WMF will see a project fitting their interests, goals, roadmap... and will be happy to be involved.

It is not clear why we need a rule preventing WMF involvement by design. Nowadays teams have a planning process mature enough to decide whether they want to get involved in a specific IEG project or not, just like they decide the rest of their goals, sprints, and backlog priorities.

In T105414#1506527, @Qgil wrote:

First of all, did the meeting happen in Wikimania?

Also, what needs to be done to consider this task closed?

This task was just meant to be a session at Wikimania which happened successfully. I think it can be closed.
@Mjohnson_WMF any open ended things to take care of before closing this? Otherwise lets resolve it! :)
(I can do it this week if no response)

My apologies for a slow response on this thread. Thanks so much to everyone who has contributed comments either through Phabricator or in-person at Wikimania. Partially because of the feedback in this thread, we've updated the IEG eligible projects criteria with revised language that allows teams that can demonstrate capacity to take on projects that require code review and integration.

I thought some of you might be interested in taking a look at the software proposals that are coming in during the current open call for IEG, which runs through September 29th. You can take a look at drafts and proposed ideas at this link. Please feel free to offer your support to any of these proposals. You can do so by endorsing them, asking questions or providing constructive feedback on the talk page, or even offering to participate as a project advisor or volunteer for project ideas that especially interest you. You may even wish to jump in with an idea of your own.

Thanks again for all of the good discussion here.