From: "How Long Do Wikipedia Editors Keep Active?"

Some new pointers (via @MGerlach ):

• Understanding Editor Drop-off
• How long do Wikipedia Editors Keep Active

Barrier to entry: Two thoughts on this.

I believe TypeScript's JSDoc mode does support defining full shapes as well. Right?

I am beginning to think that we might need to readjust the definition of when we consider the editor to has left Wikidata as I have proposed it. What do you think? Any ideas?

Also, I have a vague and anecdotal memory that Wikidata has a lot of users who are semi- or fully-automated bots but are not registered as such. Is this the case? If so, is there some other heuristic like overly rapid editing that we can use to filter out these users or analyze them separately?

People at Wikidata worked on having a part of the API possibilities accessible via REST but we also explored a bit of GraphQL and other ideas. If you are interested, @Silvan_WMDE and @Addshore can probably tell more.
This report has some survey results concerning skills in various API standards of the people from the Wikidata community who answered the survey.

@daniel maybe "refactoring Mediawiki" might be more descriptive? I looked at the title and wondered what you want to decouple Mediawiki from.

Yes, looks great! Thansk

1 swapped

So, as I learned from a team member the WMF has put up their modal design. They use a right-upper corner x.

Here is the text from the mockup above:

It is relevant that the "Assess Quality"-button is in the "box" that also contains the items or SPARQL, respectively; otherwise we might suggest, UI-wise, that the button is bound to all inputs not just what is in the currently activated tab.

There is no x to keep it easy to use (aka hit with your fingers and find it at an expectable position) on mobile. I could try to find out what Wikit is doing with popups and if they change between mobile and desktop and suggest a matching behavior here.

Looks fine to me!

Plotly already provides for that: if a user zooms in the diagram, an overlay message should pop up …

• If it is possible to give "human" labels to the variables, and if I understand them right it might be useful to do the following
  • current_year → over last 12 month
  • current_snapshot → over last month
  • history_to_current_snapshot → all time
• For the diagram it would be great to have a reset button somewhere in case one creates a mess by zooming in or panning away from the graph. Hope that is just a config option.

One variable I did not ask for: current_year – is this from beginning of the calendar year to the current snapshot or from the snapshot 12 months ago until the current snapshot?

This would look like this:

Is there some (implicit) standard where the logo should be?
Currently is it as big as on Wikidata itself, on the right side and linked to Wikidata. So currently is has undue weight.

I am generally fine with not providing them but afaic we make at least two mathematically dubious steps so I would have the tendency to be transparent. We could also explain how the score is created in the help file, though.

Discussion about error messages to T276236

Can we distinguish the problems? Cause then we could have:

I considered the flyout, but it turns out to be harder to integrate in existing layouts, so I went ahead with a popup.

Isn’t the most likely reason for an error that the WiFi is flaky?

Where should the links go? Wikimedia Deutschland e.V.,
Github project and github issues?

If our primary target group is editors, then we could just show the whole table directly and I put all relevant information and action above the table so nothing is pushed into invisibility.

We could have a "How is this score calculated" flyout and put all info about ORES, difference between the things items refer to and the content of the items themselves etc. inside there.

Lets split the "other developers should be able to report problems" in a separate ticket; as we should do with "have a error message that provides helpful guidance to problem solving (for non-developers)"

This may be problematic for users who don't have Github but would like to get your thoughts anyway.

Currently we have

Not yet. I think we should solve this with T275993.

That makes sense.

Ideally, the table would give the item label, item QId, weighted ORES Score and the ORES-probabilities for a score of 1,2,3,4,5:

Suggestion: ADD: an error is shown when providing anything but an Item ID. There is an error pointing out each of the offending inputs, rather than only the first one. (at least up to, lets say, 10 Errors or so)

Depending on the "cost" of queries and checking we might either show the evaluation results on the input page (1) or on the results page (2)

Suggestion: DELETE "a call to action exists that asks the editor to improve the worst Items"
Suggestion: ADD "The table is inserted in the page as-it-is, meaning rather than the table having a scrollbar, the page grown in length. (This is less sensitive to design changes in the future)

As suggested in the meeting, I would not provide a separate text or so for it, but go by a "show-don’t-tell"-approach that makes the actual improvement of the times easy by linking them in the table and enabling to sort the table easily.

If I understand it correctly, we will not build an interface getting the score specifically for one item, thus I wouldn’t/couldn’t not provide a mockup.
In this case the BBD criteria would need to be adjusted to work abstractly without UI.

If I understand it correctly, we will not build an interface getting the score specifically for one item, thus I wouldn’t/couldn’t not provide a mockup.
In this case the BBD criteria would need to be adjusted to work abstractly without UI.

True as well.

Thanks!
Just to understand it correctly – what do the 3 values refer to, particularly, are they from beginning of time until some point ("wealth") or for a specific timeframe ("income")?

The dashboard for this can be produced in a minimal time. It will be included to our Wikidata Analytics portal, under "Analytics", if you agree.

If I understand you correctly, you can/did calculate scores based on

Thanks – that’s great! I created the calculation in JavaScript but did not have an R version yet.

Just a reminder from user research: Participants love a sharing option; the problem with storing state in URLs is that the data that the URL can carry was, at least for some the handwritten requests, rather limited and people started to code-golf their queries.

Again, please: did we resolve this one?

I calculated the hoover index for some contribution metrics recently and it was rather easy to do using a table with the columns edit count | count of accounts with this edit count which has somewhat between 100 and 1000 rows. Hoover also seems to be rather easy to understand, working without area-under-the-curve and varies between 0 (all equal) and 1 (maximum unequal).

See related T217233 (Implement Model Items on Wikidata)

See related T205014 (Data input: Forms for Item Entry)