Grants talk:IdeaLab/Timeless

Project Grant proposal submissions due today!

Thanks for drafting your proposal for a Project Grant. Proposals are due today! In order for this submission to be reviewed, it must be formally proposed. When you have completed filling out the infobox and have fully responded to the questions on your draft, please change status=DRAFT to status=PROPOSED to formally submit your grant proposal. This can be found in the Probox template found on your grant proposal page. If you have already done this, thanks for your submission, and you should be receiving feedback from the Project Grants committee in the coming weeks. Thanks, I JethroBT (WMF) (talk) 18:16, 14 March 2017 (UTC)

Mockup

Hi, I'm very interested in your project, could you possibly make a mockup for a more cluttered page, such as https://en.wikipedia.org/wiki/Joan_of_Arc -- it has lots of interwiki, a big infobox, some vertical and horizontal templates, rows of pictures aligned both vertically and horizontally, lots of references, some other stuff in the left menu etc. Also some people use gadgets that are showing up in the menus: see http://i.imgur.com/x6uo3qk.png + http://i.imgur.com/qoavvFr.png + http://i.imgur.com/mbP3G7r.png (that's my left menu in RuWiki, the rectangle marks the gadgets I use)... It would also be nice to see what other projects would look like, for example http://i.imgur.com/IQdroCG.png (that's my Commons interface with some gadgets as well). Le Loy 05:04, 15 March 2017 (UTC)

Well, I tried to recreate the Joan of Arc article on my development machine, and I've got to say... I need a better internet connection, and apparently Wikimedia has some DAMN powerful servers, because parsing that took well over a minute on mine. Also the category handling needs serious work, and also we need better infobox handling in general, not that timeless is any worse than vector in that regard. Um. Interesting. (Also note that some of the custom wikipedia css is probably missing; I just shoved the entire common.css into the page and didn't really check any of it.)

As for the gadgets, yeah, depending on what they're doing, they probably aren't going to work currently. That's something that needs to be looked into, because obviously these gadgets are wanted/needed, so breaking everything is not the right way forward, but how exactly to keep them working (whether by skin changes, mw changes, or changes to the gadgets themselves) I can't say yet.

Okay, seriously, how are those categories even useful? Did I... seriously underestimate how hard all of this was going to be? Oh, gods... I did... -— Isarra ༆ 08:05, 15 March 2017 (UTC)

Note that some of those categories are of the 'hidden' sort. —TheDJ (talk • contribs) 15:05, 28 March 2017 (UTC)

Ah, yeah, that information wouldn't have been included when I just stole the page off the wiki, so that'd explain it. -— Isarra ༆ 03:05, 29 March 2017 (UTC)

Note that content styling is a difficult part of a skin. It requires the corporation of page authors, requires to be somewhat 'consistent'/recognisable across multiple skins and also incorporates some skin specific elements at the same time. I usually identify 3 categories when it comes to skinning. Chrome (everything outside 'user editable content', recurring elements inside content (thumbnail frames headers etc), and 'wild west' (infoboxes and other project and/or page specific stuff) inside user editable content. As some might know, I've been exploring unifying some of content specific styling between mobile, Vector desktop and other skins. I've made those first results available as a en:User:TheDJ/responsiveContent (css). It's ugly as hell, but proofs that it can work and that we should be creating core structures for that, instead of stuffing everything inside MobileFrontend/minerva. I've also been working on a version of Vector that is a bit more responsive (css). Steal as you please, unify where you can :) —TheDJ (talk • contribs) 15:05, 28 March 2017 (UTC)

BTW, these experiments proof how difficult it is to tackle problems like these. I basically have to resort to building gadgets, because doing it in MediaWiki straight away is too complicated a process which doesn't allow me to make mistakes. It's the result a year of going through various versions, adapting as required etc, all to make sure that people don't pull the plug on my experiment before it even gets started. —TheDJ (talk • contribs) 15:11, 28 March 2017 (UTC)

@TheDJ: Okay, that stuff is a massive chunk of what properly scares me about this project, and the fact that you've already been putting work into it and I'll be able to at very least use that as a reference when documenting it all (and ideally coming up with more robust ways of creating/interfacing with the things in question, but that's harder, and I need to remind myself NO MAKING EXTENSIONS FOR INFOBOXES NO MAKING EXTENSIONS FOR INFOBOXES NO MAKING EXTENSIONS FOR INFOBOXES OUT OF SCOPE DON'T DO IT etc) is going to be very helpful. But if we can come up with something more robust down the road... even if it's not used directly or whatever, the headway you've made will only make things that much easier. -— Isarra ༆ 03:05, 29 March 2017 (UTC)

i like the direction taken with this skin. is it possible to do a skin with top down menus only (i.e. move left and right menu to the top) this would be more mobile / tablet friendly; works better on small screens. i note there is a gadget on wikisource that moves in that direction. "Sidebar Flat-list" [1], [2], but it adds some load time. Slowking4 (talk) 14:28, 4 April 2017 (UTC)

@Slowking4: Timeless does this at lower resolutions, but there are a few other skins that just do this for all of them (GreyStuff and Splash being two I've made, with varying levels of menu complexity) (aside from mobile, which tends to need slightly more targeted interfaces anyway). I also made one for a third-party organisation that has a user preference option whether to put the sidebar on the side or on top using dropdowns, and this might be an option to consider here, too, depending on what people want. Even if it isn't built into the skin, though, switching to a different responsive mode should be a lot easier for a gadget, too, when they already exist in the skin itself. -— Isarra ༆ 18:32, 6 April 2017 (UTC)

Community notification

Hey Isarra, thanks for your proposal on building a skin that addresses various issues for readers, contributors, and developers. When you're able (and if you haven't already), will you be able to notify some of the communities you've listed on the proposal? (Speaking as an editor for a moment, I expect many developers and long-time editors have a lot to say about the existing skins, and I think their feedback on this proposed solution will be helpful.) If you need some help crafting some of the language for the messaging, let me know and I'd be happy to help wordsmith or revise anything if you need a hand there. Thanks, I JethroBT (WMF) (talk) 21:40, 20 March 2017 (UTC)

@I JethroBT (WMF): Yeah, that's the plan, as soon as I have a bit more to notify about (I'm currently setting up a labs wiki so people can actually test it). Any recommendations on how exactly to do that? Just drop by their versions of the village dump and say 'hi I'm making a skin and there's a grant, check it out, would love your feedback' or some such? -— Isarra ༆ 18:53, 23 March 2017 (UTC)

@Isarra: Great to hear you're making using of labs to test it out. I think in general when asking for help with testing, it's helpful to direct people to provide feedback on specific matters. Folks will do whatever they want in testing of course, and there is a lot of value in that, but if there are specific kinds of tasks or matters you want feedback on (e.g. moving a page, finding a double redirect using "what links here", resolution issues on different devices), ask participants to consider a small number of specific tasks in addition to whatever they want to do on their own. You might also update en:Wikipedia:Customisation. Some of the mediawiki and technical mailing lists might also be good to notify to gather interested participants. I'll ponder this a little more and let you know if there are other places you might get in touch with, but I think this and what you've suggested with the (heh) village dumps is a good start. I JethroBT (WMF) (talk) 18:02, 24 March 2017 (UTC)

@I JethroBT (WMF): The French Wiktionary community, our most active Wiktionary project, has favourably welcomed the Timeless skin and is thrilled to be able to test and use a responsive skin, in this discussion. --Dereckson (talk) 15:52, 27 March 2017 (UTC)

Isarra, I just want to +1 I JethroBT (WMF)'s guidance about prompting people to give feedback on specific matters. Sometimes, people tend to want to merely give a thumbs up about a project proposal, but it is much more impactful to have comments that clearly describe the needs/problems this proposal addresses, and/or objections that arise in response to your proposed solution. Anything specific and substantive is much appreciated. I encourage you to solicit feedback in a way that encourages people to comment along these lines, rather than merely endorsing. Thank you! --Marti (WMF) (talk) 20:02, 27 March 2017 (UTC)

But that's the problem! I don't know! That's why I need the time to actually be able to look into this and sort it out, because nobody every has - there's this underlying consensus, especially among people outside Wikimedia, that the skins are bad, that things are ugly, that it's really hard to figure out, but what exactly is good or bad about it? What's what we need to find out. That's the biggest problem of all, here. -— Isarra ༆ 23:10, 27 March 2017 (UTC)

I suppose I could just ask for people to give feedback within a category, and if they have anything specific, please share, this is what I need? One of the biggest problems faced by similar products (vaguely-speaking) has been that they were all very specifically focussed on test cases the developers already knew about, though. This is precisely what I want to avoid...

Wait, or are you guys just saying I should literally tell them to 'bring up specific issues you've run into'? Because that would be a lot easier and I just totally misunderstood thinking you wanted me to be specific about the sort of things to prompt them about? Also that would be a good idea, yes. -— Isarra ༆ 23:16, 27 March 2017 (UTC)

Yeah, now I feel like an idiot. Can I just steal your words? -— Isarra ༆ 00:30, 28 March 2017 (UTC)

Eligibility confirmed, round 1 2017

This Project Grants proposal is under review!

We've confirmed your proposal is eligible for round 1 2017 review. Please feel free to ask questions and make changes to this proposal as discussions continue during the community comments period, through 4 April 2017.

The committee's formal review for round 1 2017 begins on 5 April 2017, and grants will be announced 19 May. See the schedule for more details.

Questions? Contact us.

--Marti (WMF) (talk) 19:53, 27 March 2017 (UTC)

Feedback on your proposal

Hi again, Isarra,

First of all, I want to thank you for submitting such a thorough proposal. After observing your work on WikiProject X, I'm glad to see you returning to offer your design skills in another area. :-)

In the couple of preliminary conversations I've had about your project, I have gotten very positive feedback about your proposal, with indications both that this is idea would be eagerly welcomed by many in our volunteer communities, and that there is a great deal of confidence in your ability to carry it forward. As you know code review and deployment would be required, but so far, the input I've received indicates that there are enough qualified code reviewers interested in seeing some progress in skins that it won't pose a problem. It's been suggested that your project would bring experimentation and innovation in an area where it is needed and wanted. I'm also noting and appreciating how responsive you've been to community comments and questions on your talkpage, which I've come to see as an indicator that an applicant is ready to handle the responsibilities of participating in an open, collaborative grant program like ours.

I do have a few questions for you about your proposal:

• In your problem statement, you list several problems with the existing skin options. Can you elaborate on the following two:
  • Can you briefly summarize what makes existing skins difficult to develop and design for?
  • You suggest that there is brand dilution problem when the Wikimedia projects use the same skin as the over 6,000 non-Wikimedia wikis using MediaWiki software. Does this mean that you expect that the Timeless Skin will not be available for all MediaWiki sites, but rather only for Wikimedia Projects? If not, how will Timeless help with brand recognition?
• You suggest that the current skins contribute to convoluted workflows that slow users down, but also hint that changing the skin may interfere with workflows users are accustomed to (and perhaps attached to), despite possible inefficiencies. In my mind, this is the most difficult problem you call out in your problem statement. You go on to name multiple target groups who may be affected: editors, uploaders, backend developers, front-end designers, template and gadget creators, and every combination thereof, on all the various projects. You have done a good job of demonstrating a solid preliminary understanding of the problems these groups face in your problem statement, which suggests you are well-positioned to the further research you propose. Nevertheless, completing the research phase and getting clarity about user needs sounds like it may be quite complex. Do you think it is realistic to complete this research and go on to develop a complete product and deploy it to all wikis and resolve inevitable bugs and unexpected use cases and encourage adoption/testing among users and track rates and collect feedback? In my mind this is a HUGE scope of work for the timeline and budget of your project. Can you give feedback about the feasibility of your plan? Do you think you might need to scale back your scope of work?
• Currently, most of your measures of success are focused on listing outputs for your project. You may recall from conversations about WikiProject X that we like our grantees to provide measures for both outputs (things you will make or do during your project) and outcomes (what you hope will happen as a result of the things you made or did). We also like measures to be specific, measurable, achievable, relevant and timebound (for which we use the acronym, SMART). Can you take another pass at your measures of success to make them SMART and to include more outcome-based targets? This can be tricky. If you would like help, feel free to reach out and ask for it.
• Would you mind creating a table for your budget that breaks your time/cost up into project phases (i.e. research, development, deployment, etc)? Part of the reason I'm asking you to do this is because I want you to think carefully about how much time each phase will require and make sure your budget is reasonable. As you acknowledge, you do need to eat, so best not to promise to do way more than you can possibly hope to finish with $48,000 worth of your time. I agree that you are "probably seriously underestimating what this is going to take." ;-)
• Thanks for your efforts at notification. This is a project for which notification is especially important, so I hope you will continue to prompt feedback (I enjoyed that you credited Pine for his seemingly ubiquitous support in matters of notification). As I've said already on your talkpage, please try to prompt specific, substantive feedback (beyond just the equivalent of a high five), as much as possible.
• If you haven't already done so, I suggest you check out the resources available in the Survey Support Desk as you think about your research phase.

