Attn @Prtksxna

Icon + 'Feedback' link in the header (like ? Help) that links to https://meta.wikimedia.org/wiki/Talk:Community_health_initiative/Per-user_page,_namespace,_and_upload_blocking.

Need to update that project page.

We can use the feedback icon from the interactions pack in OOUI:

The current UI element on multiple special pages (Block, Recent Changes) is not a button — I'm concerned about:

1. changing the help link from an icon + link to a button only on Special:Block will create a UI inconsistency, and
2. changing the help link from an icon + link to a button everywhere is outside the scope of this project, and may be a larger time-consuming endeavor.

My personal preference is to leave it as icon + link and add an icon + link for Feedback. @Mooeypoo and @Tchanders may have further thoughts.

Just looking at a couple of other examples where special pages ask for feedback, which are both inline.

Special:Search adds a link within the text under the header:

Special:RecentChanges has a frameless button (with icon) inside the filters menu:

Should we be looking at inline options to stay consistent with these - or are there other examples where the feedback link is near the help link in the header?

In T212892#4944350, @TBolliger wrote:

This is the general "default" view we have for help link in special pages -- that is, "what is this page" -- especially without Javascript.

• If you go to https://www.mediawiki.org/wiki/Special:Notifications for example, and disable JavaScript, you'll see that representation as well.
• https://www.mediawiki.org/wiki/Special:RecentChanges also has that link at the top right corner in both JS and no-JS view.

In javascript-powered "app-like" products, the feedback was added in to where the workflow made sense. RecentChangesFilters added it to the menu as @Tchanders pointed out, and Special:Notifications inserted that link into the "Settings" cog menu when in JS mode. VisualEditor has a feedback button in their menu, too, since it's a full-blown JavaScript app.

So it looks like the "best behavior" is more up to the product owner's vision of what works best for the user.

In a page like Special:Block, JavaScript is more an augmenting feature rather than a straight-up engine so I'd consider putting the help/feedback in the same place that it would be if Javascript is not enabled.

It's a good point about consistency, but it looks like what we currently have (icon+link at the right-hand corner) is the "consistent" behavior for pages with no-js-centric behavior, while the js-centric "apps" do their own thing depending on usage.

In T212892#4944350, @TBolliger wrote:

The current UI element on multiple special pages (Block, Recent Changes) is not a button…

I couldn't access that page again and I remembered (incorrectly) that it was a button so made this. We should be fine with link and icon as well, I didn't mean to enforce the visual style.

In T212892#4944445, @Tchanders wrote:

Should we be looking at inline options to stay consistent with these - or are there other examples where the feedback link is near the help link in the header?

@Mooeypoo gave a good summary of where we have been placing the feedback icon right now (I didn't know any of this, thanks!). In light of this I guess it would be ok to put it with the help icon.

Here are some tickets that I had found earlier (just to note):

• T150959: Integrate a feedback page link in Recent Changes Beta filters
• T49815: "Leave feedback" link has confusing scope (see 3rd comment)
• T179571: Add feedback link to advancedSearch

In that case, let's use the megaphone feedback icon with 'Feedback' in with a link to Feedback in the header. Added a doctored screenshot in the task description.

@SPoore — should the link point to https://meta.wikimedia.org/wiki/Community_health_initiative/Partial_blocks/Feedback or to https://meta.wikimedia.org/wiki/Community_health_initiative/Blocking_tools_and_improvements/Feedback

@Niharika https://meta.wikimedia.org/wiki/Community_health_initiative/Partial_blocks/Feedback is the best one to keep the comments focused.

I'll mark it for translation and ask for help translating it.

@SPoore Just a note that the Feedback link appears on the general Special:Block page but the feedback page is only for partial blocks. Is that alright?

@Niharika that is a very good question. I suppose that we could link to the general page and ask for targeted feedback about partial blocks, but leave space for other feedback. https://meta.wikimedia.org/wiki/Community_health_initiative/Blocking_tools_and_improvements/Feedback

@Niharika another option is to have a special page for partial block feedback that is linked to from the main feedback page.

-Main feedback page about blocking tools https://meta.wikimedia.org/wiki/Community_health_initiative/Blocking_tools_and_improvements/Feedback

• Prominent link to a page with more detailed questions about partial blocks? https://meta.wikimedia.org/wiki/Community_health_initiative/Partial_blocks/Feedback

I tend towards the two page approach because although most admins will set many more sitewide blocks than partial blocks and could have more to say about them, we have committed to gathering substantive information about partial blocks since it is a new feature. Unless you or others think it is too confusing, I suggest a two page approach.

In T212892#5057511, @SPoore wrote:

@Niharika another option is to have a special page for partial block feedback that is linked to from the main feedback page.

-Main feedback page about blocking tools https://meta.wikimedia.org/wiki/Community_health_initiative/Blocking_tools_and_improvements/Feedback

• Prominent link to a page with more detailed questions about partial blocks? https://meta.wikimedia.org/wiki/Community_health_initiative/Partial_blocks/Feedback

I tend towards the two page approach because although most admins will set many more sitewide blocks than partial blocks and could have more to say about them, we have committed to gathering substantive information about partial blocks since it is a new feature. Unless you or others think it is too confusing, I suggest a two page approach.

That sounds good to me. We could also have a section about feedback for partial blocks on the main feedback page as that might be less confusing. I imagine the demarcation between Partial and Sitewide blocks might not be as clear to users as it is to us.
It would be great if you can setup the pages as you think appropriate. I will change the task to reflect the decision to link to the main feedback page.

@SPoore Do you want to set a template on https://meta.wikimedia.org/wiki/Community_health_initiative/Blocking_tools_and_improvements/Feedback like the one we have on https://meta.wikimedia.org/wiki/Community_health_initiative/Partial_blocks/Feedback?

Change 499781 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/core@master] Add feedback link to Special:Block

