Extension talk:MobileFrontend/WikiGrok

Edit to Wikidata?

What does "eventually stored in Wikidata" mean? I just answered a question but cannot see anything in my contributions on Wikidata. Will i ever get credit for that? Ainali (talk) 21:29, 6 November 2014 (UTC)

Hello! Currently, the user input is saved separately to see, how the quality of the input is. This is a completely new feature in MediaWiki/Wikipedia world and the team don't know, how the users will use it. So the decision was to log the data separately, look into it and decide, what we can can do better (or have to do) to make this feature ready for production use (where the user input will go directly into wikidata). --Florianschmidtwelzow (talk) 21:48, 6 November 2014 (UTC)

Thanks for the quick answer. So what are the requirements you have setup for enabling direct input? Ainali (talk) 22:38, 6 November 2014 (UTC)

Puh, the requirements i don't know in detail, i think @Kaldari: and/or @Maryana (WMF): can answer this question more detailed :) --Florianschmidtwelzow (talk) 07:15, 7 November 2014 (UTC)

Thanks. To be clear, I am not actually that worried about edit count, it is more that as a Wikipedian I am used to see my efforts actually get used in the projects rather than being a research object. --Ainali (talk) 08:47, 7 November 2014 (UTC)

@Ainali: We currently have two different WikiGrok interfaces that we are testing. We will be pitting them directly against each other in an A/B test in the next week or so. We will be looking at the results from both a quantitative and qualitative point of view and then launching one of the interfaces to stable. At that point, we will also start pushing responses to Wikidata (although there may be an aggregation threshold depending on the qualitative results of the A/B test). In other words, if only 60% of responses are accurate, we should wait until X% of people have submitted the same result before pushing it to Wikidata. The data that we've seen so far has been encouraging though. Let me know if you have any suggestions regarding this. Kaldari (talk) 18:47, 7 November 2014 (UTC)

Well, my suggestion is to do it the same way as when one edit Wikidata or Wikipedia (or the Wikidata-game for that matter). Make the edit immidiately when the user makes the input and attribute it to the user. Actually it feels like I am not trusted if you are going to compare my answers to others before making the edit. As a long time contributor, I do not feel empowered by this feature. Or, to make a compromise, perhaps logged in users contributions could be written directly to Wikidata and IP-users could be compared with other IP-users? --Ainali (talk) 21:35, 7 November 2014 (UTC)

@Ainali: That's an excellent idea. After the A/B is finished, we will be comparing the quality of the logged-in and anonymous users who used this feature. We will also be looking at whether users' edit counts affect the quality of their contributions. Ideally, we want to submit all contributions immediately, but we want to be sure we don't flood Wikidata with crap. Kaldari (talk) 00:06, 13 November 2014 (UTC)

┌─────────────────────────────────┘
I see this a different way. It seems to me that the vast majority of users who play this game on English Wikipedia in Mobile would have no idea how to know whether their choice made a difference on Wikidata, which they've likely never visited. Answering a question (even with a tout like "help us improve Wikipedia") is not the same as editing (and I think this may be a way to get contributions from readers who would be reluctant to directly edit). - PKM (talk) 18:37, 7 December 2014 (UTC)

Defer fetching Wikidata claims when the user saves an edit

I think @Kaldari: has mentioned this before but if we're worried about slowing down page saving then we can offload the work to a job queue. I'm not familiar with our infrastructure here but if we're worried about swamping the job queue with jobs, then we can:

• spin up more workers
• use a specialised, i.e. isolated, job queue
• put something in between the producer (the hook) and the queue that rate limits the number of jobs that can be put on the job queue — Preceding unsigned comment added by Phuedx (WMF) (talk • contribs) 15:53, Nov 12, 2014 (UTC)

Those are great ideas we should investigate further. There are two main issues: CPU usage and memory usage. For LinkedProp campaigns, one thing that would help both would be to only look at the first X page links. Solving Bug 52385 would allow us to not have to load huge Wikidata blobs for each page link, which would dramatically reduce our memory usage. Kaldari (talk) 00:22, 13 November 2014 (UTC)

Some suggestions

I had some suggestion for Magnus's Wikidata Game, at here may be they will be useful for your toolYamaha5 (talk) 22:32, 6 December 2014 (UTC)