In T372981#10654731, @SDunlap wrote:

it has one or more patches that have not been either merged or abandoned OR

Note that PatchDemo also assigns a meta-status of dnm to any patch that has "DNM" or "DO NOT MERGE" in the subject. For the purposes of deleting wikis these patches can be assumed to be merged/abandoned.

If you need a slightly hacky approach, you can replace the image with CSS, by setting the width of the image to 0, and replace with padding with a background image:

img.ext-discussiontools-emptystate-logo {
    display: block;
    width: 0;
    padding-left: 250px;
    background: url( yourimage ) center no-repeat;
}

In T372981#10637425, @thcipriani wrote:

I like that, so all in the PatchDemo UI. In the past, have you done any on-wiki notifications (like we did for our recent cleanup)?

No, and we've not had complaints.

In T388581#10637440, @thcipriani wrote:

what are some recent examples?

In T344029#10630921, @Jdlrobson-WMF wrote:

From your perspective should the counter on mobile reflect both notices and alerts?

! In T344029#10631502, @RHo wrote:

it would make sense for the count to be for the combined unread number.

It appears the height jump is caused by the mw-logo being hidden.

Copy is the best alternative we have at the moment to update, but is sub-optimal because:

• You may have setup custom content on your wiki, this will need to be exported and imported
• You may have already shared the link with colleagues, these will need to be updated
• You usually want to delete the old wiki after creating the updated one.
• Each time you create and delete a wiki you get a PatchDemoBot post on linked tasks. Having to scroll through them all to find the latest non-deleted wiki is problematic.

I was notified about a wiki that only contains a [DNM] patch:

This was a task affecting the editing experience and we communicated the priority when filing the task. Not sure why it was lowered?

Rougly what is happening here:

• The differ works by bisecting the text and comparing smaller fragments
• Sometimes we are comparing linked letters from the old revision with linked letters from the new revision which are equal for the purposes of the diff (characters are equal, and the links have the same target)
• Because of this we have mixture of the link annotation from the old doc and the new doc. While the links are comparable, they have different originalDomElements, so when we re-render them we break up the link at these points, as a valid use case in Parsoid would be to preserve the user typing in adjacent-but-equal links.

The issue is the following bit of inavlid HTML, where a text node ("The options for...") is placed directly under a <ul>:

<ul>The options for traditional BSN plan of study are: 
    <li style="margin-left:3em;">Four (4) semester Program of Study: please see attachment A </li>
    <li style="margin-left:3em;">Six (6) semester Program of Study: please see attachment B</li>
    <li style="margin-left:3em;">The accelerated BSN plan of study: please see attachment C</li>
    <li style="margin-left:3em;">The RN-BSN plan of study: please see attachment D.</li>
</ul>

The above log mentions QuickInstantCommons, but even if I turn that off I get:

In T268631#10568628, @srishakatux wrote:

@ppelberg @Esanders it looks like you were exploring this task. Do you have more to share on the previous progress and the reasons it was stalled?

In T381537#10572722, @Novem_Linguae wrote:

Raise Grade A JavaScript requirement from ES2016 (ES7) to ES2017 (ES8)

When was MediaWiki's grade A requirement raised to ES7?

For wkkis with tasks attached I would also wait for the task to be marked as resolved as well. A typical workflow for our team might involve:

1. Create a wiki with patches, and maybe some test data
2. Patches gets reviewed and merged
3. QA reviews, and also may need PatchDemo wiki for reviewing (along side other environments, e.g. beta cluster).
4. Patch is deployed, marked as resolved. Only at this point can the wiki be deleted.

Note this is the same order as in the source editor: