Wikinews:Water cooler/technical

From Wikinews, the free news source you can write!
Jump to navigation Jump to search

Refresh

Archive, post


2009 
2010 
2011 
2012 
2013 
2014 
2015 
2016 
2017 

January 2018
February 2018
March 2018
April 2018
May 2018
June 2018
July 2018

RfC: Plans to graduate the New Filters on Watchlist out of beta[edit]

Collaboration team is announcing plans to graduate the New Filters for Edit Review out of beta on Watchlist by late June or early July. After launch, this suite of improved edit-search tools will be standard on all wikis. Individuals who prefer the existing Watchlist interface will be able to opt out by means of a new preference.

The New Filters introduce an easier yet more powerful user interface to Watchlist as well as a whole list of filters and other tools that make reviewing edits more efficient, including live page updating, user-defined highlighting,the ability to create special-purpose filter sets and save them for re-use and (on wikis with ORES enabled) predictive filters powered by machine learning. If you’re not familiar with the New Filters, please give them a try on Watchlist by activating the New Filters beta feature. In particular, it would be very helpful if you can test the new functionality with your local gadgets and configurations. The documentation pages provide guidance on how to use the many new tools you’ll discover.

Over 70,000 people have activated the New Filters beta, which has been in testing on Watchlist for more than eight months. We feel confident that the features are stable and effective, but if you have thoughts about these tools or the beta graduation, please let us know on the project talk page. In particular, tell us if you know of a special incompatibility or other issue that makes the New Filters problematic on your wiki. We’ll examine the blocker and may delay release on your wiki until the issue can be addressed. - -Kaartic (talk) 17:22, 5 June 2018 (UTC)

Let me know if there's a better place to post this. - -Kaartic (talk) 17:23, 5 June 2018 (UTC)
@Kaartic: Is this related to the godawful screw-up change of the RecentChanges interface that was forced on us a few months(?) ago? (This all makes me very sad.) --Pi zero (talk) 17:42, 5 June 2018 (UTC)
@Pi zero: Yes, this is a change similar to a recent update to the recent changes. I'm sorry these changes make you feel sad. Could you please elaborate on what makes you feel about the change? It would be helpful in assessing whether this should be held back. Also note that, you could opt-out of both the Recent changes update and the upcoming update to the watchlist if you want to. - -Kaartic (talk) 13:03, 6 June 2018 (UTC)
@Kaartic: Well, fwiw, some thoughts.
  • About RC.
  • To be clear, I don't claim the old interface was perfect. There are generally things one might wish to tweak, about such things. (When I laid out the Wikinews:Breadboard, with similar-though-different functionality to Special:ExpandTemplates, I turned the layout upside-down, with display above and input below.)
  • There was a significant loss of functionality in the change; I don't know what-all was lost, or whether some things are really still there if one knows suitable tricks to get at them, but I do know that one of the things I would most often shift over temporarily was to suppress my own actions from the display, and after the change I was only able to make that happen by trying it on another project that the change had not yet been applied to, and examining the url to see what parameter was doing it, then manually adding that parameter here. Eventually I suppose I'll lose the ability to do it entirely, as I'll no longer be able to remember enough to recreate that parameter.
  • The new interface causes persistent changes within a single panel view, making it hard to shift to a variant view temporarily and then go back to the way things were. For example, each morning when I get up I want to look through everything that happened since I last checked RC the previous evening, and I used to (often) temporarily shift up from 50 changes to some larger number; and when I was done looking through that history, I would simply click the "back" button on my browser and be back to the usually 50-changes display. I can still achieve that, by bypassing the new interface again, manually editing the url to increase the limit parameter and then using the browser's "back" button when I'm done.
  • English Wikinews has an extensive customized display at the top of RC, including some important status information. It's provided as, and used by some of us as, a primary view of the project. Frankly, that customized information is generally more important than the clutter of (also now less effective) controls taking up vertical space now. And that information is meant to be instantly visible to IPs with no prior knowledge of the project. Yet the new interface hides that important information, requiring someone who knows the project well enough to know to go out of their way in order to make it visible, and takes up vertical space for less important controls that are likely to be rarely used.
  • A digression about the meta-picture here (because resistance is futile). When I sad "this all" makes me sad, I wasn't referring merely to these specific changes. In the process of improving things, stuff changes, and not every change is going to be to any particular person's liking. I might be "sorry" but not so much "sad" to see some mixed results as part of general changes for the better. As I've become attuned to the long-term trends of the Foundation's behavior, I've realized that the underlying conceptual framework that motivates the Foundation's strategic decisions is deeply flawed, with pervasive influence (sometimes subtle, sometimes not so much) on the tactical changes made to the platform over time. Absorbing inconveniences in a good cause is different from absorbing inconveniences in a bad cause. Add to that the insight that (as with the world at large) nearly all the intentions involved are good, and the realization that the Foundation's conceptual framework is highly robust against outside tampering with their beliefs. And that's where the word "sad" is coming from.

    When I first came to Wikinews I thought the oldtimers here were awfully paranoid about the Foundation. That was nearly ten years ago. I no longer think they were paranoid. I mostly don't try to object to whatever is the latest bad news about what the Foundation has decided to do to us on the non-Wikipedian sisters, having concluded they fundamentally don't care about helping non-Wikipedian sisters generally, and are willing in particular to go out of their way to avoid doing anything that might be helpful to Wikinews. My software development for the wiki is designed to avoid giving the Foundation any avoidable oversight, and to be as robust as I could reasonably arrange against future unfortunate design changes to the platform. On the other hand, when the recent changes to RC negatively impacted us, one of our more recently arrived Wikinewsies, not yet so cynical, raised some objections (I think that was at phabricator, where I have no voice since, in order to set up an account there, I'm asked to agree to some sort of obscure sharing of private information that I do not trust); and was given excuses why their objections were being dismissed.

--Pi zero (talk) 16:40, 6 June 2018 (UTC)
Hi Pi zero. Just to chime in re. your comment that "There was a significant loss of functionality in the change," I don't believe that is accurate. The New Filters were designed to provide parity with the old functionality in all ways—while providing a lot of completely new tools and capabilities. You mention the ability to suppress your own actions: To accomplish this with the new UI, open the main filtering menu, scroll to the "Contribution authorship" section and check the box for "Changes by others" while leaving "Changes by you" unselected. If that's your default mode, click the bookmark icon to save a filter set and then select the box for "Make this my default."
It's possible that what confused you about this is that the logic of the new filtering interface flips the previous logic. In the past, one selected filters based on what one wanted to "hide" (e.g., "my edits"). In the new UI, one selects what one wants to include (e.g., "changes by others"). While the new logic may seem strange at first, once people try it they usually find that it's quite familiar from big web sites like Amazon.com that also let you select filters to refine search results. I hope you'll give the new UX another chance, but if you prefer not to, you'll be able to opt out and reinstate the old UX. —JMatazzoni (WMF) (talk) 22:27, 6 June 2018 (UTC)
@JMatazzoni (WMF): The two putative remedies you mention appear irrelevant to the practicalities I described in my critique of the RC interface. The ability for an experienced user to opt out, for instance, is irrelevant to what IPs see; if I am able to opt out of an "upgrade" that cripples our ability to provide help to ordinary contributors, my opting out doesn't uncripple us. I see nothing in your remarks that bears on lightly checking-and-then-undoing variant displays. I also, btw, see no particular significance in whether one describes something in terms of hiding versus including; but whether the controls to do things are out in the open where they're easy to see and understand, or buried down in some ponderous device that a user with a sense of self-preservation wouldn't want to touch — that matters. --Pi zero (talk) 23:16, 6 June 2018 (UTC)
Pi zero, concerning the information on top of the RC page, you can move all messages to mediawiki:recentchanges-summary, so that they will always appear on top of the page. MediaWiki:Recentchangestext should then be used only for things related to the RC page. Trizek (WMF) (talk) 14:06, 8 June 2018 (UTC)
That works, for the third of the three criticisms I'd listed. Thanks. --Pi zero (talk) 15:35, 8 June 2018 (UTC)
Your two other points are more personal than global, that's why I haven't replied in details first. :)
Concerning the first one, I can certainly help you at finding the missing features. Please use my talk page and details cases you have, I'll reply on Monday.
Concerning the second one, you will need two clicks instead of one to switch back to 50 edits display. As a volunteer, that has bothered me during the first minutes testing the filters on my watchlist but now I can afford to click twice instead of once and benefit of all other functions I now appreciate.
Have a nice weekend, Trizek (WMF) (talk) 17:47, 8 June 2018 (UTC)
I understood myself to have been asked my criticisms of the interface. I offered them. We're in agreement that the third point was the one of broadest import. On other aspects of the interface, though my criticisms stand, I see these details as largely distractions from the larger principle that the design of such interfaces should be grown by the local communities within the scope of wiki markup (and that's been the focus of my software development efforts on-project for years now; cf. essay).

