Using vuetify, we probably want a skeleton loader with, lets say, two list-items in there?

Option 2: Fix api to work with task-specific emails

Would need answer from developers to: "Which UI framework was used to build the UI?". We then could see what styles are predefined for errors, notifications and provide a mockup to a developer to implement the feedback.

I think we would need to hardcode a place for impressum anyway, since the link should be always visible in the footer, which users currently can't config themselves anyway, which would ease both solutions as we would know where it is.

I think that providing a note next to "create wiki" is not very helpful for users. They can't act on it there and just get the info to create something they probably never heard about. If we do this, it will also stick around and will lead to it "not being a serious problem" despite its sub-par usability.

Possible solutions mockups:

Is there some way for users to know how many Wikis they still can create (a counter or so?) Or do they need the documentation to find that out?

I looked into this to find out what this function does. Here is what I currently assume:

Thanks – I approve!

disagree; wikibase.cloud is a WMDE product, and technical documentation for our products lives on mediawiki.org

I assume the link to the documentation should be easily accessible for people who want to get information on WBStack in general and for people who are logged in.

I wouldn't mind if an engineer/UX/Designer did letter-by-letter check that the other two parts in the linked change already have the intended text.

In case the HTML is too messy, you could try piping it through pandoc – download as .docx and convert to HTML. Use pandoc inputdoc.docx -o outputdoc.html. I gave it a try and it works well, aside of the original docx having some sections in tables and headlines being manually set to bold, which are quirks that carry over. But I guess it is still a good start for resolving these quirks. (You could write a pandoc script that resolves these issues, but you are probably far faster doing it manually)

• We could not include all content from the suggested text, since there are no FAQ yet (and we did not want to create a dysfunctional link)
• We went with the not-a-waitinglist text-version for now, but we can easily add a link to the the get considered for closed beta form (we probably should be clear likely it is to get in the closed beta)

Just to check: Mere CNAME is sufficient, we do not need A and AAA records set?

Here some background on what we talked about:

sure sure, go ahead :)

What about:

Thanks, super interesting! Some things are beyond my data-skills, thus, I look forward to feedback from other people!

Seems also relevant: https://eprints.whiterose.ac.uk/140352/1/evolution-wikidata-editors.pdf "The evolution of power and standard Wikidata editors: comparing editing behavior over time to predict lifespan and volume of edits"

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.