[…] there's nothing more cryptic about it than any other markup.
I tried the effects of these two changes. Even if I totally support the idea presented, I must say I do have some mild concerns with the way this is currently presented to users of the VisualEditor. I believe it's possible to resolve this quite easily:
- In all cases where users decide to ignore the empty space above the table they are going to insert, a super-cryptic |+ ends in the wikitext. I think this is effect is unavoidable, but:
- VisualEditor presents the caption as an empty space. There is absolutely zero hint at what this space is meant to be. If I focus it, it gets a thin dashed line and an editor cursor. But that's it.
Wed, Nov 22
Tue, Nov 21
During todays discussion round there was huge confusion what this ticket here should be about: Is it exclusively about Lua? If so, why? Shouldn't this be about fine-grained usage tracking and change notifications in general? And what does "fine-grained" include? Tracking statements and descriptions as well?
Mon, Nov 20
We tried to estimate this ticket today. We concluded this will – hopefully – not (technically) block us from doing T168263: WikibaseLexeme functional baseline. The team will write new browser tests with nodejs to avoid growing the technical debt the existing browser tests already represent, but leave the existing tests untouched for now.
If you as me, you should simply remove all @uses tags. From my experience they are of limited use, add awful clutter to the tests headers, nobody tracks and updates them properly, and they become outdated way to fast. Just make sure a test @covers exactly the one (maybe two or three) classes it should cover, and verify this via a coverage report.
A datatype for something like this already exists: we call it "external identifier". Internally it's still a string, but appears as a link in the user interface as well as in exports.
The patch https://gerrit.wikimedia.org/r/391244 was a direct result of this task. But since this ticket got closed before the patch was merged, the patch is "orphaned" now. How would anybody ever look at it again?
- It's in a chain of patches that block T180469: Make Forms and FormId implement Entity interfaces, which can't be closed without also reviewing the "orphaned" patch.
- Or somebody needs to create a Phabricator ticket for the sole purpose of splitting "investigation" and "realization" into two different tickets, assign the patch to that new ticket, move that to the sprint, probably discuss it first (because we never said we will actually work on this, or did we?), and probably close the ticket ten minutes later when the review is done. Holy cow.
Fri, Nov 17
Thu, Nov 16
Wed, Nov 15
Uses labels from items by turning L5-F11 into Q11.
[…] except that it does return a value where the item ID is translated to a form/sense ID (Q11 becomes L5-F11).
I realized the missing thumbnails are nothing but a bug in our code, and submitted a patch to fix it.
Tue, Nov 14
I had a look at the remaining usages and they are all fine. All remaining calls of one of these newFromNumber methods are either done on a number as returned by Int32EntityId::getNumericId, which is well specified and encapsulated. Or they are because of T114904: Migrate wb_items_per_site to using prefixed entity IDs instead of numeric IDs, but that has it's own ticket already.
I will close this ticket for now because it seems to fulfill no purpose.
- The mentioned patch was merged 8 months ago.
- The tickets title is as vague as it can be. "Refactor" is a continuous process, nothing we can or should track.
- There are no acceptance criteria.
- I don't think it is even possible to remove all "global state" and "database" access from this test. From what I understand it is more an integration test, which means it should also test the integration with the database. That database should be a fast SQLite one during tests for performance reasons, but still an actual database.
I removed this ticket from our sprint boards for the moment. The only remaining patch https://gerrit.wikimedia.org/r/384050 is work in progress, but I do not find it obvious what exactly is needed to get it out of that state. I suggest to focus on the not yet closed sub-tickets instead, and possibly create more sub-tickets if needed.
Can we consider this done with https://gerrit.wikimedia.org/r/390365?