A good weekend to you, as well. --Pi zero (talk) 18:09, 8 June 2018 (UTC)

@Trizek (WMF): Some further thoughts on the interface, fwiw.
  • Number of clicks can fail to capture important aspects of ergonomics, one of which is error-proneness. Part of my point was that, under the old interface, when I was done with whichever variant view I'd been looking at and wanted to go back to the usual view, there were no complicated decisions to make and it was well-nigh impossible to get wrong. It wasn't even necessary to remember how I'd gotten to the variant view in the first place, nor to remember, conversely, details of what I was trying to get back to.
  • 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 (talk) 16:58, 9 June 2018 (UTC)
Thank you for your reply and your critics, Pi zero. I appreciate them and the nice conversation we have.
I've offered to provide you some tips, if you wish some, like when you enter a new house and you're told where are the restrooms or the furnace. If you've found what you were looking for by yourself, that's the most important. Other people may have a different experience, and the most important for us is to provide a tool that works for the majority of users and readers.
Feedback we had, both from the 3 design testing phases and the numerous feedback from users across the wikis, haven't raised the points you raise. Honestly, I've seen two kind of feedback on the feedback places: most feedback was about bug fixes and local scripts incompatibilities (we've replied to most of them), some people asked for a bit of assistance because the interface is new, and a very few people who were just against the change by principle and wanted to opt-out immediately without giving a try to the new filters. Overall, I think people appreciate the interface.
I appreciate that you gave a try to the filters and provided some thoughts about how the design should be, but, for now, I'm afraid I can't offer anything more than guiding you (BYW, to exclude your edits, click on the menu for filters "Filter changes" and, on the list of filters, select "changes by others").
Trizek (WMF) (talk) 08:43, 11 June 2018 (UTC)
@Trizek (WMF): Fwiw, some thoughts on the sort of feedback you're talking about. Really good designs cannot be produced by majority-based response to feedback (one should say, not by that alone); vision is required, and real success must always come down to whether somebody has the right vision or the wrong vision, with no vision being reliably an unrisky way to be wrong; and in even interpreting feedback at all one has to aggressively consider how the feedback, especially on a statistical basis, can be misleading. For example, who does and does not give the feedback, what biases are they going to bring to it, what may be lurking amongst those who don't provide feedback, and what do those who provide feedback know, or think they know, about what they're critiquing? If people expect feedback to be pointless, they won't give it; and there you're up against both people's perceptions that you inherit from all other software contexts they've dealt with, and the Foundation's reputation (which, I have to say, is horrible amongst the non-Wikipedian sisters, deservedly, having been earned through consistent bad behavior since right about the time the position of Executive Director was created). If people don't know how to give feedback, they won't. If they don't have deep insight into interface design, they won't be able to offer any but superficial feedback. For whichever reason, it's entirely possible for important principles to be not mentioned at all in feedback, or at best mentioned by one person (and that much more likely if the individual is atypical of those providing feedback, directly opposing any majoritarian interpretation of feedback). --Pi zero (talk) 18:12, 11 June 2018 (UTC)
Concerning how to collect feedback, we do our best to get comments: from the Beta page, from all newsletters and messages left on the wikis, directly from the interface as far as it is possible. We also ask people directly: people who are interested by a given topic or a given problematic, and of course random volunteers who are offered to test things. People who opt-in Beta features do that on a page where they've an option to provide feedback. When they've opted-in for all Beta features by default, they notice changes and have a pop-up offering them to provide feedback. We also know our limitations: it is not possible to have feedback from everyone, across all wikis and all languages. We work on those weaknesses, like the language gap (we welcome comments in any language) or new ways to ask for direct feedback about actions (micro-surveying). In any case, when I receive feedback, I dig in and ask for clarifications and more details. That's also a way to identify implied issues that were not identified by the first comment received. We are far away from the initial discussion, but while that's more about my daily job, that's fine. :) Trizek (WMF) (talk) 08:32, 13 June 2018 (UTC)

┌─────────────────────────────────┘
 looks like it is the right time to share the link for the phab request.
•–• 08:52, 11 June 2018 (UTC)

While real time updating of watch lists is nice I do not always keep the recent changes list open in a separate tab. Instead I have implemented a user script which shows recent changes below the footer of each page, and -- only when single clicked -- it updates. User:Gryllida/js/showRcAtPageEnd-0.1.js For me at this wiki this has proven to be an effective strategy for monitoring recent changes each day and each hour at some points, I recommend that you experiment with something similar and do not include the recent changes live feed in the present form. --Gryllida (talk) 02:19, 6 June 2018 (UTC)
As Gryllida has started a thread in the project talk page, let's keep the conversations there. - -Kaartic (talk) 13:03, 6 June 2018 (UTC)
Kaartic I doubt the people here would be willing to use Flow. You may wish to continue looking at this discussion. Gryllida (talk) 21:54, 7 June 2018 (UTC)
@Kaartic, Gryllida: Flow is inappropriate for serious discussion. --Pi zero (talk) 22:55, 7 June 2018 (UTC)
Gryllida, I've created T196739 with your suggestion. - -Kaartic (talk) 13:15, 8 June 2018 (UTC)
(Just to make it clear I Oppose addition of the new recent changes feed ui to this wiki. If consensus is considered here.) --Gryllida (talk) 21:58, 7 June 2018 (UTC)
I too Oppose, fwiw. --Pi zero (talk) 22:55, 7 June 2018 (UTC)

I personally don't like them, so Oppose unless it's somehow critical. I would prefer if we could have the option of both. —Justin (koavf)❤T☮C☺M☯ 00:01, 8 June 2018 (UTC)

@Koavf: There is an option of both. To be clear, you can still use the old Special:Watchlist UI is not going away (neither has the old Special:RecentChanges UI). You can opt-out of the new feature via Special:Preferences if you want to. You could also opt-out via the message you would see above Special:Watchlist after the first time you visit it after the update. To add to it, you can opt-back-in if you think you want to give the new UI a try. - -Kaartic (talk) 12:55, 8 June 2018 (UTC)
@Kaartic: Not claiming to speak for Koavf, and to avoid possible misunderstanding: my point concerned the RC interface for IPs and newcomers as well as for experienced users, for which opt-out has no bearing. --Pi zero (talk) 13:38, 8 June 2018 (UTC)
@Pi zero: I'm asking other people about whether there is an option to disable the feature per-wiki. I'll let you know about how the discussion concludes. - -Kaartic (talk) 14:03, 8 June 2018 (UTC)
Anyone (except IPs) has the option for both: they can opt-in filters on RC and not on watchlist, or the opposite, or have them on both or none. Have the filters for everyone by default is a good practice for consistency across the wikis.
Please elaborate on special incompatibilities or other issues that makes the New Filters problematic on your wiki from a technical perspective, preferably as bug reports. We’ll examine those with attention. Trizek (WMF) (talk) 14:06, 8 June 2018 (UTC)
There are issues.
1) You have not asked what changes we need. To my liking we don't need any. I don't change RC display filters frequently, and addition of large clunky ui to perform RC display filtering is akin to adding a new monitor to the work station of a blind person.
2) Perhaps if you introduce this change while leaving clicky links as they are now -- without adding large chunky buttons there -- it could pass more comfortably; however I would still be concerned about the CPU impact on IP contributors whose computer is slow.
3) We have one incredibly valuable contributor here who frequently edits as an IP due to Internet and privacy issues, and their productivity would be impacted by this change. They are a privileged user who volunteered to participate in the core tasks of original reporting and peer review, and losing them would be a major inconvenience for the project. --Gryllida (talk) 21:09, 12 June 2018 (UTC)
Thank you for your message Gryllida. I need some clarifications on the points you raise using your personal experience, because I don't see any technical blockers described there.
You mention the "large clunky ui", without examples of blockers. You see it as large, despite the fact that it is less high than the previous Recent chances interface. For Watchlist, the new interface takes a bit more space on a large screen (not on a narrow one) than before. To change that, extra blank space will be removed soon, and a way to collapse the commands will be provided (for the case when you don't change filters frequently). The interface aims more compact and will become even more compact, with commands built to be more accessible (more contrasts, margins, etc.) than the previous one.
Some users have reported performance issues on their computer. However, in most cases those users had some personal scripts installed that. When those scripts where inactive, the performance issues were gone. We also have unresolved cases on the centralized feedback page, where people haven't replied to the issues the pointed out. In any case, we have taken those feedback seriously and provided some fixes. We have also checked performances on old computers without significant blockers (I run my own tests on an old Dell Inspiron 1520 from 2007 -- when it starts).
Can you provide details about that IP who would be impacted by the filters on watchlists? Can that person explain to me directly the issue they are facing and how the filters on Watchlists? Unless you're referring to filters on Recent Changes, that are default since September 2017? We don't want to see the filters blocking someone from contributing for technical reasons.
Thanks, Trizek (WMF) (talk) 08:32, 13 June 2018 (UTC)
1) The ui change requires my labour to learn it. It would be nice to have an option of avoiding this labour. Please add an option for using a ui which corresponds to what was used before (clickable links not buttons).
2) Live feeds are not used by majority of people at this wiki. Adding them, even without adding ui changes, would be akin to adding a new monitor for a blind person.
3) The JavaScript issues are not only that of performance. It is also an ethical issue: I would not like my personal computer to do computing which I do not need. I have uMatrix installed to control that, and if you add the Recent Changes Live Feed, then I would be obliged to blacklist it.
4) Also I dislike ui changes introduced after the page started loading. For example, when VisualEditor loads, some page elements move around after they have already been displayed once. This is terrible. This is the case with the Recent Changes Live Feed, it takes more higher space than initially when the page begins to load. This requires me to move my eyes to resume reading a line which was already visible at the screen.
5) I dislike icons. Text is better. 'Hide anonymous users' vs 'Show anonymous users' is easy to read.
6) After toggling something in the old interface it is very easy to toggle back. In the new interface this requires typing the name of the thing into a box by hand. This is inconvenient. Maybe it is my first time and I misclicked and I do not even remember what I clicked.
7) The new interface seems more compact, but in fact it hides the num of edits and dates away into a button at the right. This makes them harder to find.
8) I am not sure whether the contributor would be willing to clarify their concerns. The last time I asked, they weren't (see the last section on my talk page, which has a link to the past discussion). --Gryllida (talk) 02:54, 14 June 2018 (UTC)
I'm sorry, but most of your feedback can't be considered as technical blockers.
About icons and time-and-date menu, and like on any new interface, it requires a time for adaptation. It is like getting used to a new home or a new car. That's also why a Beta period is provided: to give you time to try new tools and provide feedback.
Live feed (if I understand correctly what you are referring to) has no obligation to be used. Live updates is a button you have to click on to get it activated, and the "Show newest changes" link is offered with no obligation to be used. You can click it when ready to see new changes, or don't use it at all to reload the page manually. That's up to you. Both live updates and "new changes" link will add new changes to the list of results, visually separated by a line from the previous ones, only if you ask for them.
If you don't use javascript, you will get the old interface, without all added options. Those options were built using JavaScript because that's was the best option, according to developers, to add more interactive functions that would fit the tested design. Concerning performances, we investigate report of slow Watchlist load times. While there is no broken scripts on your wiki or your account, that's not a blocker.
However, you raised two points that may require more attention (while they are not blockers):
  1. what is that issue with the visual editor? How can I reproduce it, can you give me the steps? Can you show how the page looks like to you? Do you have that issue if you append safemode=1 at the end of the editing URL? That's not related at all with the new filters, but I can't let you with something you think is an issue.
  2. concerning your point #6, to witch menu/tooltip are you referring to? How can I reproduce it, can you give me the steps? That may be related to the interface adaptation time.
