Some projects have reported issues with infobox, images and hatnote styling. If your project is impacted, please redirect concerns to this ticket.
We are evaluating fixes and hope to provide updates on that ticket soon.
Jdlrobson | |
Jun 14 2024, 12:47 AM |
F57689628: Screenshot 2024-11-08 at 10.23.16 AM.png | |
Nov 8 2024, 6:23 PM |
Some projects have reported issues with infobox, images and hatnote styling. If your project is impacted, please redirect concerns to this ticket.
We are evaluating fixes and hope to provide updates on that ticket soon.
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Open | bwang | T361737 [EPIC] With the current layout, some elements extend beyond the content area and overlap sticky page tools | |||
Resolved | Jdlrobson | T367480 Changes to infobox, hatnote and image styling in Vector 2022 |
I have copied multiple reports of undesirable behavior from the English WP Village Pump (technical) into T367462. If any of the problems are not related to the style changes reported in the original bug report, they may need to be split into separate bug reports.
The code that caused these breaking changes really needs to be rolled back and fixed on a development server. It is far too disruptive to be on the live encyclopedia.
Hey everyone, this is the Web team working on skins. We wanted to explain the situation, apologize, and share what will happen next. Thank you all for reporting and helping us fix things.
This week, we released styling changes to hatnotes, templates, and images. Some of these changes were not intended for rollout this week. Our focus was mostly on T113101 and related tasks. We apologize for introducing bugs and making editors confused.
We read concerns shared on different wikis and on Discord, and went over our options. We decided to revert all changes to templates and hatnotes for the time being, and keep the changes to images. Next, we'll review the changes to templates and hatnotes, and bring them for discussion one by one prior to proceeding. If you notice any remaining issues with images, please report them in comments to T367463. We hope to have a fix for the remaining issue on Monday.
Thank you!
@Aklapper any chance we could setup a Herald rule that resolves any task in "Already announced/Archive" column? Having to close these out is a bit tedious given an existing workflow already exists. If not, I'd like to document somewhere in Tech News process that anyone should feel free to close out such tickets if possible (without needing to seek permission).
Usually User-notice is used on a task that amounts to "do the work", and sometimes the announcement is sent before the work is done so autoclosing isn't appropriate necessarily. The Web Team seems to, unlike anyone else, create separate tasks for "send an announcement".
But sure, I'll start closing these when I come across them without asking first.
Thanks @Pppery I wasn't aware web team approached announcements differently but yes do feel free to close out any ticket that's announcement-like. Is it documented anywhere @Quiddity what is preferable? FWIW I do think separate announcements are useful, as usually tasks are written from a developer point of view, and user notice often need a different audience. I know you often have to ask lots of questions and propose wording when tasks are not clear and I don't think that's fair on you so that has typically why I have been approaching it that way.
PS. I just realized you can auto resolve tickets once they are dropped in a column so I guess no need for a herald rule if that approach is taken:
@Jdlrobson I'd recommend tagging the original task with #user-notice in the future. That makes it easier for me/other TN editors to read any associated comments/concerns/contexts, and thus more easily notice and propose any tweaks to a draft-entry, and to potentially notice things like patch-reverts/merges. Plus it reduces the quantity of threads in our inboxes (for those who use email to triage).
Re: tasks being written from a developer-perspective - that's true, and is sometimes a drawback. However, instead of creating a new task with a non-dev-focused description, I'd generally encourage editing the existing task's description to add a more non-dev-skimmable overview. E.g. Just write the summary above the more technical description, at the same time as writing a comment with the draft-entry. -- Relatedly, we mostly try to avoid linking to phabricator tasks from the prose of most entries (and usually leave them as bare [1] reference links) because Phabricator isn't an easily 'translatable' destination to arrive at (so it's not good for the non-English recipients of Tech News), but with exceptions for tasks that are entirely dev-focused.
Documentation-wise, it's briefly covered in the 3rd bulletpoint at https://meta.wikimedia.org/wiki/Tech/News/For_contributors#How_to_add_an_item but not in detail. I'm planning some updates to that documentation, and will keep this thread in mind for that segment.
Re: auto-closing - We cannot do that, because many tasks are still 'open' (or get re-opened) even after being announced (cf. Most of the 'open' entries in that column now: https://phabricator.wikimedia.org/project/board/1097/query/open/) -- But just-FYI, we do have User-notice-archive which is an archive for #User-notice to avoid the phab-project getting extremely bloated and unloadable. A bot moves resolved tasks in the "Already announced/Archive" column of User-notice, into the -archive, if they are not modified in the past ten days.
HTH! Sorry for the length!
@Jdlrobson: Best to bring up on https://www.mediawiki.org/wiki/Talk:Phabricator/Help as I'm not the only person who can answer such questions. I think you can set this up already, see https://www.mediawiki.org/wiki/Phabricator/Project_management#Automated_actions_via_column_triggers