The committee will begin scoring on April 5. If you decide to make any revisions in response to my comments, please try to make them before then. Ideally, you should incorporate changes into the proposal itself, but also reference them here on your talkpage so it is clear in both places what you've changed.

Thanks, Isarra!

Kind regards,

--Marti (WMF) (talk) 22:17, 27 March 2017 (UTC)

@Mjohnson (WMF): Thanks! Specifics, then:

• ...briefly summarize what makes existing skins difficult to develop and design for - do you mean like one line to sum up all of that section? Because if so, I'm not really sure how beyond 'skins, skinning, and everything associated is all a huge mess'.
• You suggest that there is brand dilution problem... - this is a good point about other sites, since already a bunch use Timeless, and the number will only increase down the road, and I certainly have no intention to try to stop them. So I guess more emphasis on the planned themeing capabilities, and also just having a more distinctive visual identity, more than actually unique, is what we're after here. Vector mostly just gives off vibes of being old without really looking like much in particular to people unless they're actually used to it... something something.
• Do you think it is realistic to complete this research and go on to develop a complete product and deploy it to all wikis and resolve inevitable bugs and unexpected use cases and encourage adoption/testing among users and track rates and collect feedback? In my mind this is a HUGE scope of work for the timeline and budget of your project. Can you give feedback about the feasibility of your plan? Do you think you might need to scale back your scope of work? Yes. Or, more accurately, it's completely ridiculous, but all these things kind of tie into each other and to an extent even depend on each other, so I kind of expect to have to. But the timeline is almost certainly too short to actually complete much of any of it - I'm still working out actual details, but would it make sense to push the timeline up to a year? Or, alternately, to just make the scope of this grant starting down all the things, and then after three months or something, renewing with a better idea how the overall timeline is going to look?
• a table for your budget that breaks your time/cost up into project phases and Measures of success - on it. Outcomes I was sort of glossing over as implicit for some reason, but yeah, if I never actually specify them, they'll be hard to measure...

And more notifications incoming! It would have all happened sooner, of course, but... I'm kind of bad at this, frankly.

Thank you. Seriously. -— Isarra ༆ 03:57, 28 March 2017 (UTC)

Isarra,

Thanks for the quick response. Just wanting to respond to your question about how to frame your scope of work in a feasible way. You note at the top of your proposal that you have a loose, overall plan for your work on Timeless that may require more than one round of funding to achieve. While it's strategically worthwhile for you to be thinking through your overall plan, you need to stay clear that this particular proposal should be focused on the narrow scope of work you hope to achieve with this round of funding. While also communicating other more nuanced ideas, your proposal ultimately needs to clearly answer the question, "What will you give us if we give you $48,000?" (to put it in very bald terms). Your proposal will be more competitive if you can deliver some concrete outcomes that stand alone and aren't dependent on future rounds of funding. So, for example: one option would be to pare down your proposal and focus solely on research based on specific questions about user needs in regard to skins. The new knowledge culled from your research would be a stand-alone deliverable of this project. Once this research is completed, you could apply for a renewal and begin responding to the needs your research identified. This way of staging your project avoids you having to say, "I'll do a little bit of work in each category, but nothing will be completed at the end of this round of funding." And, in the case your life takes a turn and you lose interest in developing Timeless, you will have completed a discrete phase of work that makes it easier to pass along the results of your work to another person.

Let me know if this doesn't make sense and, if needed, we can jump in a call to clarify. The main thing is that you want to be really clear about what you can and cannot complete with this single round of funding.

--Marti (WMF) (talk) 04:28, 28 March 2017 (UTC)

@Mjohnson (WMF): The mentioned overall plan has a scope pretty much encompassing every interface aspect of MediaWiki. It's huge and vague and scar and will take years and require many more people involved. This... this is much smaller, a single thing (a skin) outside of core itself that can serve as a vehicle for showing what's possible without actually changing much, if anything, about the rest of the environment. It's actually potentially doable. I have an understanding how to do it. I can just sit down and start doing it, unlike the rest of the general plan. And once this is actually done? That's when we'll have something to point to from which to go try to fix everything else. Or something. Long story short, I want to totally redo the skinning system. Later. But should I just get rid of the mention of that, or try to make it clearer where I do want to go (BECAUSE HOLY CRAP WE NEED THIS SO BADLY), or what?

So whatever I do, each round needs some actually finished outcomes - could these be things like 'this set of features, to serve these needs' and 'general compatibility with and satisfaction on trial projects' and 'documentation as a general overview of what people need from skins such that developers on both sides (skin or stuff working with skins) can save blah hours of horrible redundant consternation down the road', and then following up with a new thing with 'moar features for this much wider list of more niche needs' and 'general compatibility with and satisfaction on all projects' and 'documentation of all the typical usages, plus the idiotic crap, what the crap is all this, VE went through this horror in order to even work, so let's make it so nobody ever has to do this again, sort of thing'...?

And, honestly, the fact of the matter is that plain research is the thing I am worst at, but it's also the thing we need the most. I just don't think I can split it up like how you say, because if I do try to do the research and only that, I'll just get stuck. I'm first and foremost a developer and designer, and so just as much as I want the research driving the development, I want to use that to drive the research in the first place. I want to be able to routinely go back to the code and apply my findings to in order to see how they interact with what I tend to consider reality. Or... something. Does that even make sense? Or seem reasonable as a way to more focus this? -— Isarra ༆ 02:45, 29 March 2017 (UTC)

@Mjohnson (WMF): Okay I did it. I changed all the things. I think. The budget seriously worries me, but is theoretically possible. Um. -— Isarra ༆ 10:27, 4 April 2017 (UTC)

Just to chime in here, as I've taken an interest in this project, particularly as it relates to LearnWiki: I am experiencing the pain of what happens when one significantly underestimates the amount of hours and quality of focus required to complete a project. I think that staging the project is a good idea. I don't know enough about skin development to offer more specific advice, but speaking in general I think the concept of developing a skin that is more suitable to editors' needs is a good one. I like Marti's suggestion about having a table of project phases, timelines, budgets, and outcomes. I realize that with engineering projects it's difficult to make accurate estimates, so I'd encourage everyone involved in this project including the Project Grants Committee to understand that the table would be more like a table of hopes and goals than a table of hard-and-fast promises. From a resource management perspective it's highly desirable to have deadlines and budgets, but surprises happen all the time in large-scale projects like this. This isn't an edit-a-thon or some other project which has costs and timelines that are much more predictable based on limited scope and prior edit-a-thons. --Pine^✉ 02:30, 29 March 2017 (UTC)

