Wikibugs just joined #wikimedia-operations

In T308933#7948870, @Ladsgroup wrote:

Both are done.

@Ladsgroup has the schema change already been applied to production? Or is it just the views that were updated

Cross link T116948, seems like there will be work soon to remove from WMF so this won't be needed

It looks like its been that way since it was first added in https://github.com/x-tools/xtools/commit/e7f46030de93babbbdd311b2911f82a2f3fb24dc

Simplify tests by moving reusable setup

Superseded by rDCOD27ce23c3d864: docs: Allow configuring icons used as slot contents where there is an icon picker for a slot icon (any that the user wants) instead of a toggle

The figma spec linked in the description says that the file is not found (perhaps it needs to be made public?)

The figma spec linked in the description says that the file is not found (perhaps it needs to be made public?)

Unclaiming for the work on a determinate variant

@AnneT can this be closed?

Can I be added as a subscriber to P26128 please? Its currently private

While I fully admin I have little experience with ARIA attributes, I *think* that tablist does allow this attribute?

Just crosslinking T266890 for reference on that task (release process)

+1, just came to try and request this myself, because I run a bot that marks pages as reviewed and when they are unreviewed it doesn't help to report it to the bot

There is a Legal directive to move away from storing and publishing IP addresses on Wikimedia sites for all users.

This is the first I've heard of a directive not to store IP addresses - is this correct? How will users with advanced rights be able to unveil the IP if it is not stored?

In T295177#7895555, @bmartinezcalvo wrote:

In T295177#7892419, @DannyS712 wrote:

Do you mean the border? The inner bar has a height of 16px, and then the outer wrapper has a 1px border on all sides, for the total 18px height. Are you saying to reduce the inner bar to 14px so that the border brings it to 16?

@DannyS712 I mean a 16px inner bar with a 1px stroke outline inside (instead of outside) so the progress bar heigh is not 18px but 16px. Something similar to TextInput outline.

I'll wait until after T306581: Handle icons correctly in sample code generation merges to be able to configure the icon as well

In T306856#7893238, @STHart wrote:

@DannyS712 @Volker_E if this is in progress, could you please add the "In Progress" tag? If it's being worked on, then it would be appropriate to add to the current Sprint. Otherwise, we should add it to the "Up Next" column on our team board.

@bmartinezcalvo though this is currently in the "code review" column, the patch is stalled on some design review before being merged. Would you mind taking a look? You can see the result of the patch at https://785354--wikimedia-codex.netlify.app/components/text-input.html#demos

In T295177#7888890, @bmartinezcalvo wrote:

@DannyS712 I've done the Design Review of the component and I found one correction to do:

1. Component height should be 16px. Now it has 18px because it seems that the outline is outside the component instead of inside (we always use outline inside the component to avoid to increase the height of the element)

I'm going to create the Design Review checklist with this correction.

LogoFunctions is about an extension unrelated to the request

Given that: MWStake is on track to manage future MediaWiki releases for the WMF

These were introduced in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/703416 and haven't changed since then.

The use of UserIdentityValue was introduced then, but I made sure to match the existing behavior with User objects that had the same results as close as possible - see 825064fa759c21d22dae3535d60b80f47f04b42b where I added regression tests for the old behavior with user objects:

New component, bug or component improvement tickets should be added to the 'Needs Triage (Incoming Requests)' column in the Codex Phabricator Workboard.

In T306952#7883227, @Stang wrote:

@DannyS712 Hmm, is wikidata, not meta...

Done

In T295177#7879385, @STHart wrote:

@DannyS712 thanks for your feedback from a volunteer's perspective. Our goal is to provide an intake and tracking process that is maintainable for the team and also intuitive for all contributors to participate in. When we revisited this, we knew that the Codex board was super out of date, which was an indicator to us that maintaining statuses in multiple locations is not maintainable manually.

Makes sense, though it hasn't (to me at least) been a big deal elsewhere. But my biggest point is that if you were going to use one location, it should have been the Codex board rather than a DST board

I'll revisit this topic in the team; there are a few paths forward. Ideally I'd like to have a column of "Open" issues that are free for volunteers to grab, and track status within our sprints if feasible.