Concerning the IP contributor, I'm sorry I can't do much more is I don't get more clarifications. If blocked, that person can setup an exception for Special:RecentChanges on its browser's JavaScript management settings that will fallback the filters to the old state.
Thanks, Trizek (WMF) (talk) 09:53, 14 June 2018 (UTC)
Hello Trizek,
  1. Look and feel are important and need to be addressed before this tool graduates.
  2. I am glad if the live feed feature itself is an opt in.
  3. I am glad if the ORES highlighting still works with JavaScript disabled. Does it?
  4. I will need to make several screenshots of ui jumps.
  5. Sorry Trizek but I fear that an icon-less ui version, which corresponds to the current interface, needs to be created before this tool graduates.
  6. Hard to toggle back - I thinbk you did not address this.
  7. Dates harder to access - I think you did not address this.
  8. Anonymous contributor - please see their responses on my talk page at the end.
  9. Some extra items may be missing here, which may or may not be found in the discussion above.
This leaves one todo item for me (#4), I'll supply it to you soon.
Again thanks for considering everything Trizek, it is really appreciated.
And please see some extra questions below as I am gradually trying to become more familiar with this tool and suggest a more gradual deployment (if anyone wants it - this needs time to think). Gryllida (talk) 02:15, 16 June 2018 (UTC)
Hello Gryllida
  1. Look and feel scientifically measured for all users, across all wikis, yes. Using your personal opinion only as a blocker is unfair. :)
  2. It is. I regret that you haven't reflected that on your questions below.
  3. As I told you, "if you don't use javascript, you will get the old interface, without all added options". If JavaScript is disabled, you will get the filters like they are now by default (that's the same as opting out the filters). ORES will work, with a less precise accuracy while we can't user the filter to display the different states of predictions.
  4. Please. :)
  5. Sorry but see my point #1. If that's only for you (as in "you" personally or "your community"), you will need to find an alternative. That request is not a technical, measurable blocker.
  6. I don't get that "hard to toggle back". The conversation is long and I may have skipped a point, sorry. Can you clarify again? Or is that what I've been asking you for clarifications on my previous message (you skipped my two questions there).
  7. That's not a feedback I've get on the central feedback page (I've checked quickly and found nothing), so I assume that date and number of edit filtering is specific to you. See my point #1 again.
  8. About the Anonymous user, the only comment left by an IP on your talk page is that one, unrelated.
The gradual deployment is not an available option since:
  • the filters on Recent Changes have been deployed for everyone last September on all wikis,
  • we get no feedback since then from your wiki,
  • the filters are on Beta on your wiki since September, used by +120 users, so that people can try them as they wish.
We keep an option for people who want to keep the Watchlist as it is now, without the filters. Please consider that option when the deployment will be done while the filters apparently don't fit your personal needs. We are not forcing you to use them at the end. Trizek (WMF) (talk) 14:42, 18 June 2018 (UTC)
Trizek (WMF) Hello and thanks for your interest. I may indeed have overlooked some points as I am not really feeling well this winter in Sydney. I am struggling to fix several severe long overdue hardware problems at home while I am also trying to get some rest. Today morning my home laptop fan went out. It may take me a while to get new data that you need.
However about 'toggle back' for example recent changes includes a button to 'HIDE anonymous users' (where Hide is a link) and when clicked it switches to say 'SHOW anonymous users' (where the 'Show' is a link to toggle it back) With the new interface I tried it briefly and I found that when some filters are clicked they simply disappear from the list of filters and re-adding them requires me to remember the name of the filter and type it into a text box below. I will most certainly try to add the ui jumps information as soon as it is practical for me to do so (the hardware failure has also prevented me from doing trip arrangements for early July, this would perhaps also have a higher priority). --Gryllida (talk) 02:12, 20 June 2018 (UTC)
Thank you for that feedback. While we are in the middle of the conversation, I'll reply in a separate section below. Trizek (WMF) (talk) 14:42, 20 June 2018 (UTC)
@Trizek (WMF): Quoting from your #1 "Using your personal opinion only as a blocker is fair." Am I reading it correctly? Is using a personal opinion as a blocker a fair thing? Or am I misunderstanding the meaning of 'fair'? - -Kaartic (talk) 18:12, 18 June 2018 (UTC)
That's a typo from me, thank you for spotting it, Kaartic. I meant "unfair". I think using a personal opinion or a guts feeling as a pretext to block a deployment on all wikis as a wrongful way. This is why I'm asking for actionable blockers based on issues I can reproduce or on data. Not feedback like "I feel like that feature is perceived as [reason] so it should be removed for everyone" or "I personally can't do [action] anymore so it should be removed for everyone" I can sometimes read on other wikis. Trizek (WMF) (talk) 12:37, 19 June 2018 (UTC)
Re, the anonymous user one the talk page: I suppose Gryllida (t · c · b) is referring to replies of Acagastya (t · c · b) in User_talk:Gryllida#"Internet_and_privacy_issues"_when_contributing_using_an_user_account_? - -Kaartic (talk) 18:28, 18 June 2018 (UTC)
Just as a matter of general interest, regarding "we get no feedback since then from your wiki". Sorry if this comes out sounding overly negative, but I see a fundamental error in interpretation going on here, and know no other way to point it out. I have been a contributor to non-Wikipedian sisters for about a decade, and I'm aware of the progressive pessimism and giving up on the Foundation that is beaten into such contributors over years by the way the Foundation disses non-Wikipedian sisters. People like me almost never bother to try to provide feedback, because we know it will be ignored, only wasting time and effort we could have better spent by treating the changes forced on us as natural disasters, after which one cleans up as best one can and tries to find a way to live with the consequences. However, as I think I may have mentioned somewhere above, one of our more recent arrivals here, not yet as far along the curve as I, did try to point out that the change to RC was causing problems here (somewhere; maybe on phabricator?), and met up against a sampling of the vast arsenal of excuses the Foundation has accumulated for ignoring feedback they don't want to hear. Including, 'but we haven't heard a lot of complaints', as if that were evidence of success of the particular feature, rather than being equally well accounted for by long-term evolvution techniques for stifling unwanted feedback (including, teaching people like me not to give feedback).

I see, btw, the phrase "Look and feel scientifically measured for all users, across all wikis". I wanted to say something along the lines of "You don't actually imagine it's possible to scientifically measure look and feel, surely" — but I'm very much afraid that you do imagine it's possible. Misplaced faith in formal methods, machine learning, and the like seems to me one of the most dangerous trends in the world today. --Pi zero (talk) 19:21, 18 June 2018 (UTC)

┌─────────────────────────────────┘
 How can you possibly expect complaints from the editors who are not from Wikipedia because there has been hardly any importance given to non-Wikipedia projects when it comes to listening to them. Editors like Pi zero and Gryllida spend their time developing the tools which the developers should be providing us.
•–• 19:28, 18 June 2018 (UTC)

Acagastya and Pi zero, I'm listening to your community. Alas, for now, the conversation implies that you want to have the whole wiki opting-out. Create an exception like that is not possible both for maintenance and coherence across wikis. It seems that your community doesn't accept that, and you are the only community pushing back.
Since I've started to write here, I try to explain how and why decisions have been taken for that tool, and help you to integrate the new filters the better way. There are workarounds, like editing system messages or, for people who don't like the tool at all, select the opt-out option in their preferences. I'm just looking for clear questions and needs, or issues I can reproduce myself, so I can help you. I've asked for that quite everyday with nothing actionable. I'm spending a lot of time to give you the best experience concerning that new tool (that has been released on RCs months ago).
Overall, on my job, I spend a lot of time on sister projects doing my best to connect developers and users. I don't like when a feature is done only for Wikipedias, especially if that's only for English Wikipedia. I'm sorry that there is no resources to specifically help you. I'm for doing things that would help the maximum of wikis. You may not be aware of that, but say that I'm focusing on Wikipedia-only is not accurate.
I understand that your community can have a certain frustration based on past interactions, and I regret it impacts our current ones. Trizek (WMF) (talk) 12:37, 19 June 2018 (UTC)
If it is not "Wikipedia-only" -- the time will tell, that discussion is not going to bring any good outcome. But in all fairness, I had raised the concerns seven months ago.
•–• 12:46, 19 June 2018 (UTC)
I see your concern. I also see that it was clearly addressed with possible solutions. One of the solutions stated there seven months ago was re-stated in this discussion a few days ago and was used to solve your concern. Am I misunderstanding that. - -Kaartic (talk) 13:30, 19 June 2018 (UTC)

Research details[edit]

Kaartic and Trizek (WMF): the research conducted is unclear. Conclusions are provided but the mechanism of conducting the research is not detailed very much, and it is unclear which of these conclusions apply to which wikis and in what languages. Could you please clarify that? --Gryllida (talk) 02:15, 16 June 2018 (UTC)

You should ask that on the Research talk page. That's the dedicated place, and it makes is easier to keep track of that new discussion. Trizek (WMF) (talk) 14:00, 18 June 2018 (UTC)

Machine learning and highlighting (ORES)[edit]

Question[edit]

Machine learning and highlighting might improve productivity here. Kaartic and Trizek (WMF) please detail how to use it. Does ORES learn from each wiki separately or not? Can we try it as a beta feature separately without the live feed? Gryllida (talk) 02:15, 16 June 2018 (UTC)

Machine learning (ORES) is not available on your wiki. You can try it at English Wikipedia. What are your questions about ORES, precisely?
Concerning Highlighting, I'll give you an example. Enable the filters in your Beta preferences, and click on that link. Don't change the filters configuration I've shared. Please tell me how do you know which edits are done by newcomers (less than 4 days on the wiki or less than 10 edits) and which ones are made by "learners" (not newcomers, but with less than 500 edits and 30 days of activity). Then do the same thing with the same conditions, using that link.
I assume that "Live feed" is when you reload the page clicking on "View Newest Changes" or when clock on "Live updates". Any of the filters work without them. Trizek (WMF) (talk) 14:11, 18 June 2018 (UTC)
Hi Trizek. What material does ORES use for learning -- only from this wiki or from several? Can ORES be added without adding the improvements to RC filter ui? Gryllida (talk) 03:28, 20 June 2018 (UTC)
Hi Gryllida - ORES models used on RCs and watchlists are specific to your wiki. If you want to have the service, the community will have to train ORES, by checking diffs in a specific tool. The models you will train could be used without the improvements, but, as I've already explained, with much less precision (only obvious vandalism would be highlighted). Trizek (WMF) (talk) 11:25, 20 June 2018 (UTC)
Trizek (WMF) do we have the option of deploying ORES and new filters here without the live feed and without the new filters ui? That is, deploy everything, but do not load the javascript which adds the new ui and new live features. This would make the software behave in the same manner as if the user had JavaScript disabled. Gryllida (talk) 06:42, 22 June 2018 (UTC)
Trizek (WMF) can we choose what filters to add and what new filters to not add? Is there a list of the new filters? Is it configurable per-wiki? Please advise. Thank you. --Gryllida (talk) 06:45, 22 June 2018 (UTC)
It is possible to get ORES if you do the trainings to feed that IA, please check the documentation about that. ORES will then work on both the new and old UI, no matter if you have opted it in or out. Again, you can opt-out in your preferences. We are not going to opt-out the entire wiki while you haven't shared actionable blockers.
You can create new filters if you want; that's a bit technical. Which filters are not usable? Yes, there is a list, in the documentation we provide. They are standard on all wikis. Trizek (WMF) (talk) 16:40, 22 June 2018 (UTC)
Thanks for this list. I think you can see that reading documentation about such a complex feature set is not easy for me. You sharing a link is really appreciated. Which items from this list are already present in the current (old) version? Gryllida (talk) 21:47, 22 June 2018 (UTC)
All old features have been kept. On watchlists, you can display a period of time (and now a number of edits). You can hide (or only show - that's new) registered users (with a more precise filtering: you can have newcomers, learners and/or experienced users), anonymous users, your edits, bots edits, minor edits, page categorization, Wikidata or reviewed edits. It is possible to select multiple namespaces (instead of just one on the old interface). Inverting selection and Associated namespace inclusion are now handled by selecting all namespaces you need.
If you have particular cases in mind, I can share with you the matching filters configuration. Trizek (WMF) (talk) 08:22, 25 June 2018 (UTC)

I think we are not communicating properly. Consensus is required for you to make a configuration change. However providing blockers to you is not required for anyone. Please let me know if this is wrong. Gryllida (talk) 21:47, 22 June 2018 (UTC)

You have been asked to provide what you think are blockers, so that they can be reviewed and, if they are real blockers, may delay the deployment. Please re-read Kaartic's announcement at the very beginning of the page: "tell us if you know of a special incompatibility or other issue that makes the New Filters problematic on your wiki. We’ll examine the blocker and may delay release on your wiki until the issue can be addressed." The team in charge of that feature has been discussing about what you identify as blockers. While blockers you've provided are out of project's scope, or based on the newness of the filters, so I've declined them. I've also reminded you that you can any time personally opt-out the filters in your preferences if you don't like them and I can give you any information you need to use them the best.
So far, the only actionable blockers we have received are about performance, a point I've informed you about (you haven't raised it before I've introduced it). That point is really an issue and currently delays the deployment on all wikis. Trizek (WMF) (talk) 08:22, 25 June 2018 (UTC)
What is the performance issue that you are investigating? --Gryllida (talk) 01:24, 26 June 2018 (UTC)
See T197168 - -Kaartic (talk) 15:27, 26 June 2018 (UTC)
Thank you, Kaartic. This performance issue may be not as bad at smaller wikis, I guess? --Gryllida (talk) 01:38, 27 June 2018 (UTC)
The performance issue seems to be related to the number of pages in the Watchlist and the number of changes (possibly also related to the filters). I'm not sure about whether it would be less pronounced in smaller wikis as the core part of the issue hasn't been identified yet. They're still working on it. - -Kaartic (talk) 18:05, 27 June 2018 (UTC)

Discussion[edit]

Contributors here -- would you like to add ORES to this wiki without adding the live feed? This may make it easier to detect spam. See documentation. Gryllida (talk) 02:15, 16 June 2018 (UTC)

Excessicive vandalism notification[edit]

I have not read the discussion on this page for quite some time now, but if the ML is responsible for this, you guys have seriously pissed me off.
•–• 05:43, 2 July 2018 (UTC)

For the record: It was not. It was badly-configured abusefilter. — revi☏ 09:45, 3 July 2018 (UTC)

UI questions[edit]

Hi! Please see questions below and answer inline. Also please see ORES query above in separate section. Thanks, Gryllida (talk) 02:25, 16 June 2018 (UTC)

Icon free ui[edit]

Would making an icon-free (text-based) ui help you?--Gryllida (talk) 02:25, 16 June 2018 (UTC)

Toggling[edit]

Do you toggle things frequently such as whether to show anonymous contributors? Does the new ui make it difficult to toggle them back?--Gryllida (talk) 02:25, 16 June 2018 (UTC)

Date range[edit]

Do you often change the date range for recent changes? Do you find it easy in the new interface?--Gryllida (talk) 02:25, 16 June 2018 (UTC)

Time range[edit]

There is a button "Show new changes starting from 12:19, 16 June 2018" as a link. Do you use it often? If yes, do you find it easy to use with the new ui?--Gryllida (talk) 02:25, 16 June 2018 (UTC)

Namespace filter[edit]

If you use the namespace filter often, do you find it easier ot harder to use on the new version?--Gryllida (talk) 02:25, 16 June 2018 (UTC)

Tag filter[edit]

If you use the tag filter often, do you find it easier or harder to use on the new version?--Gryllida (talk) 02:25, 16 June 2018 (UTC)

Bookmarking[edit]

If you bookmark RC list with certainfilters, do you find it easier or harder to do on the new version?--Gryllida (talk) 02:25, 16 June 2018 (UTC)

ui jumps[edit]

To be added --Gryllida (talk) 02:25, 16 June 2018 (UTC)

mobile[edit]

Does the new interface read well on mobile ? --Gryllida (talk) 02:27, 16 June 2018 (UTC)

performance (loading)[edit]

Are you able to time how quickly the recent changes new ui takes to load? What is the timefor you? This can be done via Firebug or Firefox / Chrome builtin tools. Gryllida (talk) 02:27, 16 June 2018 (UTC)

Summary 2018-06-25[edit]

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

From my personal view of the discussion above,

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 no workaround available? (being discussed below)(01:28, 26 June 2018 (UTC)) (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)
Please see clarification below. --Gryllida (talk) 01:28, 26 June 2018 (UTC)

Consensus unknown:

  • B_1 list of which filters to display by default is not customizable per wiki (me + Pi zero)
  • B_2 issue with ui jumps has not been resolved (bug may be filed) (my personal concern)
  • B_3 issue with loading time has not been measured (bug may be filed) (my personal concern)
  • B_4 issues with the ui appearance have not been resolved (bugs may be filed) (my personal concern)
    • dates moved to a pop-up
    • filters difficult to toggle
    • too many icons (06:41, 25 June 2018 (UTC))
  • B_5 list of which filters to enable or not not customizable per wiki (my personal concern)
    • "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)
  • 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)
  • B_8 "the new interface does not have an 'opt out' button which takes people to a login page with a note at the top that they may opt out in their preferences after they log in" (added by Gryllida (talk) 23:55, 27 June 2018 (UTC))
  • B_9 "the new interface does not have an 'this is new, leave feedback here' note with an URL to a local discussion page on wiki" (added by Gryllida (talk) 23:55, 27 June 2018 (UTC))

Did I miss anything? Gryllida (talk) 06:44, 25 June 2018 (UTC)

Could you please comment which of these issues are relevant to you? Gryllida (talk) 06:44, 25 June 2018 (UTC)

Would the development of A_3.2 be a good way to resolve this situation? Gryllida (talk) 06:43, 25 June 2018 (UTC)

Gryllida, please stop misquoting people.
For point A_2, I've never called that a bug. The question was about displaying 50, 100, 500.. edits on the list of results on Recent Changes page. 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.
For point A_3.2, JMatazzoni never told that opting-out is possible for the reasons you mention: "If there is a special reason why the New Filters cause problems on a particular wiki—a common gadget or some such—we can delay release on that wiki until we can fix the issue." If you check on the example he gives, that's not the case for your wiki.
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. Trizek (WMF) (talk) 08:29, 25 June 2018 (UTC)
To clarify the point "leave it opt-in rather than opt-out (confirmed by Kaartic, ...", I wasn't endorsing that the change should be made opt-in for this wiki. I can't do that as I'm not so involved here to speak about it. I was just exploring the possibilities of whether it could be made opt-in or not for this wiki due to the requests here.
As a point of note for "inability of IP contributors to change back easily", I guess the easiest way, now, for them to switch to the old UI is to disable JS while viewing the RC page, as pointed out by Trizek earlier. - -Kaartic (talk) 19:55, 25 June 2018 (UTC)
pi zero notes, in passing, that Wikinews is heavily dependent on javascript-based customizations to correct shortcomings of the platform for news purposes, so that accessing it with javascript turned off leaves the site rather crippled. --Pi zero (talk) 21:40, 25 June 2018 (UTC)
I visited Special:RecentChanges with JS disabled and it wasn't as crippled (at least, from my perspective). I suspect using Wikinews with JS disabled is crippled only for the veterans. In which case they have the option of opting-out in the preferences.
Further, I also read Gryllida stating that this wiki "does not have anonymous RC patrollers" which clearly indicate (at least to me) that IP users aren't in trouble yet and if there are IP patrollers in the future then they would see the new UI and would learn to use it. I'm saying this as I still don't see the ultimate need for IP contributors to switch to the old-UI. If I'm misunderstanding, let me know. - -Kaartic (talk) 08:39, 26 June 2018 (UTC)
@Kaartic: A bit of perspective on where I'm coming from. I've been thinking deeply on how users interact with Wikinews for about eight or nine years, and after some lead time to choose a starting point for action, over the past five or six years I've put in, guesstimate, a few thousand programmer-hours. A key principle of my strategy is that in developing wiki interactivity —just as in developing wiki content— the volunteer community is the wellspring of expertise and therefore the volunteer community must be directly in charge of the process. Although the current discussion may have got started because of some remarks I made, I've not continued to engage deeply. I did notice, however, a point of which an outsider might be unaware, and thought to aid clarity of thought by remarking on it. In response, I'm told that I'm likely to be wrong because I'm a local expert. The only further thought that comes to my mind, in the face of this reasoning, is that as a basis for dismissing feedback from local experts it seems extraordinarily incisive. --Pi zero (talk) 13:56, 26 June 2018 (UTC)
@Pi zero: Seems I crapped with the words and didn't communicate what I intended to clearly. Sorry about that. When I said "I suspect using Wikinews with JS disabled is crippled only for the veterans", I actually meant I couldn't immediately notice how much the Wiki is heavily dependent on javascript-based customizations. I didn't intend to mean you're wrong, I mean I couldn't still get the perspective that you have (which I tried to convey by means of indirect statements such as "If I'm misunderstanding, let me know"). As a consequence I couldn't confirm the issue about the IP contributors you were stating. I don't intend to dismiss feedback from local experts (I wouldn't have posted the announcement, if I had that mindset), we actually expect that. I'm still hoping to understand the issue you're stating which would help me take actions that might help solve it. Thanks, Kaartic (talk) 15:24, 26 June 2018 (UTC)
@Kaartic: Fair enough. Well, fwiw, some general, and then some specific, thoughts on Wikinews site automation:
  • Ordinary day-to-day activities here depend on automation so ubiquitous that, as a regular user, I tend to forget they're there (except when, from time to time, we lose another one of them due to externally imposed changes to the wiki platform). There is (just to underline the point) a patch in our common.js that allows admins to create page-specific javascript, run automatically when any particular page is loaded. The older deployed generation of automation here was mostly coded by bawolff in days of yore; I'm developing a new generation of semi-automation, including amongst its design goals as much deliberate robustness as I can devise against arbitrary changes to the wiki platform. Both the old and new tools require javascript; my new generation of dialog tools are centrally focused on empowering the community by writing all customization through wiki markup, but enabling it requires javascript under the hood. In the long run, I would expect pretty much every activity on the site to use semi-automation. Imagine, for example, an interactive article wizard to help anyone, most definitely including a completely new arrival, write a news article. I have in mind we might replace liquid threads with something dialog-based. Proposing edits to archived articles. Even adding remarks to talk pages.
  • Regarding ordinary day-to-day activities already requiring automation, that a newbie using an IP might reasonably be expected to use — as I say, I could really easily completely forget some because they're so ubiquitous, but, two that come to mind:
  • When one writes an article and then wants to submit it for review, one does this by clicking a button on the {{develop}} template at the top of the article (or if it's being resubmitted after revisions, the {{tasks}} template). That button is enabled by javascript (used to be bawolff's code, now uses mine). If javascript is disabled, submitting an article is more arduous (perhaps only mildly tedious for an experienced practitioner of wiki markup, but we are discussing newcomers, here).
  • When viewing any Wikinews topic category [‍e.g.‍], the category page has a dynamic list of most recently published articles in the category. That list can be scrolled, to look further back in time, using a dialog button — but not, of course, without javascript. Atm that sort of scrolling is mostly restricted to the topic category pages, but the possibility of using it on the main page has been hovering about for some time now.
--Pi zero (talk) 16:47, 26 June 2018 (UTC)
A non-JS fallback (inconvenient, but better than nothing for non-JS users) for the first one could be opening the edit interface with a note "please replace {{develop}} with {{review}} here and click save" at the top? Gryllida (talk) 21:53, 26 June 2018 (UTC)
@Gryllida: Atm, if dialog is not available the button does revert to an edit link; however, there is no editintro to tell the user what to do once they are actually editing the page: the instructions are contained within the text on the {{develop}} template. We could add such an editintro at Template:Assistant/submit. It's never been a high priority to add special support for an IP when dialog is disabled, especially considering that a major cause of dialog getting messed up is that a user is loading broken customized javascript of some sort, which an IP can't do. --Pi zero (talk) 22:12, 26 June 2018 (UTC)
@Pi zero: Thanks a lot for the detailed explanation! That gives a lot of context to me. I could now see that disabling JS for IP users would not be a solution for them to get back the old UI. Anyways, that still leaves with the question of Why would the IP contributors want to use the old interface? What would limit them from using the new interface?. The answers would let me know about the real issues with the new UI which could in turn be fixed, if possible. Else we could consider pondering the option of allowing the IP users to switch to the old interface, if that's the best and reasonable solution available.
Also a general note about "from time to time, we lose another one of them due to externally imposed changes to the wiki platform". I don't think any changes were pushed to this wiki even after knowing they break things (cause more harm than good) (hope I'm not missing anything obvious). It might be the fact that they would not have been aware about the issues. If possible, in future try evaluating the new features before they get deployed and let the right people know about the issues, if any. I'm sure they would help you fix your issues, whenever possible. (At least that was my experience). - -Kaartic (talk) 17:57, 27 June 2018 (UTC)
I guess from my personal perspective IP users may want to disable this interface because of the issues raised in A1 and A2 and B7. Also, the new interface does not have an 'opt out' or 'leave feedback here (URL on local wiki)' buttons; added as B8 and B9. --Gryllida (talk) 23:55, 27 June 2018 (UTC)
I've created T199054 for the feedback link (B_9). I haven't created the task for B_8 as I'm not sure if that would be useful as not every IP user would have seen/used the old interface and showing a message for everyone wouldn't be useful. Further, I'm not sure if it's possible to show the message only for IP users who have used the old UI. I suspect the solution would be complex and am not sure if it's worth it. If you feel strongly about B_8 (or any other issue, for that matter), please create a new task in phabricator or start a discussion in the talk page. Thanks, Kaartic (talk) 13:00, 8 July 2018 (UTC)
It seems there already was a feedback link in the filter menu of the new UI. I've just failed to notice it. --Kaartic (talk) 19:23, 30 July 2018 (UTC)
@Kaartic: Relating to your general note. You mention evaluating new features before they get deployed. Two thoughts about that.
  • We are a small project, chronically short of needed volunteer labor, especially volunteer labor at the high end of expertise. Consider, for a moment, this logistical challenge: news has to be reviewed, in exhaustive depth, by a trusted expert, who is a volunteer, promptly (by wiki standards), on the schedule of the volunteer reporter who submits it rather than the schedule of the volunteer reviewer. To someone familiar with how wikis traditionally work (think: Wikipedia), this does not play to the strengths of that traditional model, which means both that expert volunteer time is stretched to its limits trying to keep up, and that expert volunteers must then somehow scrape up additional volunteer time in which to design and implement measures to improve the workflow of the project. There is, as I've noted, a great deal of ubiquitous automation (or semi-automation) around here, which it's hard to even list, let alone check for obvious (or unobvious, or downright bizarre) interactions with each change that comes down the pipe. Announcements of changes happen far more often (likely, orders of magnitude more often) than our small, overburdened community of volunteer experts could reasonably be expected to keep up with. (That's supposing that the changes involved are, in a practical sense, announced beforehand; another can of worms.)
  • A question that becomes very relevant is, why are platform changes being made that place, one way or another, additional burden on our short supply of expert volunteer labor? And that's a point at which things become highly problematic. The biggest, most sweeping structural changes to the platform —most likely to cause collateral damage that's hard to anticipate, hard to detect, hard to figure out what to do about— are done to accommodate long-term Foundation initiatives that are, to be blunt, directly contrary to the long-term interests of the sisterhood and apparently impossible to dissuade the Foundation from pursuing. VisualEditor. Flow. It's one thing to ask us to put up with some problems to support initiatives for the long-term good of the projects; it's quite another to ask us to put up with some problems to support initiatives for the long-term detriment of the projects.
--Pi zero (talk) 15:36, 28 June 2018 (UTC)
IIUC, you're trying to say that:
i) This is one of those unique Wikis, unlike other wikis, where the volunteers need to act on a timely basis for their content due to the timeliness required for News.
ii) To the contrary, the wiki is chronically short of volunteers needed for various things. As a consequence of which the existing community finds it difficult to spare time to evaluate the new platform changes (for example, the recently deployed New filters for Edit Review in Recent Changes and the upcoming deployment of New filters for Edit Review in Watchlist).
Here's my reply:
  • If that understanding is correct: That's seems to be a sensible reasoning to me. What kind of alterations/exceptions to the deployment of platform changes would make it a more gradual and accepting one in this Wiki? Would delaying the deployment a little, help? I'm asking this to gather more information so that I could ask other people and see if I could get something done to make things more smoother rather than making it a pain. I'm not sure if I could do this, but I'll try my best. That said, I think skipping/avoiding deployments altogether would not be an option as the Wiki must accept them at some time to ensure consistency across the wikis.
  • If I understood something wrong, somewhere: please correct me by clarifying what I got wrong.
