All wikis except one have (theoretically) seen the message, while an other message has been posted on the page after the announcement, or a whole discussion happen there.

Message also sent to the Tech Ambassadors

Deployment scheduled for today's SWAT, 19:00 UTC.

On two wikis: "why it hasn't been announced? How can I get rid of it?". Those messages have been left on the same page where I've left the announcements.
Twice, an other user replied to the question asked about disabling the advanced filters.

I assume this task changed the appearance of recent changes. However, on English Wikinews, there is an important template which is now collapsed by default and the label reads "Other review tools" even when the tasks mentioned in that template are not limited to reviewers. Admins, or even normal users can make use of it. However, if the label says review tools, it is less likely to be clicked, and hence, it is counter productive. The Tech News says users can opt-out for the new filters. Instead of opting-out, it should be not there by default and let the users opt-in for it. Else, it hide crucial links for everyone -- moreover, anonymous editors would not be able to opt-out.

@Acagastya, you can override locally the label. Instead of having "Other review tools", you can labelled it "Community informations" or something else. MediaWiki:Rcfilters-other-review-tools is the message you can override.

The goal of that collapsed menu is to gain space to focus more on the results. The overall design, when the "Other review tools" menu is collapsed, is more compact than the previous design. Plus if you prefer to have it open, you just have to click on it and that setting will be memorized for your account.

82 users were trying the new filters as a Beta feature when it has been released, and I'm sorry no one reported that problem earlier.

@Trizek-WMF: the “more compact design” makes it harder for newbies to contribute. It hides one of the most crucial templates which contains everything from links to project policies, RFA, RFP, DR and articles to review.

Keeping it uncollapsed would not solve the problem for others who might think that template has been removed, or for newcomers or IP editors.

Provide an option to set it uncollapsed by default on the entire project, which users can later decide if they want to collapse it or not. (If option to rename is available, then it would be good to have n option to not collapse it by default, and let the project members decide if they want it collapsed or not)

It would not take a moment for those 84 users to collapse it if they want, but it would help newcomers and anonymous editors.

Contents listed on the collapsed menu are not related to recent changes. When you mean it "makes it harder for newbies to contribute", I think it is in the context of recent changes and I don't understand why: those elements are not all Recent Changes related or not actionable by them. They are more things people should know about, or a sort of dashboard to see all the activity on the wiki.

If you re-label the link, people will not have any problem to open it because the context will be more clear, and then discover the content.

Task update: concerning the other wikis, I haven't seen anything new.

@Trizek-WMF That dashboard helps knowing what kind of changes were made recently, knowing which articles needs expansion/peer review/protection … Since different projects implements these things in different way, I suggest to provide an option to set it uncollapsed by default … and as you have mentioned, one can choose what to do with it, and it will be saved, so just a simple by default uncollapse would solve the issue.

Hi all,

I think we are having difficulty communicating about this task at English Wikinews (on the list at P6067).

1. Consensus has been against the addition of the new RC filters for this wiki. It would be very much appreciated if this was heard and followed, even if blockers may not be identified.

2. Personally I suggested that the new interface makes it more difficult to

• select date range
• toggle filters
• view it (ui jumps are present - more information needs to be screenshot and drawn and commented to fully deliver this point, I will need to do it as soon as it is practical to do so)
• learn it with or without javasript (the ui looks much different with or without it)
• learn it for old users (They have to learn a new ui which they have not had a significant need in)

3. I question the research methods used to identify the usefullness of this tool. If users were given the new ui for filters perhaps they simply used it more because it was easier to spot on the page because it stands out. If we want to truly evaluate whether the new filters are useful then they need to also be introduced using the old ui and various techniques need to be done to make it stand out, and the choice needs to be made then.

4. At this wiki we have at least one person who is a regular recurring contributor who, while being a privileged user and valued content author, edits anonymously. Their computer prevents them from saving cookies after browser restart. As a result making the new filters "opt out if user is registered" would be a great difficulty for their editing.

5. As this is a small wiki, I would like to request a six months window for the discussion of this new feature so that contributors are not pressed to spend their valuable precious time on an active review of the vast number of features that are being proposed, and instead do the review gradually over a several months period.

6. User interface changes are important and I would consider it a blocker if we want anonymous contributors to see the classic 'Hide' 'Show' links instead of the new filters then this needs to be considered as I believe it is not too difficult to program this to be opt-in.

7. People who monitor RC already have a user account anyway so if they an improved RC then an opt-in link may be provided in a corner of the old interface.