https://gerrit.wikimedia.org/r/499781

The patch links to https://meta.wikimedia.org/wiki/Community_health_initiative/Blocking_tools_and_improvements/Feedback, but it looks like this hasn't been created yet?

Is this feedback link temporary? If so, I can create a task to remove it.

Created now

After some discussion, it seems that we need to distinguish between WMF-specific feedback and general mediawiki-related feedback.

We can show the feedback link to everyone, and have it point to https://www.mediawiki.org/wiki/Help_talk:Blocking_users by default. We can then override this to https://meta.wikimedia.org/wiki/Community_health_initiative/Blocking_tools_and_improvements/Feedback via the WikimediaMessages extension.

Change 500100 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/extensions/WikimediaMessages@master] Add "block-feedback-url" override message

https://gerrit.wikimedia.org/r/500100

Change 500198 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/extensions/WikimediaMessages@master] Add feedback link to Special:Block

https://gerrit.wikimedia.org/r/500198

After more discussion, it seems there are concerns with adding any sort of feedback link in the core software. It's definitely worth resolving that question at some point, but since this task is blocking deployment to more wikis, and since we're (probably) more interested in WMF feedback in this case, it might be better to keep to the less controversial path.

Therefore, the latest patch adds the link to https://meta.wikimedia.org/wiki/Community_health_initiative/Blocking_tools_and_improvements/Feedback, for WMF users only.

In T212892#5065844, @gerritbot wrote:

Change 499781 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/core@master] Add feedback link to Special:Block

https://gerrit.wikimedia.org/r/499781

I've been asked to look at this. A few thoughts:

• Aside from what this particular task needs, most prior feedback mechanisms have been developed in a way that is short-term and WMF-specific. Hence onlookers tends to expect that for new feedback methods. That's not to say it has to be that way. But it's a good reason to think about what our requirements are, whether it needs to be in core, and (perhaps most important for other people) what the impact is of it being in core. Specifically, doing it in core is something we have very little experience with and may be hard to "get right".

• The typical way we do this sort of thing tends to be through a hook in the WikimediaEvents or WikimediaMessages extensions, or sometimes directly in products with a config flag that's off by default, enabled in WMF prod and Beta, and then removed again prior to stable release.

• Based on Thalia's last comment on Gerrit, it looks like getting feedback from third-parties could actually be desirable for this feature.

The third-party wiki ecosystem is quite large, and I think it may be undesirable to present a feedback mechanism there in a way that's always on and can't be disabled, especially when tied directly to WMF software development. I'm struggling to quantify why exactly (so perhaps I'm wrong), but it seems like something our community may not be expecting and MW has always made these sort of interactions opt-in. It might be useful to ask MW product managers in the Core Platform Team how they would feel about this kind of feedback loop existing in MediaWiki, and the best practices for it should be.

The other factor to consider is the release cycle. I imagine that we'll want to end this survey at some point. However, once part of the software and released, that won't be possible. MediaWiki 1.33 will not be released until June 2019, so that's when feedback would start. The next release MW 1.34 will go out in November 2019 which is when you could expect feedback to start slowing down at the earliest. With feedback ending no earlier than June 2020 when support for MW 1.33 ends. But it'd likely continue beyond as we know lots of wikis will continue to run it. See also https://pingback.wmflabs.org/#media-wiki-version/media-wiki-version-timeseries (Note, this data has a bias by only being collected from wikis where the administrator opted in during the installation process).

Regardless of where the code lives, I think at minimum it would make sense to disable by default via a configuration flag. Third parties could be encouraged to enable it in some way. If the June 2019-2020 range is reasonable, then CPT might be able to help facilitate the outreach around that.

Getting feedback from external MW installations was a nice-to-have and it sounds like we should drop that. Good point about the release cycle, @Krinkle. We're at the tail-end of the project here and won't be looking for feedback beyond a month or two. Hence putting it in core doesn't make sense. Also, as we are wrapping up work on this, we definitely cannot commit to working on all the feedback we might get from this. It feels disingenuous to ask for feedback with the knowledge that we will probably not be acting on it.

We're at the tail-end of the project here and won't be looking for feedback beyond a month or two.

@SPoore said that we wanted the link up for an indefinite amount of time, i.e. not forever but not short term either...

Change 500100 abandoned by Tchanders:
Add "block-feedback-url" override message

Reason:
Doing I45d39e34e3f80b instead

https://gerrit.wikimedia.org/r/500100

Change 499781 abandoned by Tchanders:
Add feedback link to Special:Block

Reason:
Doing I45d39e34e3f80b instead

https://gerrit.wikimedia.org/r/499781

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaMessages/+/500198

Change 500198 merged by jenkins-bot:
[mediawiki/extensions/WikimediaMessages@master] Add feedback link to Special:Block

https://gerrit.wikimedia.org/r/500198

On Special:Block and Special:Block/$username, there is a link to https://meta.wikimedia.org/wiki/Community_health_initiative/Blocking_tools_and_improvements/Feedback.

This also appears after submitting the form (successfully or with validation errors).

It appears for users even if they don't have the appropriate rights to create blocks.

Environment:
https://en.wikipedia.beta.wmflabs.org
MediaWiki 1.33.0-alpha (846d970)
14:25, 3 April 2019

Thanks @dom_walden!