Thanks, Kaartic (talk) 19:37, 30 June 2018 (UTC)
@Kaartic: Your understanding, as you describe it, sounds about right. Though I would place one caveat on it: our particular need for prompt action on submissions amplifies our labor shortage here, but all small wikis are pretty sure to have a similar problem, proportional to how small they are. The whole concept of relying on local wikis to find and report problems with centrally-imposed changes to the platform is inherently biased in favor of large projects and against small ones. Which goes to my basic thesis that design changes should be in the hands of the local communities rather than being imposed by a central authority.

Curiously enough, however, I find myself leery —at first blush, anyway— about delaying deployment. That would seem to invite [technical] incompatibilities between this project and various of its sisters, and that strikes me as a bad idea. (Perhaps Gryllida has thoughts on this point?) A particular twist on this: In pursuit of my vision of local communities directly growing interactivity through the medium of ordinary wiki pages, I'm developing tools here on Wikinews, with the intention that they would then be exported to other projects, including the Wikipedias (so far I know of two other projects they've been exported to; one I did myself and another by someone else). En.wn is a good place to do the development not only because we have an urgent need for the tools here, and because this is a small and focused project to use as a testbed, but also because our license allows things developed here to be exported to all other sisters, whereas we can't import primary content to here from most of the other projects. (There is ongoing disagreement here, even after more than a dozen years, about importing templates and whatnot from Wikipedia; but then again, the very nature of what I'm doing blurs the distinction between "code" and "primary content".) --Pi zero (talk) 13:50, 2 July 2018 (UTC)

@Pi zero: Sorry for the delay. Was travelling for a few days. Thanks for the suggestions. I've noted them and I'll try to discuss with others about your suggestion. I'll let you know if there's something remarkable that changes. Thanks, Kaartic (talk) 11:44, 8 July 2018 (UTC)
Hello @Pi zero: After some discussion with other people, I've been reminded that the community is always welcome to give feedback about the design as every design process is open (I'm not sure how I missed this in the first place). So, why do you feel otherwise? What am I missing? --Kaartic (talk) 21:02, 5 August 2018 (UTC)
@Kaartic: Two remarks.
  • Smaller wikis have less time to spare to interact with some central authority and, from experience, are pretty sure to get nothing from the attempt, thus it would be a bad expenditure of their time.
  • Moreover, the whole central model is not a good way to design interactivity. The situation is very much like providing wiki content: the volunteers are the ones whose knowledge is to be captured, and it makes more sense to empower them to contribute directly than to present them with an opportunity to try to explain to a centralized authority what they want and convince the centralized authority to eventually provide it.
--Pi zero (talk) 23:06, 5 August 2018 (UTC)
@Pi zero: Thanks for the remarks. My replies:
About the less time smaller wiki community has to spare, it seems mw:ORES might help you reduce that burden. When well trained it helps you with doing your work easily. It does take some time to train it, though. But the result might be fruitful given the initial training.
About your second remark, excuse me, but I think I still don't get your point completely. From what I understand you seem to be suggesting to empower the community with to contribute directly to design. But I think the community were never deprived of that. To point out an example that comes to the top of my mind, the new Timeless skin for MediaWiki and responsive variant for Monbook skin were developed by a volunteer possibly with the help of other volunteers. To add to it, the central authority you speak of doesn't develop anything because they think it might good but because the community wants them to do it. Also, they do seem to listen to valid concerns and act on them accordingly. The recent performance issue with Watchlist is an example that comes to the top of my head.
Correct me if I misunderstood you somewhere and excuse me for that.
--Kaartic
  • By "confirm this bug" I meant "see that this works differently to XYZ's expectations" -- not "confirm that this is indeed an issue worth fixing, which we will fix" and not "endorse". Hopefully this makes it easier for you (and others) to understand what I mean. I'm sorry that it is misleading. --Gryllida (talk) 01:28, 26 June 2018 (UTC)
  • For clicking back there is no workaround then? I've tried to remove a few filters in the new RC changes interface, but the back button in my web browser remains grayed out. --Gryllida (talk) 01:28, 26 June 2018 (UTC)
