Fri, Dec 6
Another question that came up: "this value is currently semi-protected on $repoName and can be edited only be autoconfirmed/confirmed users", second from last mock-up.
This sounds like it iterates the groups that can. In practice we know about actions which need to be allowed to do something. Certainly we can try to deduce the groups from the actions but we'd put more effort into this than MediaWiki itself (uses fixed messages per "reason", e.g. "semi-protected"). Is that intended?
(@Lucas_Werkmeister_WMDE please correct my terminology if it's off!)
Thu, Dec 5
The nature of this ticket is, counter to what was agreed when this product was kicked-off, the archetype of the opposite of "responsive development".
Consequently I assume that this is a one-off compensation for oversight in specification so far, but that we can expect stories to contain specification for the new components at all planned viewports.
This can now, again, be witnessed on beta.
Wed, Dec 4
@Lucas_Werkmeister_WMDE mentioned during the task break-down that we still need to check for blocking as a permission problem, add it to the output.
We did not commit to this during the sprint start of Wikidata-Bridge-Sprint-11 as we expect some conflict and/or synergies with T235154: show error when editor can't edit the statement because of permission errors on the repository which are hard to parallelize but under-comitted a little in the hope to address at least parts of this during this sprint.
Tue, Dec 3
Working hypothesis is that in the past, while developing termbox, we were all surfing about with funky ULS cookies so "nobody ever" looked at a pure English version without any "more languages".
Mon, Dec 2
Visual Editor was identified as the reference implementation.
Defined in https://gerrit.wikimedia.org/g/mediawiki/extensions/VisualEditor/+/90bbfb56837a3b01b1238ec191af827dd0e0dde2/modules/ve-mw/preinit/styles/ve.init.mw.ProgressBarWidget-wikimediatheme.css#13
There was some deployment lag due to technical problems, but this can now be witnessed on beta.
Thu, Nov 28
Mon, Nov 25
Wed, Nov 20
Discussed with @Charlie_WMDE during task break-down (N° 10):
- error reasons for client and repo will be shown in the interface alongside
- client reason(s) will be clustered first
- repo reason(s) will be clustered second
Mon, Nov 18
Amir did an excellent job at explaining wikidata - the video recorded unfortunately lacks sounds for the first ~2mins and cuts out early (empty battery) so I did not upload it.
Sat, Nov 16
Fri, Nov 15
i had this crazy idea
once i had kids, and job and life i stopped playing instruments but about a year a ago i found an ukulele for me in vienna
about 35 €
i travel with it, it is small, it take it to the plane
very similar to other string instruments
krinkle: i play the piano
clearly, i am not the first person to start playing an instrument and trying to connect it to the computer - to convert it to text
(Sparse) Notes from during the session:
Wed, Nov 13
Nov 8 2019
Nov 6 2019
Another question: How does this error state affect the save/publish button? The mock-ups show it hidden, but the AC do not mention it.
Another question: the links that are mentioned are apparently not supposed to run through Special:MyLanguage - is that intentional?
During the task break down a question came up which does not seem to be answered:
What if a user is not allowed to edit for multiple reasons? Do we show (and explain) all of them? Or is there a hierarchy and we only show the most severe one?
During the task break down we discussed that there seems to be an interesting ratio between the effort it takes to use/show the progress bar and the animations mentioned.
This is particularly alienating as it was mentioned that it is hard to imagine how these animations/transitions look/feel like.
The more agile approach might have been to add the loading bar and then have dedicated feature requests to modify its animations/transitions if we realize that the look and feel leaves something to be desired.
During the sprint start we quickly discussed this and concluded that we will move the missing functionality (blocked on the client) into a dedicated ticket.
Nov 5 2019
Nov 4 2019
stick to whatever desktop is doing and want to diverge the UI for mobile
Nov 1 2019
Oct 31 2019
"in case of 0 references title is not visible" contradicts the latest comment - @Charlie_WMDE help, please.