8. We have not been given enough time to discuss these items above even among the people involved with the project, not to mention gaining consensus there about whether opinions of others coincide with my own.

I hope that some of this information is helpful to you in planning how to roll out this new tool while also keeping the ui consistent between different wikis run by the WMF.

Regards,
Gryllida

In T178990#4307009, @Gryllida wrote:

I think we are having difficulty communicating about this task at English Wikinews (on the list at P6067).

This ticket has been closed since November 2017 ! There have been multiple deploy phases of the feature set of this software and maybe you are referring to one of the later ones. Regardless, when a ticket is closed for this long, you should ALWAYS open a new ticket and then LINK to a ticket like this.

1. Consensus has been against the addition of the new RC filters for this wiki. It would be very much appreciated if this was heard and followed, even if blockers may not be identified.

As always, you can file a separate ticket, detailing which function (preferably the exact config optionname) you want disabled on which wiki and LINK to local wiki consensus. Add the Wikimedia-Site-requests tag as well as Edit-Review-Improvements-Integrated-Filters.

2. Personally I suggested that the new interface makes it more difficult to

• select date range
• toggle filters
• view it (ui jumps are present - more information needs to be screenshot and drawn and commented to fully deliver this point, I will need to do it as soon as it is practical to do so)
• learn it with or without javasript (the ui looks much different with or without it)
• learn it for old users (They have to learn a new ui which they have not had a significant need in)

• What exactly isn't working for you with the edit range selector. What functionality do you need specifically ? Have you filed a bugreport ?
• Saved filters allow you to quickly switch between your useful filter sets
• There should be no jump, unless there are watchlist notice (which already caused jumps before. Another reason might be that the filters span multiple lines. Unfortunately there is little that can be done about that right now.
• most people don't jump around between with and without javascript
• they got to start learning at some point, this point is as likely as one they delay another couple months.

3. I question the research methods used to identify the usefullness of this tool. If users were given the new ui for filters perhaps they simply used it more because it was easier to spot on the page because it stands out. If we want to truly evaluate whether the new filters are useful then they need to also be introduced using the old ui and various techniques need to be done to make it stand out, and the choice needs to be made then.

I have no answer to this other than that every research is open to being questioned. I do note that cost is like a prohibitive factor to some research.

4. At this wiki we have at least one person who is a regular recurring contributor who, while being a privileged user and valued content author, edits anonymously. Their computer prevents them from saving cookies after browser restart. As a result making the new filters "opt out if user is registered" would be a great difficulty for their editing.

Users that break their own browser setup are indeed not supported. There are limitations to what is possible. When you break the browser, then not being able to customize your setup exactly the way you want is one of the side effects of that choice. The user could choose alternative solutions, like software that uses a cookie/webstorage white/blacklisting.

5. As this is a small wiki, I would like to request a six months window for the discussion of this new feature so that contributors are not pressed to spend their valuable precious time on an active review of the vast number of features that are being proposed, and instead do the review gradually over a several months period.

The wiki does realize that time on this side of the equation is also valuable right ? 6 months in general will just be 6 months culminating in the last week something being discussed. But point 1 details how to switch the default for your wiki, and if that's what you want to do, just do it.

6. User interface changes are important and I would consider it a blocker if we want anonymous contributors to see the classic 'Hide' 'Show' links instead of the new filters then this needs to be considered as I believe it is not too difficult to program this to be opt-in.

This is not a requirement on our software stack. It is impossible to take every single persons preferences into account and actively harmful to our ability to maintain the software. Especially when people break their browsers to forget settings.

7. People who monitor RC already have a user account anyway so if they an improved RC then an opt-in link may be provided in a corner of the old interface.

That might be an idea. Patches are welcome.

8. We have not been given enough time to discuss these items above even among the people involved with the project, not to mention gaining consensus there about whether opinions of others coincide with my own.

Yes software development is very time intensive.... ;)

I hope that some of this information is helpful to you in planning how to roll out this new tool while also keeping the ui consistent between different wikis run by the WMF.

I hope that my answers as a volunteer, save WMF some time in answering this.

Dear TheDJ,

At English Wikinews we are being told a configuration change would be made by WMF even though local consensus (so far I think about 4 people had their say and said 'no') is against it. Surely this should not happen? I was assuming there is an open ticket somewhere and this is it.

Specific issues:

• the date range selector has been moved to a popup, making the date range harder to realize or modify
• the filters which are saved by default are not configurable per-wiki, or this was not made clear in the original message at the water cooler
• ui jump is present when the new rc filters interface changes from empty space with a throbber to its fully loaded pane
• when a filter is removed, if not saved, it is difficult to retrieve it back (requires user to type its name into a text box)
• RC filtering is more often used by logged in contributors than not, hence an opt-in mode could be preferred (at this wiki we do not have anonymous rc patrollers at present)
• perhaps 24 filters is too much, it would be nice to enable only some of them which are useful at this wiki (if this is possible this was not made clear in the original message at the water cooler)
• some people may prefer icon-free ui that is more similar to the current version but there is no option for this afaik
• research has not been done to show that "new filters + new ui" is more useful than "new filters + old ui"
• opt-out button is difficult to locate in the new interface

I would like to file bug reports, however Trizek has said 'you have not provided identifiable blockers to me' at least two times. I've took some notes of these and similar issues at the technical water cooler at English Wikinews but the issues that I was raising were dismissed by Trizek repeatedly... I am having great difficulty thinking of their possible reaction to bug reports in this situation.

I was assuming this is the correct open ticket where this situation could be brought up to the attention of the relevant project team. Perhaps I made a mistake in my bug search. Then which one is the correct bug where these issues need to be raised?

Regards,
Gryllida

In T178990#4309110, @Gryllida wrote:

Dear TheDJ,

At English Wikinews we are being told a configuration change would be made by WMF even though local consensus (so far I think about 4 people had their say and said 'no') is against it. Surely this should not happen? I was assuming there is an open ticket somewhere and this is it.

Ah I was mistaken, apparently this functionality is not planned to be disabled per wiki. I have no idea why this is, I don't see a good reason as to why this would be, though I assume it is to keep consistency accross the various wikis and because there already is a personal setting to disable it. I can't particularly comment on your interactions with Trizek, as you have not linked to them, and i'm honestly too lazy to go and look it up.

Specific issues:

• the date range selector has been moved to a popup, making the date range harder to realize or modify

You mean you need to do one more click to open a menu ? And that's a problem ? With the increasing complexity of the wiki software, it is inevitable that not all controls will fit on a page.

• the filters which are saved by default are not configurable per-wiki, or this was not made clear in the original message at the water cooler

They are configurable per person. Concerning the default per wiki I'm not sure if it is configurable. But again, if you want to deviate from the defaults, you are expected to invest in this deviation, it won't magically happen.

• ui jump is present when the new rc filters interface changes from empty space with a throbber to its fully loaded pane

Again, this should not be. If it is does, there is something wrong and you should file a separate bug ticket, preferable with screenshots or movies..

• when a filter is removed, if not saved, it is difficult to retrieve it back (requires user to type its name into a text box)

Click the trash icon, then 'restore default filters'. If you already customized (didn't save) and then removed a filter, then well, there is only so much that software can do.

• RC filtering is more often used by logged in contributors than not, hence an opt-in mode could be preferred (at this wiki we do not have anonymous rc patrollers at present)

no opinion on this

• perhaps 24 filters is too much, it would be nice to enable only some of them which are useful at this wiki (if this is possible this was not made clear in the original message at the water cooler)

Not sure if this is possible

• some people may prefer icon-free ui that is more similar to the current version but there is no option for this afaik

They can disable in their preferences: "Hide the improved version of Recent Changes", or later for watchlist, when the watchlist feature graduates out of beta.

• research has not been done to show that "new filters + new ui" is more useful than "new filters + old ui"

There is always something left to research i'm sure. We also have to move forward at some point

• opt-out button is difficult to locate in the new interface

They can disable in their preferences: "Hide the improved version of Recent Changes"

I would like to file bug reports, however Trizek has said 'you have not provided identifiable blockers to me' at least two times. I've took some notes of these and similar issues at the technical water cooler at English Wikinews but the issues that I was raising were dismissed by Trizek repeatedly... I am having great difficulty thinking of their possible reaction to bug reports in this situation.

And you let one person stop you ? I mean I may agree, but one person might be wrong. Just file the bugreports.

I was assuming this is the correct open ticket where this situation could be brought up to the attention of the relevant project team. Perhaps I made a mistake in my bug search. Then which one is the correct bug where these issues need to be raised?

It's not even open:

Again, I think that separate tickets are the best avenue in this case. Tickets are cheap, and can easily be merged or closed when they don't apply, or if there is already an open ticket about it. If that annoys the team, they should have left a better trace of their tickets, because even i can't find the right one ;)
I'd also advise to STRONGLY separate your personal opinions and comments from any community request you make. That tends to avoid long dwindling discussions where people need to separate these various aspects.