This makes sense for status within the DST board but it should also be visible in the codex board - right now I've seen some tasks where the title was updated to reflect the status, which is a bit helpful but columns were more useful

We're actively iterating on this, so thanks for your patience. We welcome any and all volunteer contributions but are not actively seeking more until we sort all of this out, for the reasons you've stated, and also to focus on completing our prototype iterations. I've created a task T306857: Workflow for volunteer/cross-team contributions to track progress on improving this workflow. Thank you!

Happy to help

The text input demo already includes a note

This component will pass any HTML attributes applied to it, except for CSS class, to the <input> element within the component.

so it might make sense to list the HTML attributes separately, but for now just added as a normal prop

In T303899#7816452, @DannyS712 wrote:

Hmm, doesn't appear to be visible at https://doc.wikimedia.org/cover/ yet?

key() doesn't have parameters, but offsetGet() does, and functions that do not start with "get" and have no parameters do not require documentation, per 42f4c82601e70e7a6ec6697253ab2bbae67e93a2

In T295177#7878605, @ldelench_wmf wrote:

In T295177#7875286, @DannyS712 wrote:

Since this is as good a place as any, @ldelench_wmf why were the column from the Codex workboard all hidden, and everything moved into "Open Tasks"? This makes it a lot harder to figure out what is going on and the current state of each ticket

Hi @DannyS712, thanks for your question (and all of your contributions to Codex!) and apologies for any confusion this caused.
We found it was inefficient & confusing for Design Systems to track task statuses on multiple boards, so all our active work is now tracked in one place: Design-Systems-Sprint. We have been pulling your assigned tasks for Code Review & Design Review into that board as we go.
Let me know if there's a need we're not meeting with this current approach & I'll add it as a topic for our retrospective.

Appears unrelated to codex (which isn't even in use yet)

Since this is as good a place as any, @ldelench_wmf why were the column from the Codex workboard all hidden, and everything moved into "Open Tasks"? This makes it a lot harder to figure out what is going on and the current state of each ticket

@thiemowmde added these in c7256b0c68708fbd2c950c4e1ce172fe27d87e15

• assertNotEquals() as well as assertNotSame() with a boolean value is not wrong, but highly confusing. Replace with assertTrue/False().

I plan to investigate adding a configurable icon to the wrapper in the next few days

Our use of document.execCommand( 'copy' ) might need to be reconsidered, since it is marked as deprecated, https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand

In T295179#7863835, @bmartinezcalvo wrote:

@DannyS712 I've done the Design Review of the component demo and I found some corrections:

1. We need to add toggled-on-hover and toggled-on-active too for normal button to indicate the user the interaction when the user wants to turn off the button again.

2. Disabled toggled-on (normal button) still has wrong styles. It should be exactly the same as disabled toggled-off. Quiet disabled states are ok.

In T305890#7864187, @sbassett wrote:

In T305890#7858154, @thcipriani wrote:

This fights the model of phabricator a bit. Quoting the phab docs:

...

Phabricator's philosophy here is that it's hard to understand the intent of adding a tag.

I can sympathize with that, sure. But this is a use-case that upstream folks likely didn't envision (I find it bizarre myself) but due to certain legal constraints and risk acceptance by various leadership levels at the WMF, is really the only path forward that the Security-Team has found to provide more volunteer and community contributors access to a set of security-protected tasks in relation to the all-or-nothing status quo. This approach was outlined a bit in T305731 and discussed more thoroughly within T302686 and T298997. I'm also happy to have a more in-depth chat with anybody to further discuss or work through solutions for this issue.

In T157658#7861560, @Daimona wrote:

What's the status of this task? I would very much like to see EditPage go away, and I may be able to help with CR. The main patch is a few months old and out-of-date, at the point that it may be easier to start over. I also wonder if it would make more sense to split the changes into multiple patches, e.g. move everything as static methods in another file, then make everything non-static, inject dependencies, clean up etc., so that it's easier to review and it's less likely for things to break (which remains quite likely, given that we're talking about EditPage).

In T120794#7839206, @WDoranWMF wrote:

