Thanks! That helps, I think.

Thank you so much to the entire team! 🙏
I look forward to using it 😊

In T344541#9146428, @AnneT wrote:

We don't have any demos of dialogs open on mount, so I'm skipping design review and moving straight to pending release. This fix will go out with the Codex release next week @Celenduin!

In T344541#9111924, @Catrope wrote:

[...]

I'm writing a Statement editing interface for mobile Wikidata, which means adding edit-buttons in a lot of places that open the same dialog with different data. It doesn't seem like a great idea to already mount the whole app in a lot of different places just to have the button there that might or might not be clicked.

Is your concern that creating lots of copies of this dialog in the DOM would be wasteful if the dialog is never opened? If that's the main issue, would it be helpful if we changed the Dialog component so that it didn't render itself unless it was open (i.e. if it applied v-if="open" to its contents)? Alternatively, would there be a way that all these buttons could all share one dialog instance?

I volunteered some time and created a first version that uses rollup to build the main code: https://gerrit.wikimedia.org/r/c/wikidata/query/gui/+/875993

I forked @Lectrician1's userscript and made a first working version: https://www.wikidata.org/wiki/User:Zvpunry/WikibaseEcho.js

@Physikerwelt I spent a lunch-time and a bit and made a user script that allows you to create new math statements on items: https://www.wikidata.org/wiki/User:Zvpunry/MathWorkaround.js

In T262215#6441223, @Aklapper wrote:

In T262215#6441075, @Celenduin wrote:

as the "public" phabricator conduit API is missing the Access-Control-Allow-Origin header and [browsers care about such a thing nowadays]

Please help me understand why that's relevant and why browsers are mentioned if you plan to have some code running somewhere to pull stuff via the API.

But I guess this is quickly answered as apparently not feasable as the "public" phabricator conduit API is missing the Access-Control-Allow-Origin header and browsers care about such a thing nowadays. Also, this doesn't even seem to be a configuration issue on the wikimedia side of things, but adding that header is a WONTFIX in phabricator itself: https://secure.phabricator.com/T7304. *throws hands up in the air in resignation*

Hi @Aklapper, problem to solve is that prioritizing non-product tasks (e.g. refactorings, cleanup tasks, writing docs, etc.) consistently and transparently can be non-trivial. One possible approach to this would be to score the task along some dimensions (e.g. developer impact, did it cause issues before, how many extensions would it affect) and rank task according to that score. This is inspired by a concept called user pain.