Dear TheDJ,

Thank you for your effort reading what I said. This is a lot of information and I am grateful to you for taking the time to read and reply in detail.

The conversation is here:

https://en.wikinews.org/wiki/Wikinews:Water_cooler/technical

As I understand the "community request" here is "please do not enable new filters, we do not find them useful/applicable at this wiki" (Pi zero, Gryllida, Koavf)

Identified issues:

Fixed:

• Issue with showing the 'Other reviewer tools' banner has been resolved (Gryllida, Acagastya, Pi zero) (consensus, sysop renamed a mediawiki:* page)

Can be filed bugs:

• A_1 Issues with recreating a parameter which was just removed - need it so that if something is different from a default, an option to toggle back is readily available (Pi zero, Gryllida) (bug may be filed right now)
• A_2 clicking 'back' does not restore the previous settings - needs clicking back twice (Pi zero; confirmed by Trizek) (bug may be filed right now)
• A_3 inability of IP contributors to change back easily (Pi zero)
  • add a "go back to classic interface" button which takes people to the login page with a hint at the top? (my personal suggestion, consensus unknown)
  • A_3.2 leave it opt-in rather than opt-out (confirmed by Kaartic , and by JMatazzoni see https://www.mediawiki.org/wiki/Topic:Uejs2f53w2otypma ) (consensus unknown) ) (bug may be filed right now)
    • opt-in mode is preferred at this wiki because it does not have anonymous RC patrollers (my personal concern)

Consensus unknown:

• B_1 list of which filters to display by default is not customizable per wiki (me + Pi zero) (community consensus needs to be checked)
• B_2 issue with ui jumps has not been resolved (bug may be filed) (my personal concern) ( consensus unknown)
• B_3 issue with loading time has not been measured (bug may be filed) (my personal concern) ( consensus unknown)
• B_4 issues with the ui appearance have not been resolved (bugs may be filed) (my personal concern) ( consensus unknown)
  • dates moved to a pop-up
  • filters difficult to toggle
• B_5 list of which filters to enable or not not customizable per wiki (my personal concern) ( consensus unknown)
  • "I've just spent a pile of time struggling with the new interface, trying to accomplish the simple task of changing the view to exclude my edits. With much effort and time, I failed to accomplish the objective. The point is not that I want help figuring out how to do it (why would I bother? manually altering the url is easier to do and can be undone easily and reliably); the point is that the new interface being hard to figure out means, by definition, the interface is badly designed." (Pi zero)
  • I think this is a valid bug, needs to be formulated
• B_6 a lot of how this behaves relies on settings of logged in users, leaving anonymous users helpless - is it better to have it opt-in for those who log in (my personal concern) (consensus needs to be checked)
• B_7 No UI is shown initially, only white space and a throbber. Since this is server side code, it is possible to generate the buttons for the ui on the server side so that they are available to me the same instant I load the page. (my personal opinion) (consensus needs to be checked)

As you see, with a lot of changes, we do not know yet whether they are the issue, or the issue is something else. We need to identify why people are against this change. This is best done by asking them what they dislike and looking at their interests without saying 'hey we have no identified blockers' and suggesting a rushed deployment.

I would be glad to file bugs gradually after consensus is identified.

It would also be nice to delay deployment until consensus is reached. If we have enough technical staff to develop this feature, then there needs to be enough staff (and time) to negotiate a consensus, I believe. Perhaps the development of A_3.2 is a good way to resolve this situation.

This message has also been added to https://en.wikinews.org/wiki/Wikinews:Water_cooler/technical#Summary_2018-06-25 .

@TheDJ, thank you for offering help, while my offers to give them tour of the tool, or my requests to get actionable feedback so that I can reproduce bugs have been ignored by that community. I wish you a better success.

@Gryllida, our conversation has been pleasant so far, so I'm unpleasantly surprised to read this:

A_2 clicking 'back' does not restore the previous settings - needs clicking back twice (Pi zero; confirmed by Trizek) (bug may be filed right now)

The question was about displaying 50, 100, 500.. edits on the list of results. I've confirmed that it is now needed to click on the date and number of edits menu, and then select a range, everytime you need that. I've never called that a bug. Please don't say that people "confirm" bugs when there is no clear statement about that, like in "yes, that's indeed a bug". That desserves your speech.

Please fill new bugs. That one is closed and archived.

Dear Trizek,

I've responded to both points -- the back button clicking, and the 'confirmed' bug claim -- on wiki.

Regards,
Gryllida