You seem to mapping the old and new interface a lot. It doesn't work well. The new interface does not reload the page each time you change the filters. It updates the page dynamically. So, you would have to add back the filter you removed by using the menu. Alternatively, you could save the set of filter configurations you use often and you can access them using the 'Saved Filters' menu. --Kaartic (talk) 11:58, 8 July 2018 (UTC)
It could also update the URL dynamically? --Gryllida (talk) 21:01, 8 July 2018 (UTC)
Yes, it does update the URL dynamically. I didn't actually think about that before but I just confirmed that the page's URL (the URL parameters, to be exact) gets updated dynamically, without actually re-loading the page, whenever you add/remove filters. This is done to ease sharing, I suppose. --Kaartic (talk) 17:56, 9 July 2018 (UTC)
Thank you for this detail. Is this technically possible to make the Back button work with this technique while not re-loading the page? Gryllida (talk) 01:42, 12 July 2018 (UTC)
I don't think so. AFAIK, the back button is used to go to a pages you visited "before" the current one. So, you can't go "back" to a page unless you've moved away from it to another in the same window. As a consequence of which you can't enable the back button until you've either re-loaded the page or visited another one (thus leaving the current page). --Kaartic (talk) 12:44, 15 July 2018 (UTC)
Hello Kaartic. :-)
Can it use pushState() ? Gryllida (talk) 05:34, 16 July 2018 (UTC)
Thanks for the pointer. I wasn't aware about that before. It might be a possible solution. Would you mind opening a task related to this? I'm asking you to do this as you could more appropriately describe how you're affected without this. Further, I lack the knowledge of the pushState() feature (and how it could be used). Thanks, Kaartic (talk) 03:50, 18 July 2018 (UTC)
added. Gryllida (talk) 00:48, 19 July 2018 (UTC)
  • What about A_1? It is, too, increasing the learning complexity greatly, for IP contributors who can not switch this tool off easily. Gryllida (talk) 01:35, 26 June 2018 (UTC)