In my experience making a new skin from scratch generally takes about a month once you account for back and forth from the client to address whatever they want done specifically once it's mostly finished, but that's for much... smaller-scope things. Generally single sites and not wikifarms. Certainly not wikifarms with many diverse communities. (Last time I tried making a skin for one of those ended... badly and I'd rather not talk about it. But that was many years ago, and I've learned a lot since. I think this will go much better. Yes.)

And yeah, the table is a definite... thing I need to add. As soon as I actually have time to sort it all out (probably this weekend?). It'll probably need to be just as explicit, if not more, about the things I am absolutely not supposed to be doing, too, just so I don't totally wander off topic later... for instance, yes, an extension for infoboxes or whatever would be awesome. But totally out of scope. -— Isarra ༆ 02:57, 29 March 2017 (UTC)

That sounds reasonable to me. I think that outlining your intended scope of work in a table format would indeed be helpful, along with guesses for dates and budgets. Change is nearly inevitable -- perhaps, and likely, significant change -- but that table will provide a starting point for conversations as the project moves along. Getting projects built on time, on budget, and 100% compliant with specifications is one of those noble goals that is great in an ideal world but in practice can be more difficult than it sounds, and the more novel a project is the more risk is inherent. I guess what I'm trying to emphasize is that I think this is a relatively high risk project -- which is not to say that it shouldn't be done, but that people should be aware that if WMF is going to commit $48,000 to this, the outcomes are going to be more difficult to predict than if WMF was spending that same money on repeating a bunch of edit-a-thons that were successful last year. I think that this is a relatively high-risk but relatively high-potential project. One thing that might make me more comfortable with it is to ask for less than $48,000 up front but then to make it clear that what you're asking is only for one part of a larger project. This will enable some containment of the risk, both for you and for WMF. --Pine^✉ 07:00, 29 March 2017 (UTC)

@Pine: It's really not that high-risk. This is all stuff I've done before, the development aspects are solid, and the price I'm asking for is not exactly unusual in software (yes, it's a bit high for my region until you account for the fact that it's not a salary with benefits and as such all I get is the cash and I have to pay double taxes, but at that point it really is... actually it's a bit low, but it beats working on roll-your-own java interfaces). But it is true there haven't exactly been many software grants as yet, so we're not so familiar with that territory. Hopefully CK's horribly inaccurate prognostication won't be used against me here (BUT THAT WAS DOING LIKE 50 TOTALLY NEW THINGS, AND THIS ISN'T). -— Isarra ༆ 10:27, 4 April 2017 (UTC)

Questions from NickK

Hi @Isarra: and thank you very much for your proposal. As an active editor not very happy with Vector (and honestly not that much with Monobook either) I appreciate the proposal to make a new skin, it is high time. However, as a Project grants committee member, I have several questions regarding your proposal:

• You state that your goal is to implement this skin as a default one. How do you want to organise it, preferably without falling into a Superprotect trap? When do you expect to be able to implement it?
• What is you plan for community consultation? It is great that you want to know what others think of the new skin, but
• What do you want to do with the other skins (Vector, Monobook, ...)? Do you want them to continue to be maintained? If yes, how easy will it be to make various extensions compatible with all skins?
• Does your project rely on any involvement of the WMF staff?
• If your request happens to be partially funded (well, it is the biggest grant request in this round, thus this may happen), will you be still able to reach your goal?

Thank you in advance for your answers! — NickK (talk) 12:11, 11 April 2017 (UTC)

@NickK:

You state that your goal is to implement this skin as a default one Where did I say this? That's not the plan at all - this grant is about determining community needs regarding skins and developing a prototype (Timeless) to showcase how these needs can be addressed. While I would like for it to eventually become the default, whether or not Timeless is adopted will remain up to the communities, including the Foundation itself (it's also possible that it will not be, and instead will serve merely as the stepping stone to whatever comes next, but having done this work, that next thing will actually be something we can make). Even deployment in general is outside the scope of this grant - that is being handled separately and concurrently.

What is you plan for community consultation? I don't have a plan for this. I want the communities involved, not consulted. Everything about this project is about them, learning how they do things, what problems they face, what they want, and thus creating a product to address that. The communities I'll be working with primarily are of course but a subset of all of them, but as with the rest, what they eventually decide to do with the skin will be up to them, at least as far as I'm concerned (yes, they might even want it undeployed from their projects, and there is precedent for doing this with other extensions, too).

Vector, Monobook, ... Do you want them to continue to be maintained? Yes. As with all the other skins we also maintain in gerrit that are not deployed to the Wikimedia projects, these can and must be maintained and updated moving forward. Much of the technical aspects of this grant concern coming up with better backends for the skins themselves to interface with MediaWiki core (and other extensions), and while doing this myself (or as part of this grant, at least) is a out of scope, these changes will need to be propagated across all skins for them to be of any use moving forward.

Does your project rely on any involvement of the WMF staff? No.

If your request happens to be partially funded ... will you be still able to reach your goal? This is actually an issue on both sides - if I wind up getting another job for whatever reason, for example, I won't be able to put in the full-time as proposed, either. But this is something I believe we need, and I would like to be able to see it through, so I've put a fair amount of thought into how it could still happen, and I'd like to say yes, a partial version is possible, but not ideal. The end results would be... less. Essentially it'd happen by cutting the grant in half, or the like - research into only some the things; less complete documentation of relevant UX stuff (with perhaps as much documenting what needs documentation/research, as actual documented results); only some of the major features; and breaking bugfixes on the skin. Some things, such as gadgets, would likely not get looked into at all. Timeless would not be deemed a final product, though it would exist as a viable option for many usages. Underlying technical issues impacting skinning and especially extensions that need to hook into skins would likely not be addressed at all. Basically it would not be ideal, but it could still be... something. It's work that needs doing, either way. -— Isarra ༆ 14:56, 12 April 2017 (UTC)

@Isarra: Thank you for your answers, this makes it more clear for me. Three more questions:

• One of the measures of success is Stretch: a cross-project consensus to establish it as the new default, that's why I thought it is your goal. While I can understand this might not happen, in case of full funding, will Timeless be developed as a usable skin, perhaps as an optional or even on non-WMF MediaWiki farms, by the end of this grant period?
• It's great that you are planning to involve communities instead of merely consulting them, but what is your plan for this? More precisely, at which stages and what exactly will you ask for?
• Regarding partial funding, will it be a viable option if we proceed in the following way: 1) first stage with major research, documentation and features, 2) some form of consultation on whether Timeless should be implemented as a default skin or not, 3) second stage to complete the project if community supports implementation as a default skin? I am a bit uncomfortable with investing 100k$ in something that may end up being rejected, as this would be a rather costly failure. This is just my own idea and other committee members may disagree with it (in either way, by supporting full funding or completely rejecting funding) — NickK (talk) 15:46, 12 April 2017 (UTC)

@NickK:

• Regarding the measures of success, the 'outcomes' are all things beyond the scope of what I'm actually doing - these are things that are intended to happen as a result of the grant, but are ultimately in the hands of others to actually do. It's like having a goal of an event grant be to get people inspired by the event to actually come back and keep contributing - it won't actually be part of the grant itself for that to happen, but that you're ultimately intending for that to happen is part of why you're doing the event, and thus getting the grant, in the first place.

Whatever happens, though, Timeless will be a usable skin by the end of this - because it already is. It just doesn't do much, currently - it displays the page, it has the tools on it, it has basic responsiveness (which puts it slightly ahead of MonoBook and Vector). The problem is that 'slightly ahead of MonoBook and Vector' isn't really significant. In order to warrant a change, it needs to be developed into something that solves the problems currently experienced with the available skins, to something significantly ahead. And so it will be.

• As I stated in the proposal, the plan for the communities is to create hubs on the pilot projects, and issue general reports out to basically everyone relevant as things change. The hubs will serve as central locations for me to solicit stories about specific use cases (generally for whatever feature/item/whatever I'm working on at the time), as well as for users to provide feedback and bug reports, and as locations for general discussion both ways, not unlike what we did on the English Wikipedia for WikiProject X. Reports will go out to appropriate mailing lists/massmessage lists depending on what is being reported. Technical/documentation updates will probably all just go to wikitech-l. Things the different communities found, and status updates on the project in general, are more a thing for sending out on-wiki. Phabricator will also be used as a primary coordination platform, especially with other developers and more technically-minded contributors outside of the project. When it all happens depends on when there is anything new to report, or if too long by goes without anything to report, that nothing has changed may also prove worth reporting.
• ...will it be a viable option if we proceed in the following way... In a word: no. This project cannot be staged like that. Each part depends on the others to move forward - without being able to ground the research results in something that can be implemented, without being able to test out potential solutions, all I would be able to do in the initial investigation is document the status quo, a few weeks' worth of work at most. I would not be able to follow up with possible solutions, or delve into further investigations into specific, pertinent problems, because I wouldn't know which ones are higher-priority than the others. I couldn't even say what best practices should be for the existing stuff - without grounding the results in diverse implementation, we have no way to tell what will be robust moving forward. Basically, I need the research so I know what to develop. I need the development so I know what to follow up on with the research, and so I can prototype possible solutions and see what the communities make of them. And I need the communities to keep all of this on track through the entire thing.

This is very unlike the usual grants, I know, but I'm essentially a full product team, in one, doing a team project. I am the manager: hence I am proposing this, and trying to lay out the organisation and plan for the project in a sensible manner. I am the UX designer and researcher, which is where it will all begin. But I am also the developer, and the community liaison. In a team, these people are all working together, concurrently. You can't just split them apart and have each one go in order, and then pass everything off to the next and be done. It is the same with this.

• I am a bit uncomfortable with investing 100k$ in something that may end up being rejected, as this would be a rather costly failure. I disagree with this premise. There seems to be an outlook around Wikimedia that if a product fails, it was a waste, and thus it absolutely must not fail. But this causes more harm than good - you see it time and again, products are developed, fundamental problems arise, and yet these are not addressed, and so what is eventually deployed doesn't actually work, isn't scalable, doesn't solve the problem at hand, introduces far more problems than it solved. Flow, MediaViewer, MobileFrontend, PageTriage, among many others - these were all based on very real UX issues that needed to be resolved, but they turned out to be fundamentally flawed products. Flow, in particular, emphasises what I mean. It tried to do too much, went too far in a new direction, and failed. It, too, was not the first iteration of its type, formatted discussion, and yet it failed to take the lessons from its predecessor, LiquidThreads, because LiquidThreads too was deemed a failed product. And when it turned out that the direction it had taken, that the very nature of its data handling and structure and interface was at odds with the direction of MediaWiki itself, those working on it did not allow it to fail quickly. They were not able to step back and start over, now having a better idea what the correct approach would be. And thus Flow, today, is not used across the projects, and along with many usability, accessibility, and compatibility problems, it is in fact widely hated among the communities. We are discussing this here, now, in plain wikitext, because it ultimately failed even as a complete product. We do not have something else, something better, because it was not allowed to fail when the problems initially became clear. Even now, Flow still stands in the way of trying again, and the longer this goes on, the more hated it will become, and the less anyone will want to try to learn from what it actually did right, either.

It's okay for a product to fail. We need to let them fail, and take from the failure the lessons that will enable the next iteration to succeed, because even in the failure there will also be successes. That's what this project is about, and what we are investing 100k$ in: not Timeless as a product, but the process that will lead us to a solid product that addresses all these problems, which may or may not be Timeless itself. -— Isarra ༆ 03:50, 13 April 2017 (UTC)

@Isarra: Thank you, that all makes sense.

• On the first point, this is what is called impact here, and it is great if such things that are in the hands of others will happen
• Regarding grants and failures. It is not a typical grant indeed, and that is a part of the problem. And there are different failures. Basically I am ready to support investing 100 k$ in this project in one of the following cases:

  • Timeless is a skin supported by the community and implemented as a default skin. A new skin will be one of the major news of the year regarding Wikimedia projects, and it will be well worth even more than 100 k$.
  • Timeless is not supported by the community, but there are clear lessons learned from it and there are people willing to work on a new skin addressing these problems. This is a useful failure, as ultimately we will get a new skin.

  However, what I would not like is any of the following cases:

  • Timeless is a skin that is not supported by the community, but nobody understands what exactly the community wants. Community starts to hate any work related to new skins (like many people hate Flow). We are in a worse situation than before.
  • Timeless is a skin that is not supported by the community for some clearly identified reasons, there are lessons learned, but no one is planning to work on it.

• The reason why I thought about partial funding is exactly the Flow case. I am thinking of the model with some mid-point discussion to make sure we are moving the right way. This is basically about being able to step back if needed: if the community says they like Timeless and they want to go forward with it, you get full funding to finalise it; if the community hates it than we need to discuss how to start over, probably with a separate proposal and involving other people. I know it is not a very pleasant thing, but I would be glad if we would be able to come up with a solution like that — NickK (talk) 14:46, 13 April 2017 (UTC)

@NickK:

• #3 is essentially where we are now - we don't really know what a lot of the problems are or what people want, and there is a deep mistrust of skin and interface work, especially that done by the WMF. So that is exactly what the aim is to fix, here - learn what the problems are, show that it can be done right, and hopefully mend some of the perception around this work in general. Given that we have had success with this process already with WikiProject X, I have no doubt I can repeat this here.
• You're exactly right that we need to be able to step back - but this isn't like Flow. This isn't a totally new product, doing its own thing, with nothing else like it (not that Flow should have been as much as it was, either, but that's a separate argument). Skins are many, all doing much the same things, so their components are reusable between them. We wouldn't be starting over, if it came to it - we'd be making a new skin with all the code already developed for Timeless, resolving the design problems with a new layout. Depending on when this happens, it could even be done within this project without even missing a beat, or just as easily after.