Just to be clear, on why I added this task to the Platform Engineering Icebox. We acknowledge the existence of this task but progress on it is unlikely. If anyone can walk through the urgency/priority that would be helpful.

Others are welcome to work on it or help to get it merged.

Okay, for the quiet version I'll have disabled be the same for toggled-on and toggled-off

In T305329#7827296, @Reedy wrote:

That and UserEditTracker::initializeUserEditCount() only does revision anyway...

In T305329#7827213, @Reedy wrote:

MariaDB [itwiki]> select * from actor where actor_user = 110871;
+----------+------------+-----------------------+
| actor_id | actor_user | actor_name            |
+----------+------------+-----------------------+
|   272621 |     110871 | Tetesco sotto il sale |
+----------+------------+-----------------------+
1 row in set (0.001 sec)

MariaDB [itwiki]> select count(*) from revision where rev_actor = 272621;
+----------+
| count(*) |
+----------+
|       88 |
+----------+
1 row in set (0.002 sec)

And the fix:

MariaDB [itwiki]> UPDATE user SET user_editcount=88 where user_id = 110871;
Query OK, 1 row affected (0.003 sec)
Rows matched: 1  Changed: 1  Warnings: 0

The rule appears to be {H188} - you should be able to update it yourself

In T295179#7824152, @bmartinezcalvo wrote:

If you go to https://doc.wikimedia.org/codex/main/components/toggle-button.html, hit the button to toggle it on, and then disable the button, you can see that the disabled state still reflects that it was toggled on. I would expect that the quiet version also reflects whether it is toggled on or toggled off when it is disabled

I hadn't realized when I did the Design Review of the demo but this design of the button when you disable it while toggled is not correct and should be fixed:

We don't want the disabled state for toggled-on is different for not toggled. Disabled buttons for both toggled and not toggled should be the same disabled button (that matches the rest of disabled on all our button):

Both normal and quiet buttons won't display a different disabled state for toggled and not toggled.

In T295179#7822511, @bmartinezcalvo wrote:

I mean I don't see the spec for the button when it is both toggled on *and* disabled

@DannyS712 do you mean the state Toggle-on Disabled? This design doesn't exist since we always use the same Disabled button for all button variants (Primary, Normal or Quiet). I mean, we don't have specific design for disabled outline buttons and disabled solid buttons, so we should use the same solid disabled button for both toggled disabled and toggled-on disabled.

In T222042#7822308, @Lucas_Werkmeister_WMDE wrote:

Reopening, since trailing commas keep coming up in places where they’re uncontroversial (e.g. resources.php file or message lists), but get forgotten because there’s no automatic sniff/fix for them. I did an informal poll among Wikibase developers, and it seems like we have consensus to enable such a rule there. I think the implementation of the sniff should live in the MediaWiki codesniffer; it doesn’t have to be included in the default ruleset, but it should be available for individual repositories if the developers there decide on it. Whether we want to enable it on our largest shared code base (MediaWiki core) is a different question, and if that’s more controversial then I’m happy to leave that alone for now.

@DannyS712 do you still have the code that you wrote at the time? The built-in ArrayDeclarationSniff still seems to be as unsuitable for this purpose as it was three years ago (T222042#5142556), as far as I can tell (the issue to make it more configurable remains open with little progress).

In T295179#7820900, @bmartinezcalvo wrote:

In T295179#7820170, @DannyS712 wrote:

The figma doesn't appear to include the toggled on and disabled state, can you add it so I know what the quiet version should look like?

Hey @DannyS712 you have in the spec sheet all Normal and Quiet states (view them here):

Also I've included the guides section for quiet buttons in the beginning of the spec sheet:

Tell me if you need something more.

In T295179#7810201, @bmartinezcalvo wrote:

When i click on the figma link, I'm told "File not found" and

Either this file doesn’t exist or you don’t have permission to view it. Ask the file owner to verify the link and/or update permissions.

@DannyS712 I'm so sorry, I had to give you permission to view the Figma file. I've updated the link permissions so you can view the Figma link.

We will probably need to revisit this when there is an icon prop type for the docs, but for now everything should be copyable :)