Nodejs programming needed[edit]

I am looking for someone who can implement this, as then currently unfolding events may be shown on a map such as this one, but after the fix the moderation may be improved and the web site may be actively advertised to Wikinews audience and beyond. For adding OAuth and for implementing username based blocks there a reward may be offered.

I am open to suggestions of other software that does this task more simply also: each marker on the map needs to have a title and two long descriptions, and be colored by date or status; however 90% of the events would be discarded as stale, as there is a lot more events happening than we can report on. Gryllida (talk) 00:11, 2 August 2018 (UTC)

@Samwilson: can you advise of anyone with the skill set? — billinghurst sDrewth 11:09, 2 August 2018 (UTC)

Headers broken[edit]

See (e.g.) Category:Barack Obama with the following displayed to the user: "action=do&label=see older articles&verb:button-local-field-verb&page:button-local-field-page&offset:button-local-field-offset&cols=&rows=&viewxcols=&rows=&Category:Barack Obamaxcols=&rows=&10x". —Justin (koavf)❤T☮C☺M☯ 23:18, 13 August 2018 (UTC)

@Koavf: That code is supposed to be hidden until and unless the dialog gadget runs, and at the time it's unhidden that gibberish should already have been replaced by a button. When I look at thost pages, sometimes the gibberish appears briefly before being replaced by the button, which is disturbing since it should be invisible until after being replaced, suggesting that the hiding facility has failed. If for you both the hiding and the gadget are missing-without-leave, you would permanently see the gibberish. Do you perhaps either have javascript turned off, or have some javascript running that is broken is thereby prevents other javascript (such as the gadget) from running? --Pi zero (talk) 01:24, 14 August 2018 (UTC)
@Pi zero: Scripts were turned off until not long ago but definitely before I viewed that category. Hm. Now it does the "briefly appear and then fade away" trick. —Justin (koavf)❤T☮C☺M☯ 01:35, 14 August 2018 (UTC)
Retrieved from "https://en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/technical&oldid=4426793"