(For scale: If I wanted to make a new skin now doing the same things Vector does, it'd take me a week, tops (nearly all of which would be coming up with a good design, and later yelling at the CSS/js/some random Schrödinger function in BaseTemplate), and it would be complete. This would be comparable, though probably with some added discussion in the middle about what sort of design people prefer.)

• Regarding partial funding, it's hard to say when things should be broken up. The development in particular will be an on-going process throughout all of it, adding pieces, testing potential solutions, documenting results/problems encountered. Like all already deployed products, issues will be resolved as they come up, even after the grant is over. A lot of this is because we already have the MVP - at this point it's a matter of making it more than that, and fixing all the stupid broken stuff because I think I actually did make Timeless in about a week... over a year ago.

Anyway, if we do need to break this grant up for whatever reason, having talked it over with some other folks, too, I do think one of the best approaches might be to start out with a very small research-only grant. The issue here is that the scope would be very limited - as I noted before, it would likely only be able to address the end-user situation and the issues I'd be able to look into would be largely limited to the status quo, with nothing about potential solutions or the like - but this could potentially still be a useful jumping off point. It would probably be about a month, the output of which is a report on the current situation regarding usage, which would require follow-up for further outcomes. But we shouldn't necessarily be ruling this out, either. -— Isarra ༆ 19:13, 14 April 2017 (UTC)

@Isarra: OK, thank you for your answers. You reasons are clear, although I am not sure about timing. If you do not get full funding now, the next date you will be able to get funding will be in December. It may make sense to do the research before, but waiting a few months after the research is made is probably not an ideal solution. In any case I understand your approach, and I have to think yet whether full or partial funding will be the best option. Thank you! — NickK (talk) 22:25, 14 April 2017 (UTC)

@NickK: Yeah, that gap is the main reason I don't want to stage it like that, and why I kind of ruled it out in the first place. But that doesn't mean it'd be impossible, or whatever, either. Thank you for taking the time to ask. -— Isarra ༆ 00:39, 15 April 2017 (UTC)

A question

Taking into account the complexity and importance of the problem, is the project grants program (limited by 100,000) the right vehicle to fund it? I mean should not WMF fund such a development directly as one of its core programs? Ruslik (talk) 18:25, 12 April 2017 (UTC)

@Ruslik0: You're right. This is exactly the sort of thing the WMF should be doing directly... the problem is, with all the history and the pain associated with skinning and the interface in general, the features forced upon the communities when they didn't even want them, and all the community mistrust fostered by all of this, I'm not sure the WMF can anymore. I mean, it's been seven years, and the closest we've seen to a new skin since Vector are MobileFrontend (which is only mobile and was basically just a workaround... for Vector), and a set of font updates (for Vector) that backfired catastrophically. There isn't even a dedicated team working on the interface at all. There are no internal plans for anything of the sort. As important as the problem is, nothing's happening with it, because it's still just too risky to try. Many in the communities will fight it at every turn because they remember what happened with all the other WMF projects that have gone wrong, and as bad as Vector is, it at least works as well as it works.

But I'm not WMF. I'm not associated with all the failures, and so users tend to have a much more open mind when I show up and ask, 'yo, here's this thing, what do you think, how do we make it better, how do you use it?' And then I do exactly what a good WMF team would do anyway. I've worked with some of these folks, after all. Learned quite a bit off them.

So yeah, this is probably not really the right vehicle, but I think it's our best option. (Bear in mind that the direction the WMF is going, with management practices and community engagement improving, in another few years I could see them being able to much more easily pull this sort of thing off directly. I just don't want to wait a few more years. Been too long already.) -— Isarra ༆ 04:30, 13 April 2017 (UTC)

Some feedbacky questions

Hi Isarrra, am really excited about a new skin with many of these design elements! I just want to note and hear your thoughts on some thoughts I have:

• Given what I have heard about rolling out vector and the failure of the Winter project, I am concerned that this skin will have trouble launching without more resourcing than what this project is asking for. What have we learned from either of those projects that will make this different?
• On a related note, this project seems to me like it might require WMF support, whether it is design reviews, code reviews or other. Do you have a sense for what or how much that would be?
• Making the skin system easier to work with feels like an unassailable goal. I wonder if perhaps starting here as a stage 1 would make sense rather than tying this work to the outcome of a potentially contentious design rollout.

Thanks! Jkatz (WMF) (talk) 20:17, 13 April 2017 (UTC)

@Jkatz (WMF):

• Vector, I think, exemplifies its time. It was created as part of the Wikipedia Usability Initiative, a grant-funded project of which I think one of the main failings was that they didn't know what, specifically, they were actually trying to do. They knew there were problems. They knew there was a divide between readers and editors, despite editors being former readers themselves. And yet I'd say they went about the solution backwards - they focussed exclusively on the readers, they hired out to design and usability firms, did studies, interviews. They found many problem areas, it's true, but they didn't find connections, how these areas related between the readers and editors, or to each other, or across the interface as a whole. Paradoxically, throughout the entire process, they ignored the very same group they were trying to make more of - editors. When it came time to make the skin and other phase I tools (acai), they were apparently simply implemented and deployed. The existing users, the editors, were given the choice to enable many of these features, or not, but they weren't really involved in the process of actually making them.

