Grants talk:Project/Putnik/Wikidata module

Name of the module(s)

I want to improve and partially rewrite Lua module that was originally created for the Russian Wikipedia, and now it is used in 17 more Wikipedias.

Can you give the links to the current modules which you are planning to rewrite in this proposal? --Zache (talk) 09:55, 3 August 2016 (UTC)

Please see the section below, I have listed them there. — putnik 12:33, 3 August 2016 (UTC)

More info about the proposed modifications

Hi, good initiative, but Wikidata integration in WP is a difficult topic for some WPs. Perhaps it is good to provide the list of current lua modules in WP:ru which are concerned and their respective use. Then a second list for the features which will provided by the new lua modules.

If the intention is to provide an international module, a better explanation of the future architecture of the new modules with their capabilities is necessary. Without that information the risk is high to see the new modules to be an updated version of the Russian module focused on the demand of WP:ru. Snipre (talk) 10:11, 3 August 2016 (UTC)

• Thanks for the comment. It's really a good idea to describe current and future structure at the proposal page. I do this in more detail later, and now just briefly draft. There are some required pages now:
  • w:ru:Template:Wikidata - friendly wrapper for users
  • w:ru:Module:Wikidata - main module
  • w:ru:Module:WikidataSelectors - module for filtering, should be optional
  • w:ru:Module:Source - module for references, should be optional

This 4 pages is enough to work with this types: coordinates (requires {{coord}}), quantity (without unit), string, monolingualtext (requires {{lang-xx}}/{{ref-xx}}) and commonsMedia.

Also there are many modules for special cases:

• w:ru:Module:Wikidata/Places - shows chain of administrative units for places of birth and death and adds categories
• w:ru:Module:Wikidata/date - for dates of birth and death, shows age and adds categories
• w:ru:Module:Wikidata/link - for identifies
• w:ru:Module:Wikidata/media - was for images, and now for P373 only
• w:ru:Module:Wikidata/number
• w:ru:Module:Wikidata/Software
• w:ru:Module:Wikidata/Medals
• w:ru:Module:Wikidata/Countries
• w:ru:Module:Wikidata/Biology
• etc

And you need to create special templates like w:ru:Template:Wikidata/p19 to use it.

The idea is to

• make it works with Template:Wikidata + Module:Wikidata + Module:Wikidata/config pages only;
• add good support of quantities, identifies, Commons link, etc inside the main module;
• allow to set custom formatters for properties at /config page and remove all {{wikidata/*}} templates;

For end user it will be only {{wikidata}} template that can be used inside infobox templates and shows nicely formatted values from Wikidata. Or module can be integrated into infoboxes directly (like wikidataN = P123 in this template). So basic functionality will be suitable for all wikis, and you can create any extension and allow it using config page for your wiki if you want. I think that most extensions will be the same for all wikis, so Russian Wikipedia extensions will be ok for everybody (maybe with some changes). I definitely want to make it international, so I will focus on the requirements of all wikis. — putnik 12:32, 3 August 2016 (UTC)

@Putnik:

• I am sorry but I think this implementation is very clunky and inelegant -- not a step in the right direction

Concerns

• Completely removes the element = value relationship
• Adds Wikidata numbers, which are quite frankly, useless to the casual editor
• To move backwards and have a sequentially numbered list of element relationships, I would rather have the Infobox templates
• There seems no value add to this proposal in terms of translating the potenitally massive number of elements of Infobox values this way
• If this was a form like with the Cite RefToolbar (see image at right, but disregard lookup notations) I would understand the benefit, but to have this sequential list like this, with masses of ###, it's just not worth it in my opinion

• Also -- the worst part is that this iteration of the project is a depreciation (No!!!!) of the Infobox to where? To Wikidata? So this will be just like the Authority Control. Only Wikipedia end-users will be extremely unhappy with this because I think most people know how to update a Wikipedia Infobox, but suspect it would become problematic to do so for the large number of infobox elements transported to the Wikidata page for this entry.
• So yeah, I think this solution needs to be reworked. I'm sorry. -- Erika aka 01:26, 4 August 2016 (UTC)

@BrillLyle: You see this module as a silver bullet that can simultaneously solve the problem of using, editing, and data transfer to Wikidata. But it is not. I offer it as only a solution to the problem of using an information from Wikidata. Yes, we definitely need convenient tools for editing Wikidata directly from Wikipedia. Perhaps many projects decide that without such tools, they do not want to integrate Wikidata. But I still think this is a separate problem, and we need to eat an elephant a bite at a time. — putnik 07:57, 4 August 2016 (UTC)

Comments (#1)

• While this is in theory an advance, there needs to be a really good case made for adoption before we even consider the possibility of deploying this to enwiki, or we will risk repeating the VisualEditor fiasco. Documenting the progress made so far, and engaging with the enwiki community early on would be a very good start: can we see evidence that this makes contributing and editing templates easier for both naive and power users? -- The Anome (talk) 12:26, 3 August 2016 (UTC)

@Jura1 and Putnik: Meta-comment: I am absolutely amazed that this comment got moved here, and, after some investigation of why, by the fact that this process allows only for "endorsements" on the proposal page, and not negative or, in the case above, merely cautionary comments. Is there some form of community discussion which follows this which might allow community feedback, or is there a simple presumption in favor of proposals being granted as-is, without any feedback that might improve them? In my opinion, funding something that will only be kicked back by the community, and then imposing it on the community on the basis that the work's been done, and now must be followed through with, is the wrong way to do it. Perhaps this proposal should be broken into two stages: the first to do detailed design work and documentation and to get community buy-in for the concept, and the second to implement it, conditional on that support?

Please don't get me wrong, this is an excellent proposal on the face of it, but I think it needs to be implemented with great care, and that means getting community buy-in before deployment. -- The Anome (talk) 13:22, 3 August 2016 (UTC)

As far as I'm aware, it's the format of these proposals. Talk pages are read by those reviewing them. --Jura1 (talk) 13:36, 3 August 2016 (UTC)

The Anome I confirm that the format of these grant reviews makes it difficult to post criticism or ask questions anywhere except on the talk page. I will not defend the grant discussion process, but I will say that if this comment was moved in this case, that is because of something that routinely happens with grant discussions and not something that happened only for this one. I also would like the conversation format for grants redesigned or discussed. Blue Rasberry (talk) 14:14, 3 August 2016 (UTC)

Just wanting to note that substantive comments are moved to the talkpage to encourage more discussion and input to inform decisionmaking about funding proposals. The discussion on the talkpage is a greater, not lesser, focus of review for funding decisions and we seek as much input as we can get for that reason --Marti (WMF) (talk) 18:00, 20 September 2016 (UTC)

• To address the point by The Anome, I'm not sure if enwiki is the wiki that most needs it. It's more likely to be of use to smaller Wikis that struggle to set up infoboxes that make use of Wikidata (sample: taxobox on cywiki) and keep them running. --Jura1 (talk) 13:36, 3 August 2016 (UTC)
  • enwiki certainly isn't the place that needs it most, but once this is rolled out in other wikis, it will inevitably end up being deployed on enwiki, one way or another. If we get the problems out of the way now by discussing them at the very early stages of this project, that process could be painless. If not, it could end up with conflict between the WMF and the community, as it did with the VisualEditor deployment. Let's learn from that history, and engage with the community up front. -- The Anome (talk) 21:16, 3 August 2016 (UTC)
• @The Anome: This module is not a solution that will force added to each project. It's just a tool that will make the integration of Wikidata to the project much easier if the community decides to do so. All that I plan to do this tool and show how it can be used. The final decision has to take each project community. — putnik 00:03, 4 August 2016 (UTC)
  • @Putnik: Hi -- please understand that I fully support the integration of Wikidata with templates throughout Wikipedia, and I broadly support the general ideas behind your project. However, past experience shows that technological solutions tend to take on a momentum of their own, and end up being enforced on communities whether they like it or not. All I'm asking is that you make community engagement your first priority, and come up with something that satisfies communities such as enwiki and dewiki, before you start coding your solution. Thanks for answering the questions below: this is a good start. -- The Anome (talk) 09:10, 4 August 2016 (UTC)
    • @The Anome: Thank you for your comments. I understand your position and I remember the situation with the MediaViewer. Specifically, this project I started doing two years ago, and now I want to finish it, not to start. If everything will turn out exactly as I planned, it is possible then next I'll create an interface for editing (or someone else will). I do not believe that in six months it will be possible to integrate it in the English Wikipedia, but for smaller Wikipedias it will be the good working solution. Perhaps, for the major projects, it would be acceptable only in a pair with the editing tool. It seems to me that there is nothing wrong if the English Wikipedia will integrate Wikidata in a year or two. — putnik 13:34, 4 August 2016 (UTC)

Banon (fromage infobox)

• A month ago i compared some different wikidata implementations for fiwiki and in that context i would like to ask why to use ru:module:wikidata and not in example module like fr:module:wikidata for generic implementation (for smaller wikis)? Frwiki implementaton seemed to be pretty good as viewed from template coder point of view (usage: fr:template:wikidata and fr:Projet:Wikidata/Atelier/Manuel) and with the frwiki implementation there is option to move the infobox code from template to lua (example: fr:Modèle:Infobox Équipe cycliste and fr:Module:Infobox/Équipe cycliste). I also copied it from frwiki to fiwiki and it wasnt too bad in localisation point view but there was lot of files. ( list of copied stuff)--Zache (talk) 17:35, 4 August 2016 (UTC)

• • @Putnik: after sleeping over night i think that what i was trying to ask is that if you are getting the grant then why to rewrite/refactor the ru:module:wikidata and not switch ruwiki to use fr:module:wikidata as next version of wikidata module? Currently ru:module:wikidata seems to be in par with wikidata module in enwiki, dewiki, eswiki, svwiki etc.. but even with moderate refactor it is not reason for those to switch to use ruwiki's version. However the frwiki is one step ahead so it could be reason to switch to frwiki module. Also they have least some integration for editing the wikidata values from infobox (see screenshot, Banon). Third thing is that in frwiki infobox configuration can be defined via lua code as an hash so it can be read as JSON too (example) which is step towards to visual editor support. --Zache (talk) 07:53, 5 August 2016 (UTC)
    • @Zache: Not so easy to take an unfamiliar code and rewrite it in a reasonable time to reach the desired goal. The French module is very powerful, but it has a lot (really a lot) dependencies on other modules. I think it will be very difficult to port to other projects. But I think it's possible to take some good parts of it.
      The idea of editing icons is very good. In the Russian Wikipedia we have gadget that adds these links, but it can be done right in the module code. The bottom links is not directly related to the Wikidata module, it is more a social decision on how to make editing of Wikidata more intuitive for the end user. — putnik 10:12, 5 August 2016 (UTC)
      • @Putnik: There is lot of dependencies, but nice thing is that least stuff which are related to fr:module:wikidata and fr:module:Interface Wikidata can be copied to another wiki mostly without code changes. Here is list of changes which i did when i copied modules from frwiki to fiwiki. I prefixed everything from frwiki under :fr: because there was already wikidata-module in use. Other stuff was mostly text translations, units and date formations. What is needed for frwiki's wikidata module if we want it to be portable also in non-francophile world is moving the rest of the visible texts to their own modules so that code modules can be copied (and updated) to different wikis without changes. Also date formatting will need to be something which can be configured more easily. Also one big thing is also writing tests, documentation and examples. --Zache (talk) 12:20, 5 August 2016 (UTC)
      • @Putnik: I made some testing what it would need to get infoboxes working too. (See fi:Reblochon in fiwiki) Here is list of copied modules and changes what i made to frwikis modules when i copied them. Based on that i would say that it is not very difficult to port to another wiki. It is just lot of modules, but getting it to work on another wiki is pretty straightforward. --Zache (talk) 17:30, 6 August 2016 (UTC)
      • And thinking this even further. I put the dependencies of the frwiki's wikidata access to halfviz (just for wikidata access, no infoboxes). Colors for modules are, red are modules with needing changes (most likely french or frwiki related stuff), blues are modules used for translations/configurations and greens are code modules which doesn't need changes if they are copied to the another wiki (eg. they doesn't have any language specific texts etc). The big source of red modules is support for references which are used from single entrypoint which is module:wikidata.getReferences() so those modules can be removed easily. Second problematic thing is Module:Date_complexe which needs to be configurable. Luckily after dropping the reference support date complexe is now used only from module:wikidata so date formatting can be dropped easily for rewriting too. And looking dependencies after dropping the reference support and date formatting we can see that it looks now much simpler. --Zache (talk) 12:46, 7 August 2016 (UTC)
        • @Zache: Do I understand your position right (please correct if not)? You really like the French module, and if I will successfully rewrite Russian one, then we will lose the features made in the French Wikipedia already. I'm right? If so, then I agree with you that it is bad. But I still think that we need some basic (core) module, which can be copied into any project without dependencies. In process of its development, I really need to look at all the projects that are already actively using Wikidata (not only on the Russian Wikipedia) and communicate a lot with the authors of modules. Then, after the end of the development, we will be able to rewrite the local modules in such a way that they will extend the main module, without losing the old functionality, but without the dependencies inside the main module. — putnik 10:47, 8 August 2016 (UTC)
          • @Putnik: Yes to the first. I think that frwikis module is currently best implementation so far. For the second no. If you rewrite ruwikis module then i hope that it is successful and it is so good that it can be used for replacing the frwikis wikidata module other wikis modules too so that we have one compatible implementation which is used in multiple wikis. What i fear is that even well made core module is not enough for replacing the current implementations. Second thing is that current wikidata derived implementations problem is not the installation but that they are inconvenient to use. Missing features are correct plurals for units, rounding, unit conversions, removing duplicates from lists etc... Those things aren't needed for core implementation but they are needed for that the implementation is good enough to make the difference and that is where frwikis implementation is different compared to other wikidata derived modules. --Zache (talk) 16:15, 8 August 2016 (UTC)

References

To which degree are references in Wikidata supported(/will be supported) by the present and the suggested module? — Finn Årup Nielsen (fnielsen) (talk) 14:56, 3 August 2016 (UTC)

• @Fnielsen: Great question and yikes. Infoboxes sometimes include references, so what would happen. I've gotten yelled at on Wikipedia for adding citations to infoboxes, but they are sometimes necessary. Would like a very careful consideration and response to this question -- Erika aka BrillLyle (talk) 17:37, 3 August 2016 (UTC)
  • This could just be a template parameter that further instructs the Lua code to include it or not. {{Wikidata|P184|references=yes}}. Whether people on the individual Wikipedias wants references in infoboxes is not a question for the Lua module (other than what should be the default). — Finn Årup Nielsen (fnielsen) (talk) 17:50, 3 August 2016 (UTC)
    • So it's sort of like a switch option to turn on and off references? What happens to the associated data on English Wikipedia? Does the [#] element attach seamlessly? Where does the citation information go if it is the first instance of the citation? -- Erika aka BrillLyle (talk) 18:00, 3 August 2016 (UTC)
• @Fnielsen: I think there are several problems. And there must be some settings, the default values of which is dependent on the choice of the community. First, whether to display all values ​or just only values with sources (now it shows all). Secondly, what sources considered reliable and which are not (now it works, but needs some work). Thirdly, should we show a ref link or not (and it should be properly displayed in the list of references; now it works but needs some work for internalization). And, fourthly, all these default values ​​should be possible to override (now this doesn't work​). All this I plan to do. — putnik 22:41, 3 August 2016 (UTC)

Additional information request and concerns

Summary: I Endorse strongly oppose this proposal but more information needs to be provided and there should be assurances there is buy-in and care taken to address needs of both Wikidata community as well as English Wikipedia specifically. Without those, oppose. I weakly support if this is going to happen no matter what, as I believe in the semantic power of Wikidata and want Wikipedia to be better for it's connections and implementations of Wikidata., but grave concerns.... I suspect and recommend that this project be might benefit with an additional person, part time volunteer?, who could do end-user issues and address integration with Wikipedia / existing infobox templates on Wikipedia :-)

1. Responses to Grant proposal as written

• Budget
  • Hourly rate translates to USD$11.54 per hour. Is this typical? It seems very low for technical work
  • Also the rate should incorporate a 4.3 weeks per month so the total amount should be adjusted as well, I think
• Community notification
  • Why does the community notification not include English Wikipedia among other large Wikis?!? This is a big problem. It should be FIRST on the list
• Grant funding = implementation?
  • Funding this grant, does it mean automatic endorsement and implementation on English Wikipedia? Please discuss

2. Additional information request

• Examples of implementation
  • Please provide a number of examples of implementation from the Russian Wikipedia, and discuss how this implementation was done, and more importantly how the community responded -- both from the perspective of Wikipedia editors as well as from the perspective of Wikidata editors
  • How do you plan to roll out this project, and will you do a beta test, have focus groups, etc.? Please explain
• Example of population
  • How does an Infobox populate on Wikidata from Wikipedia? This might be the same as questions below
  • Issue: What is the point of Wikipedia editors using these great templates in English Wikipedia when there is no effort by Wikidata to create pathways and integrate existing Wikipedia templates into the semantics of Wikidata?

3. Concerns

• Depreciation on Wikipedia
  • Does this project implement Infoboxes so that they are only editable on Wikidata, or would Infoboxes continue to be editable on Wikipedia? This is the biggest issue and problem I have with what I see as a similar concern with what happened with the Authority Control template depreciation to Wikidata. There was an assumption and expectation that editors would not mind editing on Wikidata, and there was no effort made to make the editing happen on Wikipedia that I know of. This is a huge problem, my biggest fear and concern. Please address
• Visual Editor
  • On Wikidata: When Visual Editor is discussed I think the implied expectation is that the editing will be done using Visual Editor on Wikidata? Please clarify
  • On Wikipedia: Is the assumption that this implementation will be edited only by those editors using Visual Editor on Wikipedia? If implemented it must be usable for Visual Editor end-users as well as Wiki Markup end-users on Wikipedia. This is non-negotiable, mandatory
• Infobox templates
  • Will all (or any?) Wikipedia Infobox templates be integrated into this project?
  • Assume the "main" Infobox template will have all elements incorporated in this module, but please confirm this is true
    • See Wikipedia List of infoboxes
    • If so, will all elements transfer over in pathways to Wikidata? There needs to be no loss of data -- or functionality -- from the Wikipedia side going to Wikidata (and vice versa). Looking for 100% interoperability between Wikipedia and Wikidata (and vice versa). This is mandatory

• End-user needs
  • How will Wikipedia editors have their needs met, especially the casual editor who wants to add an Infobox or update an existing Infobox?
  • Will there be beta testing?
  • What documentation will be made available to Wikidata editors and to Wikipedia editors?
• User Interface
  • What will the interface on Wikipedia look like for the Wikipedia Visual Editor user and the Wikipedia Wiki Markup User?
    • Ideally, for the Wiki Markup user specifically, it should look the same as the existing Cite RefToolbar interface, with the summary and expanded options of the form
  • Ideally, the casual Wikipedia editor would not even need to know the Wikidata backbone underpinning the info, if this were to be implemented correctly

-- Revised Endorsement I will add more as I can. I appreciate the amount of effort and energy this proposal will take -- and it is obviously very needed. If it can be implemented well, I would be very grateful to be able to use it. Thanks in advance. -- Erika aka BrillLyle (talk) 17:26, 3 August 2016 (UTC)

That's a great set of questions. I'd really be interested to know the answers to them. As Erika says, I'd really like to be able to endorse and use the results of this project, provided that it can be planned and implemented in a way that does not annoy the existing editing community. In particular, I'd just like to echo her comment that "If implemented it must be usable for Visual Editor end-users as well as Wiki Markup end-users on Wikipedia. This is non-negotiable, mandatory." -- The Anome (talk) 21:17, 3 August 2016 (UTC)

• 1.
  • Budget: This is a good programmer salary for Moscow, so require a large amount of it does not seem correct.
  • Community notification: First of all, I informed the communities which are already familiar with this module. Now after adding the information that will clarify the situation for those who have not seen this module work, I will notify the other large communities.
  • Implementation: This module will be a ready-to-use tool for Wikidata integration into a project. Whether to do it and do it with what settings will remain the decision of a particular community.
• 2.
  • Examples of implementation: I added screenshots of one example, which uses only Wikidata. In the Russian Wikipedia, the module is used probably in all infoboxes, but in most of them is only for part of the parameters.
  • In the Russian Wikipedia were created some examples of infoboxes with Wikidata integration, and after it was a discussion, in which we decided to use the information from Wikidata, but with the condition of priority information specified locally in Wikipedia. At the moment, it works the same way.
  • I spoke with the participants of a number of small Wikipedias, and I know that the use of Wikidata interesting for them. In their case, small enough discussion to come to a decision. For large communities, I can only offer this solution and show how it can work and how is working. Further, the decision remains with the community.
  • Example of population: When outputting data wrapped in tags that indicate the specific statements in Wikidata and allow you to create gadgets that will edit Wikidata directly from Wikipedia. But that is another major problem, and I don't see the opportunity to do it at the same time with this work.
• 3.
  • Depreciation on Wikipedia: Now template works in such a way that if there is a value in the infobox, it is displayed, but if the value is not specified, the value is sought in Wikidata. You can edit the template on Wikipedia, but for some editors, this can cause confusion, where the data is taken.
  • Visual Editor: I would really like to enable editing of Wikidata in VE (to start at least in TemplateData, and then links to statements from corresponding input fields), but in this project, it will not be done.
  • Infobox templates: Integration requires editing every single infobox to map the fields with Wikidata parameters. I conducted an experiment comparing the infobox fields by names, but it was unsuccessful.
  • End-user needs: To edit data next to each value you can place a link to corresponding statement. To add new data now there are no tools.
    • About what type of beta testing you asks? As to whether the use of such infobox convenient for the end user, it seems to me that this decision relates to a particular community.
    • For end users, it will be only a general description of the work. Extended documentation will be for those who edits the infoboxes, and for those who want to write extensions for specific properties.
  • User Interface: In the user interface does not change anything. Just some of the parameters will be displayed without adding them to the card.
• I understand that everyone wants a full two-way integration of Wikidata and Wikipedia, but it needs to solve a lot of problems. I propose to solve one of them. — putnik 23:41, 3 August 2016 (UTC)

@Putnik:

Thank you for trying to answer my many questions. I really appreciate it.

• 1. I am glad the budget is okay; however, please consider that there are actually 4.3 weeks to a month as a calculation. I think that is fair to adjust for that....
• 2. Thank you for the screen shots. I hope it was okay I added more details to them. It helped me when I was digging around in the pages to investigate this proposal and how it works on Russian Wikipedia
• 2. Unfortunately this approach of wrapping tags I think is not a workable solution. I am not familiar with gadgets so I would need to understand the potential usability of the gadget to know how it would work. But as markup it's really rough to deal with, don't like it at all
• 3. Depreciation = AWFUL (in my opinion) :-) This is my biggest fear and I will be a loud critic of this method. It removes control from on Wikipedia editing. I dislike this approach very strongly, sorry
• 3. Infobox templates are not difficult to parse out. I did this for the WikiCite proposal (for the Cite RefToolbar). There are numerous but a finite amount of elements = value relationships. They act as a controlled vocabulary and are definitely capturable. See Cite templates – 4 built-in categories
• 3. Infobox templates: The biggest issue here is the loss of controlled vocabularies. There is no pathway between the different Wikipedia infobox template elements and Wikidata, if I am understanding this project. So the granularity of the Infobox model is abandoned to fit it into Wikidata? This seems very bad. Why isn't the idea instead to capture the granularity of the Wikipedia infobox templates and incorporate those values into Wikidata? This seems more workable and practical. And there is no loss of data. Otherwise, it seems like a loss of data in the translation onto Wikidata -- a sort of terrible idea
• 3. End-user needs as you describe them involve the solution of using links? I think this is a bad idea. The simplicity of the element = value relationship is lost in a sea of sequential links. Really object to this
• 3. End user needs -- what I meant by this was that Wikipeida editors need to be able to work in a similar or same Wikipedia editing experience that they currently are working within -- this proposal creates a large number of very technical looking and seeming barriers
• 3. Beta testing means to test it in a simulated, non-live environment, with extensive samples, before actually implementing. This would be very important if it goes on larger Wikipedias
• 3. Documentation: This is a very big issue in my opinion with Wikidata. The user guides and documentation are not developed. So beyond the fact you are removing the editing from the Wikipedia editing environment and requiring editors to edit using the Wikidata interface, there is inadequate user documentation on how to do this. This essentially abandons Wikipedia editors on Wikidata with no instructions. This is not going to work. It's not an adequate solution to this question, apologies
• 3. User interface: By this I mean a form and interface. Not this mass of very dense Wiki Markup. See graphic of form I pasted above
• 3. Two-way integration of Wikidata and Wikipedia: This is why I suggest pairing with a Wikipedia editor so this can be a two-pronged approach. To go one way is a concern, is non-ideal. It meets the (possible) needs of Wikidata -- and abandons the Wikipedia editor? I know there is objection to see this as an X vs. Y relationship but you said yourself this solves only one problem. I don't think this is a good answer or solution

Thanks again for your responses. -- Erika aka BrillLyle (talk) 02:07, 4 August 2016 (UTC)

@BrillLyle:

• 1. Yes, that is about 4,3 weeks per month, 26 weeks in total. I will publish the approximate timeline soon.
• 2. I believe a more promising approach to specifying the parameter via a meta-template infobox (see screenshot #4). This does not affect gadgets, but it will be more convenient to use in the future, because the values can be processed together. Gadgets may work with HTML tags that wrap values.
• 3. Depreciation: Local values are always in a priority. If you do not like the value from Wikidata, you can set it up in Wikipedia. In the Russian Wikipedia, users have many fears too, but for now it all comes down to individual cases, each of which is solved in Wikidata after discussion.
• 3. In the case of infoboxes there is an ambiguity in the interpretation of the parameters. For example, a "country" may indicate P17, P27, P495 or P1532. And there are a lot of cases. Automatic matching will generate a lot of errors.
• 3. Infobox templates: It seems to me that we've got main misunderstanding happened. Infobox will not disappear and remain in the form in which there were. But now you can fill in the parameters as in the cards, as well as directly in Wikidata, and get the same result. If you for some reason do not like Wikidata, you can specify the values directly in the article. The integration process of Wikidata will be very long, and I believe that one day we will come to use infobox using only Wikidata, but definitely not now.
• 3. For end users it remains the same in the format "field name = value", as it now, but without wikitext. Users understand how to use visual editor for this, most of them can understand editing in Wikidata. Yes, it is more convenient to edit directly in Wikipedia, it must be done, but it does not mean that if it can be done right now, we do not need to do anything at all.
• 3. Documentation: Experience has shown that many people understand how it works, this is enough a simple documentation (nobody reads long texts anyway) and examples. Those who do not understand can edit the values directly in Wikipedia, there is nothing wrong with that. Ideally, the end-user does not need documentation, they need friendly interfaces.
• 3. User interface: User-friendly interfaces for editing Wikidata inside Wikipedia is a very difficult task. In the Russian Wikipedia we have forms for editing, but I do not think that they can offer to other projects as a good solution. If I offer them, you will write twice as much criticism and will be absolutely right.
• 3. Two-way integration: I believe that the integration with the VE and TemplateData is the perfect solution, and it does not interfere with the project, but rather complements it. I'm sorry if I could not convince you that this is different tasks, and reasonable to do separately.

— putnik 13:20, 4 August 2016 (UTC)

@Putnik:

Thanks again for your responses.

Documentation: This is really not a great answer. Can Wikipedia do a better job with documentation? Of course we can. I think Wikidata is actually worse than other projects, but is not alone either, in having inadequate documentation. It is probably unfair to single Wikidata out. I have done this because of the Authority Control depreciation, which is what I will probably end up creating something for. Maybe by doing this it will illustrate some of what might be possible by Documentation. But it is almost ridiculous to suggest that this situation cannot be improved. Like sitting in a dark room and saying, why change the light bulb, it will only eventually burn itself out again after use and there is not much wrong with being in the darkness anyhow? :-) ha ha ha. Okay.... anyway.

I think I do not have much to add to the majority of these comments. Especially the "perfect solution" which I don't see. At all. So.... I have tried to state my concerns and have listened to the responses but there does not seem to be workable solutions that will advocate for Wikipedia editors, which is my concern. So if other Wikipedians might have ideas or further comment, I encourage that!

Thanks Putnik, for taking the time and doing this work. For all the concerns I am expressing, I do appreciate your diligence and hard work on this. I know it is not a trivial thing. Best to you -- Erika aka BrillLyle (talk) 21:19, 4 August 2016 (UTC)

Eligibility confirmed, round 1 2016

This Project Grants proposal is under review!

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

The committee's formal review for round 1 2016 begins on 24 August 2016, and grants will be announced in October. See the schedule for more details.

Questions? Contact us.

--Marti (WMF) (talk) 18:06, 23 August 2016 (UTC)

Comments

The proposal is actually not so bad but I want the applicant to clarify a few things:

• How the proposed Wikidata module compares with similar modules from other projects, for instance, the module in frwiki mentioned above?
• Is the proposed module going to be a significant improvement over them?
• What new functionality will it implement that is not already present, for example, in enwiki's module?
• If there is no intent to push for it adoption by large wikis then the project goals/measures of success should be probably refined.

Ruslik (talk) 12:22, 24 August 2016 (UTC)

• The module in the Russian Wikipedia is not perfect, but the same situation and with the English and French modules. In the process of development, I plan to take existing successful solutions from different modules. The first week or two it will go on the comparison and a more detailed analysis. But the problem with all existing modules is that they are made exclusively for one Wikipedia, and their use and maintenance in other projects is difficult. In English, French or German Wikipedia there are technically competent users who are engaged in the development of the local module, but even in the top 10 Wikipedias, there are many that can not do it.
• Therefore, the main improvement is that it will be the cross-project framework for Wikidata, which can be used in any project as is or with some local features.
• Compared with the module in the English Wikipedia, a significant improvement will be an autogeneration of ref links directly from Wikidata.
• I have a goal to achieve the adoption of a module in larger projects. But 1) it all depends on the community, 2) the larger the project, the longer discuss such changes, 3) large projects usually do not want to accept the new changes without a successful example of their use. Within the 6 months, the module will be updated in the Russian (1.3M articles, 7th place), Ukrainian (648K articles, 16th place) and other Wikipedias, which now use Russian module. Also, I hope that I will deploy it in the Esperanto Wikipedia (232K articles, 32nd place) and some smaller wikis. But more important to me to create a tool that will allow users to do it themselves without much technical knowledge. @Ruslik0: What other possible goals you see within 6 months? — putnik 11:29, 29 August 2016 (UTC)
  • I added one more goal in accordance with what I wrote above. — putnik 11:09, 2 September 2016 (UTC)

Aggregated feedback from the committee for Wikidata module

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.9
(B) Community engagement Does it have a specific target community and plan to engage it often? Does it have community support?	8.0
(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?	7.8
(D) Measures of success Are there both quantitative and qualitative measures of success? Are they realistic? Can they be measured?	7.2
Additional comments from the Committee: If successful the project will likely have a fairly strong impact on the Wikimedia projects by increasing availability and use of Wikidata information in Wikipedia articles. It fits within Wikimedia's strategic priorities and can be sustained after the grant ends by volunteers alone. I am concerned it has limited potential for online impact. It will match only very specific needs of the Russian Wikipedia community, which is good but not enough. A lot more effort is needed to make it adopted beyond CEE communities traditionally influenced by Russian Wikipedia, and it’s not clear who will do this. This module would likely be able to be implemented by small communities without any specific requirements but is unlikely to be successful with more experienced communities who already use Wikidata. I am not clear if the module will be easy to adapt for other wiki projects. I appreciate endorsements from the Wikidata community and experts like Lydia Pintscher. This is an iteration on other contributions. As long as they continue to work with the on-wiki communities, this could go far. The project takes an iterative approach - it builds upon existing solutions (Wikidata modules) in Russian Wikipedia but proposes to significantly modernize them. It has clear targets and realistic measures of success. The grantee should better define what would be the advantages of the developed modules compared to similar existing modules on a number of large Wikipedias. It is unlikely to be the solution fitting needs of all Wikipedias. I think the project is realistic and can be finished within 6 months. The budget seems to be realistic as well and the only grantee has necessary skills. I support this project with changes to the budget. The budget seems quite high and we don’t have a good estimate of the number of hours to be worked over the 6 months or the cost of fees/taxes. The main concern is that there is no timeline given, and 6 months of full-time work on a single Lua module that might not be used on any big wiki project is a big investment and risk. It is slightly unclear if the grantee is the original author of the tool. Involvement from WMDE and other Wikidata experts would be good to see instead of just being a one-man effort. The plan for ongoing community engagement to integrate feedback should be more evident. The project has a wide community support and the grantee has an intention to further engage the community. There are reactions of the community and that's good. Opinions are mixed. Before these major changes like these, it is preferable to talk with the community, gather suggestions and then move toward the realization. This module targets Russian Wikipedia and is well supported by its community. It has less support from Wikidata community but potential grantee is rather well engaged in discussions. Many endorsements from diverse communities. Good to see. I support this project if the grantee adds an additional comparison with the existing Wikidata modules. I am concerned about funding this project without a clear timeline. With this level of funding and timeframe I would expect the module to be ‘’’the’’’ Wikidata module fitting needs of all communities. I am not clear this is the case. WikiData is the future and we need tools like these.

This proposal has been recommended for due diligence review.

The Project Grants Committee has conducted a preliminary assessment of your proposal and recommended it for due diligence review. This means that a majority of the committee reviewers favorably assessed this proposal and have requested further investigation by Wikimedia Foundation staff.

Next steps:

1. Aggregated committee comments from the committee are posted above. Note that these comments may vary, or even contradict each other, since they reflect the conclusions of multiple individual committee members who independently reviewed this proposal. We recommend that you review all the feedback and post any responses, clarifications or questions on this talk page.
2. Following due diligence review, a final funding decision will be announced on Thursday, May 27, 2021.

Questions? Contact us at projectgrants wikimedia  · org.

Putnik, our interview with you was part of the due diligence process (I'm getting these comments posted late). You are still welcome to record any response you have to committee comments on your talkpage to make your feedback publicly accessible, but I think we gathered the information we needed for the committee during our talk with you. Best regards, Marti (WMF) (talk) 18:49, 2 October 2016 (UTC)

• Thanks to the grant committee for feedback. I see a few things about which there are doubts:
  • Timeline: Timeline does not sufficiently clearly described at this point and specific priorities and the order of work will depend on the research and analysis in the first weeks of the project. Time at work was assessed quite pessimistic, and probably I will complete the main tasks quickly, while the remaining time will be spent on additional tasks.
  • Budget/risk: I believe that the budget cuts (and time) of the project will increase the risk that it will not be finished in time. There will also be interim results (results of researches, tools, data uploads to Wikidata), which will remain, regardless of the final result.
  • Existing modules: Comparison of modules and study how they can be integrated without breaking the current system will be one of the first tasks.
  • Integration into the English Wikipedia and other major projects: I will try to make the module integration and replacement as simple as possible for current users of other solutions, and I think that this will give an opportunity to integrate it into all projects. Perhaps this can be done with a MediaWiki extension.

  — putnik 17:37, 4 October 2016 (UTC)

Round 1 2016 decision

Congratulations! Your proposal has been selected for a Project Grant.

The committee has recommended this proposal and WMF has approved funding for the full amount of your request, $12,000 USD

Comments regarding this decision:
The committee is pleased to support your work to improve your current tool, making it easier for people to integrate data from Wikidata on Wikipedia. We look forward to seeing how the improvements are made, what engagement mechanisms you develop with the community, and how the tool is used in the future.

Next steps:

1. You will be contacted to sign a grant agreement and setup a monthly check-in schedule.
2. Review the information for grantees.
3. Use the new buttons on your original proposal to create your project pages.
4. Start work on your project!

Upcoming changes to Wikimedia Foundation Grants

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.

Focus alteration recommendation

It's nice to make code configurable and extendible. May I however suggest that a more important focus is keeping it simple and having automated tests. Both these things enable you to react to change (ie needing new extension points) and are critical for keeping maintainability economical. --Jeroen De Dauw (talk) 02:47, 11 October 2016 (UTC)