And then the project kept going. There were, after all, two more phases remaining. But phases to what? What were they actually trying to do? I don't know. The research was never completed, the tools never deployed. Today, some extensions remain. Third-party sysadmins find some extra options during installation: tabs for previewing vs editing. And only after the fact was it all wrapped up into a specific skin, specific features, specific extensions.

I like to think we're a lot better at this stuff now. MediaWiki itself is a lot easier to work with, and skins in particular get a level of support that would have been incomprehensible at the time. The culture with regards to development and design focus has shifted considerably since 2009 as well: there's more acceptance that editors are just as important as readers, and that they might know what their own problems are. And their problems are often the most important of all - whatever is slowing down the experienced users is likely to be far, far worse for anyone new to it. So start there. Begin with the users as opposed to ending at them.

The Usability Initiative had tremendous resources, but it didn't really produce a whole lot... if you only look at the software that came out of it, if you don't consider the landscape of the existing codebase and UX. It was a step toward where we are now, and all the things that went wrong show us how to do things more right, even if the lessons were unfortunately not learned for years in the interim. It's because of this and the other projects since, though, that I don't need the same resources to go considerably further. We know better how to do our own research. The architecture supporting skins is vastly improved. Extensions are far saner and more modular. We know where to start, and where to end.

• I wouldn't say Winter failed so much as just... got forgotten. It was never intended to be a skin of its own - it was more a testing ground to try out various interface ideas, some of which were ported back to Vector and various extensions and gadgets. That many of these didn't ultimately work out was a separate problem, and in a lot of cases, I think says more about the people involved than what they were actually trying to do. Bear in mind that this was all during times of significant internal problems, and eventually great upheaval, at the WMF - there was great pressure to modernise, make features, produce. Teams were being reorganised, projects were being started up and shuffled about and forgotten all over the place. Management was a mess, and many developers and designers alike wound up on projects, or with other people, that they were simply not suited to handle.

But I hear all that is over, at least, which is good.

• Design review: Nirzar is doing that now. Security review has already been completed. That's really about it, I think - only thing really blocking production deployment left is community consensus, I think, and we even have that on several projects. (Well, that, and the fact that I apparently broke it on the betacluster, but, er, I'll sort that out later. Something something deployments.) Code review in general can be handled by anyone with access, and Jack Phoenix has already committed to doing this, but I know a few others who are happy to help as well.
• Making the skinning system easier isn't really a direct goal of this, because you're right, it's a huge problem. But it is something we can work on, or at least move toward. Having more well-architected skins in general helps, even, as it establishes common practices that we can use to abstract away the complexities from the skins themselves. As an example of something we've done already: https://gerrit.wikimedia.org/r/#/c/344804/ These functions came from Timeless, but we added them to core because they can benefit all skins, just as soon as they start using them. There's no point for every single skin to have the exact same footer code in it, after all, when they're all extending the same parent class. -— Isarra ༆ 22:24, 14 April 2017 (UTC)

A bit of my own perspective here about how Winter was forgotten...

Brandon's communication about Winter in 2014 was presenting it as very much the future. Near future, even. In the same year the Wikimedia Language engineering team, where I am the product manager, first deployed Compact Language Links as a beta feature. Despite rather positive response, I was delaying wider deployment as non-beta because Winter was supposed to have a similar feature, and I didn't want to collide with that.

And than Brandon was suddenly gone, and all work on Winter ceased. I kept remembering it because its presentation of interlanguage links was particularly important to me, but after it became clear that Winter is probably not being re-adopted by anybody, we decided to start gradually deploying the Compact Language Links feature as non-beta by itself, without waiting for other developments.

So at least there's one good thing: now Timeless essentially has this feature out of the box without (almost) any further development.

I'm not sure why wasn't anybody else as interested in Winter as I was. I already wrote several times that it has brilliant and much-needed features, other than the presentation of the interlanguage links: the persistent top bar, the mobile friendliness, etc., and I'm happy to repeat it as many times as needed.

As a piece of user interaction design, Vector was not much of a departure from Monobook. Vector did contribute a lot to the world of MediaWiki technology; as far as I recall, technologies like CSSJanus and ResourceLoader were created as part of Vector development, and MediaWiki is unthinkable without them now.

Is it time for an actual user interaction redesign? Of course it is. Monobook started around 2004; Vector started in 2010, and it was hardly different; more time has passed from Vector till now than from Monobook to Vector. The web has changed since 2004, and so has Wikipedia.

Let's be bold and support this. --Amir E. Aharoni (talk) 14:31, 26 May 2017 (UTC)

Research and Scope

I'm really excited to see this being worked on. Taking a serious look at the skin system and our branding issues is long overdue. Thank you for heading in this direction.

My first concern is about the lack of current and planned research. The summary makes research sound like a prominent component of this proposal, but there is nearly no information about the research plan, and most of the information provided about the development work suggests there are few if any open questions that will steer the work. Given there's already a working prototype, I suspect there would need to be an especially clear signal from any research conducted, for you to change course. In the introductory paragraph, it identifies that there's little research about what problems even exist. Could this be refocused and sequenced to place research first, then identify the problems based on the findings, then assess the high value changes that could be made and finally begin working on actual code changes? I'm concerned when I see that security review is being considered at such an early stage, given how little evidence we have that this particular design or implementation solves the problems we also don't yet understand.

I'm also concerned about the scope, having personally designed and authored the Vector skin, I can assure you that the level complexity here is likely being underestimated. Assuming the design and engineering work is solid, there's an enormous amount of work to build community support, transition community tools and respond to issues as they are found during the first year of deployment. MobileFrontend was able to bypass the community aspects, and still took an enormous effort. Vector was a much larger effort because we did not cut those corners, and took a team a couple of years to fully deploy and stabilize. It would be better to identify smaller parts of the larger problem and invest time in doing a really excellent job, paving the way for the next steps. Monobook and Vector were active as the default skin for about 8 years each. The next change in this area will be with us for quite some time, let's be sure we are on steady footing as we proceed. Trevor Parscal (WMF) (talk) 15:33, 25 May 2017 (UTC)

Round 1 2017 decision

This project has not been selected for a Project Grant at this time.

We love that you took the chance to creatively improve the Wikimedia movement. The committee has reviewed this proposal and not recommended it for funding. This was a very competitive round with many good ideas, not all of which could be funded in spite of many merits. We appreciate your participation, and we hope you'll continue to stay engaged in the Wikimedia context.

Comments regarding this decision:
Though the committee was very supportive of the concept of innovation in skins and expressed confidence in many skills the applicant offers, there were significant concerns about whether the substantial scope of work necessary for success could be accomplished within the limited scale of a project grant. Consultations with WMF technical staff repeatedly suggested that such an ambitious project would likely take multiple rounds of funding and demand widely varying skills that can typically only be convened through the collective contributions of a team of people. Many concerns were raised about long-term sustainability. There was wide interest in supporting preliminary research about community needs with respect to skins. However, given a lack of a well-developed research plan with specific ideas about appropriate methodologies, this proposal is not yet ready to be funded as a research-only project.

Next steps: Applicants whose proposals are declined are welcome to consider resubmitting your application again in the future. You are welcome to request a consultation with staff to review any concerns with your proposal that contributed to a decline decision, and help you determine whether resubmission makes sense for your proposal.

Over the last year, the Wikimedia Foundation has been undergoing a community consultation process to launch a new grants strategy. Our proposed programs are posted on Meta here: Grants Strategy Relaunch 2020-2021. If you have suggestions about how we can improve our programs in the future, you can find information about how to give feedback here: Get involved. We are also currently seeking candidates to serve on regional grants committees and we'd appreciate it if you could help us spread the word to strong candidates--you can find out more here. We will launch our new programs in July 2021. If you are interested in submitting future proposals for funding, stay tuned to learn more about our future programs.

Aggregated feedback from the committee for Timeless

Scoring rubric	Score
(A) Impact potential Does it have the potential to increase gender diversity in Wikimedia projects, either in terms of content, contributors, or both? Does it have the potential for online impact? Can it be sustained, scaled, or adapted elsewhere after the grant ends?	7.6
(B) Community engagement Does it have a specific target community and plan to engage it often? Does it have community support?	6.8
(C) Ability to execute Can the scope be accomplished in the proposed timeframe? Is the budget realistic/efficient ? Do the participants have the necessary skills/experience?	6.0
(D) Measures of success Are there both quantitative and qualitative measures of success? Are they realistic? Can they be measured?	6.4
Additional comments from the Committee: Isn't a priority, but a new skin for Wikipedia could have a great online impact. Not clear impact compared with the cost. It undoubtedly fits with Wikimedia's strategic priorities and if successful will have a huge online impact. Though its sustainability will probably require direct WMF involvement. Great project aimed at accessibility of our site and attraction of editors from mobile devices; some developers have already shown interest in the endorsement section -- that's why I believe in its sustainability. The impact of a new skin will be very significant. An immediately visible change that should have an impact on retaining readers that can currently opt for other platforms such as Wikiwand. The project is iterative as it builds on the previous work to design this skin. The risks are significant but the potential impact is also very large! The success can be easily measured. The idea is not new and the problems are already known quite well but as the problem isn't solved yet, I still evaluate it on a high level. Innovative and good at learning, but risks are high and impact is hardly measurable unless this skin is implemented as default. I have some doubts about the time needed to develop and test the new skin, so the mixture in unit time (days/hour) doesn't help to understand the importance of the task. (Yes, it's aggregate.) I don't see any mention of whether there is a team interested to develop the new skin. The answer to this question is that it depends. The work is probably not simple but it can be reasonably completed in 12 months. The budget is at the upper limit for the project grants, but it seems to be realistic. The necessary experience/skills seem to be present. Maybe Isarra is the best volunteer developer for this project. (He already has good experience, support, etc.) But I don't believe that a volunteer could handle that: this should be performed as part of core activities of WMF, not by a volunteer project. The engine is constantly developed by volunteers and paid employees and volunteer Isarra won't be able to cope with the speed of changes, so, the skin will always be in a 'beta' stage or outdated. It can realistically be done in 12 months, and Isarra seems to be skilled enough for this. The budget is a bit high, but Project grants might not be the best way for getting funding for this. It has a large endorsement base... well, we need a new skin, everyone love a new skin ;) There is a considerable community interest in this project. Good community support, including some projects willing to test. I suggest reduce the amount of "eventual costs" to a 10% of the subtotal costs (8750 USD), not 12k to round the numbers. I understand the "wtf" line item, but the reserves amount could cover any new cost related with more time to cover. Lots of strengths in this proposal including a previous grantee with relevant expertise; lots of community support/interest in the work (I believe more than for any other project I’ve seen this round); and good potential for innovation and learning. Despite support from Wikimedians and WMF staff I would however like to see an argument for how this serves the larger movement and aligns with strategic priorities. Other than that, the big question seems to be whether to support this in full or to support an initial stage of the work. As per discussions on the talk page, the applicant seems to think that it will be difficult to separate research from development; I understand that but am also not comfortable with committing so much money (and so much of the Project Grants budget) to one project being lead by one person. There’s too much risk there in my opinion. I therefore recommend prioritizing the research component and scaling back to 6 months...OR trying to see if WMF will cost-share the entire project and/or dedicate staff or other resources to it. I think it’s also necessary to have a strong advisor attached to this project, with strong software research skills. Strong yes, but only meet budget for Software development ($43,500). I'm concerned about the amount of money required and I'm concerned that the community outreach portion may be underestimated. I'm thinking about past major UI efforts and how they ended up. However, since this is on Beta first and communication is being done on Commons and Wikisource, as well as Issara's membership in the development community, I see good things here. I love that this skin is finally responsive. With the limited resources available, I'm applying a just allocation rationale for this and asking that Issara share the cost. I am willing to support this project but I want to note that such development work should be probably funded directly by WMF as one of its core programs. If allowed to proceed the project will need a close supervision by WMF technical staff. The problem exists, the idea is great and the grantee is perfect but it shouldn't be funded as PEG, it should be financed as a core activity of WMF: probably, it's better even to hire Isaara for this project if WMF isn't able to do it themselves. Just one note (out of many I have for this grant request) : in budget there is a line for "Arguing with people". I haven't see this before. Very, very big budget for something that lacks significant community conversation in background of it. I would like to see better global community involvement. This is a very good, but very expensive project. It is a victim of Project grants being awarded just twice a year now - the first stage (research) is too short and the second (implementation) is too long, hard to fit into 6-month schedule without wasting time. There are many good ideas on the talk page, maybe we can find some tailored solution for this.