Wikimedia Forum

From Meta, a Wikimedia project coordination wiki
(Redirected from Metapub)
Jump to: navigation, search
← Discussion pages Wikimedia Forums Archives →
QA icon clr.svg

The Wikimedia Forum is a central place for questions and discussions about the Wikimedia Foundation and its projects. (For discussion about the Meta wiki, see Meta:Babel.)
This is not the place to make technical queries regarding the MediaWiki software; please ask such questions at the MediaWiki support desk; technical questions about Wikimedia wikis, however, can be placed on Tech page.

You can reply to a topic by clicking the "[edit]" link beside that section, or you can start a new discussion.
Wikimedia Meta-Wiki


This box: view · talk · edit

Global autopatrolled[edit]

I am not sure about global patrollers. But I am sure that a global autopatrolled status is needed for administrators and filemovers of the Wikimedia Commons since they correct file names in many wikis, and also for other trusted users who edit in many wikis. Gamliel Fishkin 05:30, 30 October 2016 (UTC)

  • Support Support This would be a good idea for Commons admins and filemovers who do a lot of renames and who process a lot of duplicates. This would save some patrolling time. I personally have the autopatrol right at 16 different wikis. lNeverCry 05:59, 30 October 2016 (UTC)
  • Support Support Sounds like a good idea. Jianhui67 talkcontribs 06:24, 30 October 2016 (UTC)
  • Support Support - Per INC. Wikicology (talk) 06:31, 30 October 2016 (UTC)
  • Support Support per rationale, also useful when images are undeleted. --HakanIST (talk) 06:42, 30 October 2016 (UTC)
    Along that same line, this would be helpful when a mistaken deletion occurs, the file is restored, and the delinker has to be reverted at the wikis where the file was in use (barely ever happens of course... Face-wink.svg). lNeverCry 08:09, 30 October 2016 (UTC)
  • Symbol strong support vote.svg Strong support Mainly per INC and nom. There's no reason not to trust us Commons filemovers... --Pokéfan95 (talk) 11:20, 30 October 2016 (UTC)
  • Oppose Oppose This is a solution for no problem as far as I can see. This permission is content-related and should be handled by individual communities if they think the user is okay for it. Plus, it is not really worth the effort to add 300+ users to this group, flooding the stewards for no real reason. This is different from OTRS members which get flagged to avoid licensing-tag fraud issues. —MarcoAurelio 11:28, 30 October 2016 (UTC)
@MarcoAurelio: it is possible to define, who are eligible for such a status: if an ineligible person would ask for a status, the application would be closed automatically. And is it a hard work for 30+ stewards to give a status to 300+ users? Gamliel Fishkin 12:48, 30 October 2016 (UTC)
@MarcoAurelio: The number of active filemovers and admins at Commons is likely under 100. I would suggest this right be given on request from Commons admins and filemovers who can show a significant amount of activity. You'd might end up with 100 passable requests for the right, but those 100 editors account for thousands of cross-wiki moves and replacements. Also, how do local communities give somebody a right who can't request it in their language? I've nostly been surprised by an email saying my rights on another wiki have been changed. lNeverCry 02:05, 31 October 2016 (UTC)
  • Oppose Oppose some wiki's don't even want separate autopatroll groups. We should not force this change upon local communities. Plus trusted Commons users often are problematic for other wiki's. (Global replace wars, renames in closed archives, removing files from the user namespace because they fancy the svg, you name it.) Natuur12 (talk) 13:22, 30 October 2016 (UTC)
    @Natuur12: But they're fine with Global Sysop which includes the block and deletion functions, or Global Rollback? What? Global Autopatrol seems like less of a risk than the other two. As I suggest above, people should have to apply for this right here just as they do for GRollback and GSysop. As regards problems at other wikis, you and I don't have any, and neither do most of our highly active filemovers and admins at Commons. These concerns, if present, would very likely be brought up and addressed at an editor's request for the right here. Obviously any abuse of the right would warrant removal of it. lNeverCry 02:05, 31 October 2016 (UTC)
    Global sysop follows a WikiSet. --Vogone (talk) 05:01, 1 November 2016 (UTC)
  • Support Support as per INC. Yann (talk) 22:27, 30 October 2016 (UTC)
  • If this is an idea for commons admins, I would suggest to make it part of the Global file deletion review which still lacks technical implementation, instead of creating an entirely new user group. --Vogone (talk) 22:55, 30 October 2016 (UTC)
    That's not true, it's fully implemented on a technical level. See phab:T16801#191940. Legoktm (talk) 23:29, 30 October 2016 (UTC)
    It lacks community implementation, i.e. when the RfC was closed and taken to stewards we disagreed that there was consensus to create the group. – Ajraddatz (talk) 23:32, 30 October 2016 (UTC)
    This is interesting. Is there any public record of this decision? The RFC at least speaks of a consensus for implementation. --Vogone (talk) 00:06, 31 October 2016 (UTC)
    Stewards' noticeboard/Archives/2015-04. Note that it was essentially vetoed by myself and Billinghurst, with no other stewards offering their opinion. That wasn't my intention at the time, however, and it might be worth revisiting this. – Ajraddatz (talk) 00:12, 31 October 2016 (UTC)
    How did we get global sysop and rollback, but no autopatrol? Global sysop is 2nd only to steward... lNeverCry 02:05, 31 October 2016 (UTC)
    @INeverCry: To be fair, bureaucrats are above sysops but below stewards. (And oversight/suppressor and checkuser have very specific privileges...) —Justin (koavf)TCM 02:16, 31 October 2016 (UTC)
    @Koavf: But there's no global crat group. Having been a checkuser myself for a couple years, I can tell you there were many many times when I wished I was a global checkuser because another wiki had a fresh sock I wanted to look at, or because I would've loved to run check on a certain range to see who was on it on Commons after it was found to be dirty on, etc. In the end, though, have you ever seen a crat actually do anything? Face-wink.svg lNeverCry 02:54, 31 October 2016 (UTC)
    @INeverCry: That makes sense--in terms of global status. I wasn't thinking. —Justin (koavf)TCM 04:08, 31 October 2016 (UTC)
  • Oppose Oppose Sounds like collecting of privileges. Unclear what problem is solved by this. The Banner (talk) 23:48, 30 October 2016 (UTC)
    In this case, if a Commons admin moves a file and tries replacing its global usage through his or her account, there are many wikis where the edit will be flagged by pending changes as needing to be reviewed (major wikis like and ru,wiki for example). This review is unneeded. The file is moved already, so all the reviewer is doing on the local wiki is wasting his or her time confirming something that's already been done. They can't even revert it locally since the original will be a redirect. lNeverCry 02:05, 31 October 2016 (UTC)
  • Comment I've been autopatrolled at 17 different wikis. I would think the reason for those autopatrols was mostly people on those wikis were sick of having to review pending changes that were simple filemoves or dupe processes. It seems strange to me that other wikis are willing to have people with global sysop privileges, but autopatrol would be going too far. BTW, I've actually had people on other wikis revert my edits when I replaced a file through a file move. Then they had to go through the hassle of figuring it out by seeing a redlinked file name, and going back to my good edit. This right would allow other communities to see that the person doing the move is trusted with a global right. I would certainly agree that granting of this right should be done as carefully as global rollback. lNeverCry 02:05, 31 October 2016 (UTC)
Even more, I seen a case, one of the Commons' filemovers was indefinitely blocked at one of the wikis: a sysop thought it is an unauthorised bot (the block was cancelled after my intervention). Gamliel Fishkin 04:00, 1 November 2016 (UTC)
  • Oppose Oppose Centralizing rights like this weakens the local projects, in fact it's interesting that local projects don't get to run their own votes on fundamental changes to their own project rights or a chance to opt-out of changes. -- (talk) 14:00, 31 October 2016 (UTC)
  • Support Support It makes sense to me for cases like those mentioned by Gamliel. Files move in Wikimedia Commons are just innecessary extra work for wikis with a revision system in place --Poco a poco (talk) 23:09, 1 November 2016 (UTC)
  • Support Support Global rollbackers's edits automatically marked as patrolled, and it is central permission and no conflicts before, so the idea is not new nor impossible, I thinks this permission will make some users like filemovers's work easier --Ibrahim.ID 20:59, 5 November 2016 (UTC)
    Strange comparison, global rollback follows a pretty high standard (only very few applications are successful). The proposed user right however would probably be given out to many more users. Whether that is a bad thing is a different question, but the comparison with global rollback seems inappropriate to me. Plus, I don't see how autopatrolled makes filemover's life easier, it's a very passive user right. If anyone "profits", then it's likely the group of local administrators/patrollers; and whether they want this external review is probably different per wiki. --Vogone (talk) 21:45, 5 November 2016 (UTC)
    @Vogone: global autopatrol would be a less strong right then global rollback. Yes, such a right can be dangerous if given to a vandal; but stewards are not bots to make something without thinking. This right would make filemover's life easier at least in the sence that their risk of being blocked in some wiki would be less high (I seen such an error block). Gamliel Fishkin 02:50, 6 November 2016 (UTC)
    I don't understand. Why would an error block be less likely in case of patrolled edits? Because admins don't check edits without red exclamation marks? --Vogone (talk) 07:28, 6 November 2016 (UTC)
    Sysop of one of the wikis seen edits by one of the Commons' filemovers and thought there is an unauthorised bot (that filemover is a human being and so has not local and global bot statuses). The sysop written to the filemover in a language he does not understand; there was no reply, and the sysop blocked locally the filemover for 15 minutes. 16 minutes after the end of the first block, the sysop blocked the filemover for one day. Six days after the end of the second block, the sysop blocked the filemover indefinitely. More then three years after these events, I written to the sysop with a link to global replace, and he unblocked the filemover with description "File renaming/Global replace". I think the problem would not occur, if the sysop would see at the filemover some global status like global autopatrolled (most edits of that filemover on that wiki have edit summaries starting with "(GR) File renamed"; so, these links in edit summaries are not enough). Gamliel Fishkin 17:31, 6 November 2016 (UTC)
    This is perhaps an argument for assigning random dummy flags to trusted accounts (although a weak one, since global group membership is barely visible to users who don't know where to look), but certainly not an argument for global autopatrolled. --Vogone (talk) 17:40, 7 November 2016 (UTC)
    Most technical flags grant an access to some functions. But flags like autoeditor, autopatrolled, autoreview, etc. do not grant an access to any function; they just mean that a person is trusted. I think most sysops know about tools like Navigation popups and CentralAuth. Gamliel Fishkin 01:30, 8 November 2016 (UTC)
    No, this does not reflect reality at all. And no, I have seen many admins who have never even heard of CentralAuth before and I for instance have never heard of "Navigation popups" either. --Vogone (talk) 19:30, 8 November 2016 (UTC)
    "Navigation popups" is a tool, whish displays some contents of a wiki page when a cursor is over a wiki link to that page; when it is an user page, also statuses and some other user info is displayed. You can enable it at your preferences (Browsing gadgets). Gamliel Fishkin 10:23, 9 November 2016 (UTC)
  • Oppose Oppose, I do not think is is a good idea to give a user autopatrolled rights on the project X if the user does not speak the language X. These edits are not so many and are better checked manually.--Ymblanter (talk) 22:27, 5 November 2016 (UTC)
    @Ymblanter: renames at Commons "are not so many": few thousands per week. It would be a hard task for local patrollers to explore all such edits; it is the cause, why many of the Commons' administrators and filemovers have big collections of local autopatrol statuses. If some person do not make, on some local wiki, edits which require to understand a language, but modifies file links often, and that person is trusted by few other wikis, what is the cause not to trust that person in that wiki? Local administrators explore such trusted persons and give to them an autopatrol status; would not it better if a steward would make this work one time instead of local wikis' administrators to make it many times? Gamliel Fishkin 02:50, 6 November 2016 (UTC)
  • Oppose I think this proposal doesn't even solve what the proponents want. The only effect of autopatrol is that no red exclamation mark will appear next to a user's edit on Special:RecentChanges, if this annoying setting is at all turned on (see mw:Manual:Patrolling), which on WMF wikis it is by default for new page creations. Flagged revisions rights are completely unrelated. --MF-W 01:38, 6 November 2016 (UTC)
    @MF-Warburg: I speak not about these red exclamation marks, but just about a right, given locally by statuses like autoeditor, autopatrolled, autoreview, etc. Gamliel Fishkin 02:50, 6 November 2016 (UTC)
    Please read his message again, he said: The only effect of autopatrol is that no red exclamation mark will appear next to a user's edit on Special:RecentChanges, in other words: users have their own edits automatically marked as patrolled. If that is not the point in granting this right to filemovers & commonswiki admin, what is it? Matiia (talk) 03:48, 6 November 2016 (UTC)
    Well, I read her message again because you asked me for it; I found in the message nothing I not replied yet. I already replied, that I speak not about these useless red exclamation marks, but about that patrolling who is named in other words as flagged revisions. Gamliel Fishkin 17:31, 6 November 2016 (UTC)
    Please read mw:Extension:FlaggedRevs#User rights. Here you are proposing to create a global user group with autopatrol right, not autoreview. Matiia (talk) 18:23, 6 November 2016 (UTC)
    Thank you for the link, I think that system is somewhat redundant. I speak about the right which is named there autoreview. Gamliel Fishkin 01:27, 7 November 2016 (UTC)
  • Oppose - on the basis of essentially no change with or without the rights. As people have said above, removing the red ! beside an edit isn't going to make much difference, and could infringe on how local communities want to handle content evaluation. That said, I'm not at all opposed to making the lives of commons users easier because I understand how cross-wiki in nature their activities are. I would be glad to support another attempt at the global file deletion review group along those lines. – Ajraddatz (talk) 07:49, 6 November 2016 (UTC)
    Such a global status would make the work of Commons' sysops and filemovers easier just a bit, but it would make work of sysops and especially patrollers of other wikis much easier. If some Commons' sysops and filemovers rename mostly unused or poorly used files, they do not need such a status. But many of them rename files, many of which are widely used. If a renamed file is used in hundreds of wikis, local patrollers at those hundreds of wikis have to explore just the same edit to flag it as good; one work is made hundreds of times. The local patrollers do not need to make it, it the person has a local autoeditor/autopatrol/autoreview status. I am a sysop of Wikipedia in Esperanto; when I see a person, who just correct file links, makes nothing bad and is already trusted by some wikis, I ask him/her for an agree and grant an autoreview status (for now, fifteen persons, in this number five Commons' sysops and five Commons' filemovers). Why this work have to be repeated many times by local sysops, when it can be done one time be a steward? Gamliel Fishkin 17:31, 6 November 2016 (UTC)
    Yes, I did in fact read the proposal. But I disagree with your conclusion that removing the ! would make things any easier. Not all wikis even use that system of patrolling, and even among those that do, I imagine that people will still review edits that they find suspicious, regardless of whether they have been marked as patrolled. – Ajraddatz (talk) 18:51, 6 November 2016 (UTC)
    There in the world do exist some human beings who believe to nobody. But it does not mean that the entire system of patrolling/reviewing is useless. Gamliel Fishkin 01:30, 8 November 2016 (UTC)
    At no point did I suggest that it was. I think that there is no useful benefit to be gained from a global autopatrolled group, and a little bit to lose. That makes it a net negative to me, and thus I oppose. What you should be thinking of is why all of the stewards/global sysops here have opposed this proposal. We are the ones with arguably the most cross-wiki experience, and best understanding of the situation. We are all aware of the cross-wiki nature of Commons, even if we aren't active on it. You've taken the time to argue every single one of the opposes here, but why would we all be incompetent with our opinions? Instead, I think it might be wise for you to step back, read what we've wrote, and maybe work with us to re-formulate a proposal or accept that it won't do what you want it to do. – Ajraddatz (talk) 19:35, 8 November 2016 (UTC)
    I suppose the main negative side of my proposal is an additional load on stewards; it can be one of the causes why the stewards oppose. I have a diffident idea how to minimize that possible additional load; firstly, eligible for the proposed status would be only persons who match two conditions: to be at least a filemover at Commons or a sysop at Wikidata or some mature local wiki (I think about wikis with al least ten sysops, in this number at least two bureaucrats) and to be at least autoeditor/autopatrol(led)/autoreview(ed) at not less than two other wikis (Meta, Commons, Wikidata, mature local wikis); secondly, applications for a proposed status would be sent not directly to a steward but to a bureaucrat at a wiki where the candidate is a sysop, and only positive decisions of a bureaucrat would be transferred to a steward for a final decision, positive or negative. I have read all I replied just before to reply, you can be sure. Gamliel Fishkin 10:23, 9 November 2016 (UTC)
    The increase in steward workload isn't too big of a deal, at least not to me. I'm concerned that the proposal a) won't do what you want it to do, in that the edits of commons users will (rightly) still be reviewed on these projects, and b) will infringe on how local wikis want to run their systems of content patrolling. This doesn't give them any say, and will have implications beyond just edits to where files are. How wikis grant their passive approval rights is up to them for the most part. The only exceptions to this are groups which are either restricted technically, such as global sysop, and/or go through extensive review processes, such as steward and relatively global rollback. – Ajraddatz (talk) 00:53, 10 November 2016 (UTC)
    As far as I understand, global bot status is valid only in the wikis who allow it, and in some wikis a global bot still needs a local bot status. Even if it is not, such an idea seems to me a solution: global autopatrolled status would be enabled only in wikis who allow it. Gamliel Fishkin 05:42, 11 November 2016 (UTC)
  • Support Support Because otherwise, how do you think users that have Internet censorship issues (e.g. Mainland China) could have time to login, edit, patroll, review... and others everyday or every week? The opposers in this section seems don't care about it. --Liuxinyu970226 (talk) 09:31, 7 November 2016 (UTC)
    • Now I am confused. How is this proposal related to internet censorship at all? --MF-W 15:09, 7 November 2016 (UTC)
  • Oppose Oppose the original request, global autopatrolled. If this is about global autoreviewed (or autochecked), it's a different thing. --Stryn (talk) 16:43, 7 November 2016 (UTC)
    Oh, there is a spaghetti mix between different statuses in different wikis. There in Wikipedia in Russian exists a status with technical name "autoeditor" and Russian name "автопатрулируемый" (verbatim translation: autopatrolled). The same status in Wikipedia in Esperanto has a technical name "autoreview", its name in Esperanto was previously "aŭtomata kontrolanto" (automatic checker) and now is "mempatrolato" (selfpatrolled). If you think about renaming of the proposed status from global autopatrolled to global autoreview(ed), I do not oppose. Gamliel Fishkin 01:30, 8 November 2016 (UTC)
  • I guess there is no consensus to implement this. The last comment was more than a week ago. Jianhui67 talkcontribs 09:47, 19 November 2016 (UTC)
  • Oppose Oppose the patrolling system is very different fro wiki to wiki. Version-base, edit-base, automatically assigned or assigned after a human revision. The only way to implement something in this global direction is probably if the number of option of patrolling architecture are restricted to a limited scenario, and based on what they have in common a mechanism in some cases can be proposed. BTW it could also be peculiar to give an autopatrolled status to a blocked user for example, another likely scenario. I am not against the global idea on the long term, I just think we have to make our homework carefully. Also, small wiki have to be integrated in the global workflow in a "proactive" way, if this standardization process becomes too vertical or fast it can be counterproductive. I don't think it is the moment yet. Let's discuss again after a few years and I'm sure we can find some elegant and balanced shortcuts soon or later. The managing of Global file deletion review for example is a good starting point.--Alexmar983 (talk) 07:21, 5 December 2016 (UTC)
  • Oppose Oppose This is problematic, first, this is content related, but said content may not be approved by local communities or local rules, if you want to bypass the local procedures/local filtering/local watchmen,etc , ask them, not bypassing it by using global rights. Even if it's not content related like maintenance related stuff like what SWMT did, they can't escape local communities eyes. For example, until this day, we are not allowed to help with to do an edit mr.wikipedia, because we have to speak local languages to do so, the only allowed to do so are bots, or user on designated place such villagepump.--AldNonymousBicara? 07:00, 6 December 2016 (UTC)
    • Who and/or what is preventing you to edit or revert vandalism/spam at mr.wikipedia? What kind of wiki apartheid is that? —MarcoAurelio 10:38, 6 December 2016 (UTC)
      • I don't know, it's their rule, every non mr language edit outside of village pump, will be rewarded with blocks. I've complained alot about this during my time as Global Sysop on freenode.--AldNonymousBicara? 14:20, 6 December 2016 (UTC)
        • I can confirm this to be true. It is a very old practice of this community which even existed before I myself started to get involved with the SWMT. --Vogone (talk) 19:03, 6 December 2016 (UTC)
          • What a blatant abuse of the tools IMHO. —MarcoAurelio 14:39, 7 December 2016 (UTC)

Please comment on issue of Arabic Wikipedia[edit]

I posted about serious issues with the Arabic Wikipedia (see here, here, and here), but it is surprising that almost nobody commented, although the issue became clear at the end. They refused even to comment, even though they were asked to respond not only by me but also by another user from the community here.

I posted very serious things about them but they chose not to respond in anyway. What does that tell you? Do you find that acceptable? Please comment on this.--HD86 (talk) 05:22, 17 November 2016 (UTC)

I have read and this is foolish: Wikimedia have no tools to protect honest users if harassers are administrators. It is sad :( --Luca Polpettini (talk) 19:16, 22 November 2016 (UTC)
Harassers-admins block honest users. Honest users try to argue with harassers, because they don't want become harassers themselves. The final result is only harassers-admins, and no honest users, remain in the community. Really sad.. :(( --Luca Polpettini (talk) 19:23, 22 November 2016 (UTC)

Thanks Luca for your kind comment. I am waiting to hear from the others here.--HD86 (talk) 23:33, 25 November 2016 (UTC)

Propose to reactivate superprotect[edit]

Many enwiki admins are compromised and vandalizing main page. I propose that some vandalism targets can betemporary superprotected so that only WMF staffs can edit.-- 16:53, 18 November 2016 (UTC)

Oppose Oppose if WMF staff. But if stewards, it is a rational idea. Gamliel Fishkin 00:39, 20 November 2016 (UTC)
Probably best to discuss this on enwiki instead. – Ajraddatz (talk) 00:43, 20 November 2016 (UTC)
Some of the compromised accounts were staff accounts. Superprotection would have just made it much more difficult to fix. --Yair rand (talk) 22:36, 27 November 2016 (UTC)

Enabling flow on one page (Research:ORES paper)[edit]

Hey folks, I'm working on writing a new research manuscript at Research:ORES paper (will be renamed to something more interesting at some point). I'd like to enable mw:Flow for the discussion page. I plan to experiment with using Flow as a public forum to discuss the manuscript (a mixture of Wikipedians and non-Wikipedians).

I wanted to raise the proposal here because there was an RFC that happened in the past with no-consensus. See Meta:Requests for comment/Enable flow in the Research talk (203) namespace. I closed this old RFC the future of Flow support from WMF engineering was not clear and that raised some serious concerns. However the Flow documentation now says:

The [Collaboration Team] will continue to fix bugs, and make sure that people who are using Flow continue to have a good experience.

Rather than re-open the RFC at this point, I'd like to experiment by enabling Flow on a single page in the Research namespace (the aforementioned Research:ORES paper). Any concerns? --EpochFail (talk) 01:28, 23 November 2016 (UTC)

Hi EpochFail. My sense is that people active on this wiki (Meta-Wiki regulars) have little interest in Meta-Wiki being a test bed for experimental software. Nothing in your post here convinces me that attitudes have shifted. I'm not sure I even knew that Meta:Requests for comment/Enable flow in the Research talk (203) namespace took place, but knowing about it now, it personally makes me even more hesitant. I sympathize with wanting better discussion tools and I sympathize with wanting to be able to do your own thing on your own pages, but if you're looking for consensus from the Meta-Wiki community to expand the use of Flow, it seems unlikely you'll find it.
I'm pretty sure I've made similar comments elsewhere, but I think a lot of people felt "burned" by LiquidThreads, the spiritual predecessor to Flow (even though some people involved in Flow's development vehemently denied that). The migration path away from LiquidThreads or Flow is very difficult, so escaping a bad decision becomes a lot more complicated in the event that Flow, like LiquidThreads or the solutions before it, get abandoned.
I thought Flow had been put into "maintenance mode" and was slowly dying off. The "ee" mailing list's activity can perhaps attest to this, though mw:Flow/Rollout says Flow has spread to about a dozen additional Wikimedia wikis in 2016. I consider myself somewhat technical and I don't know what Flow as a "beta feature" means. It gives the impression that a user can enable or disable Flow in his or her user preferences (i.e., Special:Preferences), but that... can't be right, I don't think. Flow pages (boards, whatever) can't simply be disabled by a user, as far as I know. If they could, I imagine you'd see a lot faster adoption of Flow! --MZMcBride (talk) 03:14, 23 November 2016 (UTC)
Addendum: I finally found mailarchive:wikimedia-l/2016-September/085114.html, which provides some background and context. --MZMcBride (talk) 03:20, 23 November 2016 (UTC)
It is possible to enable Flow on several wikis as a Beta feature, by selecting an option in user preferences. At the moment, this Beta system is out of order and we are fixing it. Trizek (WMF) (talk) 09:03, 23 November 2016 (UTC)
  • Oppose Oppose In addition to what said above: it is not appropriate to expose people to inconsistent discussion systems; Meta-Wiki contains a lot of our wiki history, which ought to be preserved in a future-proof format like wikitext; I see no indication whatsoever that this system will improve in the future and I see practically no fixes of user-reported bugs or feature requests, except some dangerous, harmful and annoying regressions which should have been resolved on day 0 by starting the project with a proper design (rather than the totally flawed design made in 2012 and early 2013). Nemo 07:05, 23 November 2016 (UTC)
Just to be clear, you're opposing me doing what I think needs to be done in order to get my collaborators working on-wiki and out in public. Currently, scholarly practices like discussing a manuscript in progress happens in private. I think that's a great loss and a missed opportunity for Wikimedia. I'm trying to re-engineer scientific practice to be more open. My collaborators won't be using talk pages because they just don't make sense to anyone who's worked anywhere other than Wikipedia on the internet. I think it's worthwhile to bring scholarly practice to the wiki and you're saying "no". Why?
Nemo's list of phab task seems very cherry picked. I could do that about any production system. E.g. ORES is dangerous and annoying. You'll see that we're primarily focusing on operational concerns -- not user-reported bugs and requests. Yet we'd like to deploy prediction models for Meta anyway. So, apparently, we are interested in experimental software running on Meta. (Also, I should note that the list that Nemo links to has many user-reported bug fixes.)
I think I'm pretty representative of the community of people who document their research on meta. I'm at least the most prolific contributor to that space. MZMcBride notes that I'm unlikely to find consensus on Meta about using Flow *at all*. That might be true, but of people who actually edit in the Research namespace on Meta, we have a clear consensus that we want to have Flow. This is a serious point of departure between our subcommunity and the rest of the Meta. By saying no to running Flow on one page as an experiment, you're preventing us from trying it at all. Nemo complains that by enabling Flow on one page, we'll have "inconsistent discussion systems", but what alternative do we have for showing you (Meta-Flow-naysayers) how much of a difference it will make to us (Meta-Researchers)? --EpochFail (talk) 16:06, 23 November 2016 (UTC)
Yes, I manually picked the latest resolved tasks that I could find which were closest to being user-reported. I remind you that it's you saying that Flow is maintained and everything, against the latest official statement, so the onus of proof is on you, not the others. I don't know what the ORES comparison is for, so I'll skip that.
The RfC did not show such a consensus in the "subcommunity", as far as I can remember. As for ways to show the difference Flow will make, I guess one option is to study the impact of the usage of Flow on other wikis.
However, even before we start collecting evidence on what will be good for the wiki and the Research namespace, there might be a need to discuss and clarify the general goals and principles: it's certainly possible that there are conflicting goals here, e.g. «re-engineer scientific practice to be more open» may not be everyone's first goal. Nemo 17:14, 23 November 2016 (UTC)
I brought ORES into the discussion to challenge the assertion that Flow development is in an undesirable state for use in Meta.
When I asked JMatazzoni about the status of Flow development and support, he directed me to the quote I pulled from the Flow documentation above. "The [Collaboration Team] will continue to fix bugs, and make sure that people who are using Flow continue to have a good experience." I feel like that is a pretty clear statement, Nemo. What else do you want?
Regarding the past RFC, all participants who had actually edited in the Research namespaces (with the exception of you, Nemo) supported switching to Flow. All provided substance for their arguments while you provided almost no explanation -- claiming that you'd be "forced to stop" commenting on research pages if Flow was deployed. This is obviously not true and only betrays a strong ideological bias you have against the software -- usability aside. I think that shows a pretty clear consensus, honestly.
I understand that your first goal might not be to bring Science to Wikimedian practices of open discussion and open access, but it is something that those of us Wiki Research scholars active on Meta *are* trying to do. Do you feel like this is in conflict with Wikimedia's goals? I don't think so. I think it's clearly well-aligned and I don't understand how you could disagree. --EpochFail (talk) 18:19, 23 November 2016 (UTC)
  • Support Support This change would help people who want to participate in on-wiki discussions around a particular research project, and whose input would be valuable to that research project, but who are not comfortable using wikimarkup on talkpages, contribute to that project. As EpochFail says, it's about getting external collaborators working on-wiki and out in public. There also is nothing inherently wrong with exposing people to inconsistent discussion systems. I'm not aware of any principle of design that asserts that consistency trumps usability: the mechanism used for discussion should be designed to meet the needs of the target audience. Furthermore, we develop specialized workflows and workarounds across all our projects to address particular needs. We used a gadget on the Teahouse Q&A board to make it easier for newbies to participate, and there have been no negative consequences of that decision that I've seen (MZMcBride and I argued back and forth about this point extensively in the early days). Nemo_bis is your objection to Flow specifically, or would you also be opposed to enabling the Teahouse Q&A gadget (or another gadget-based solution) on this single page as well? Jtmorgan (talk) 19:48, 23 November 2016 (UTC)
    • Hi Jtmorgan. Yes, you were able to create your own special snowflake on the English Wikipedia called the Teahouse. Building infrastructure and tools that fit many use-cases is hard. Hacking together your own custom/one-off thing is easy. If you're interested in helping out with the hard work instead of marginally increasing our collective technical debt, both phabricator:T7642 and phabricator:T33919 remain unresolved. :-) --MZMcBride (talk) 18:53, 27 November 2016 (UTC)
  • I have no issue with this. – Ajraddatz (talk) 02:43, 26 November 2016 (UTC)
  • Support Support I have been using the Flow system for half a year on my home wiki and it works quite well. That does not imply that there are no problems with the system, but hey there are bugs all over Mediawiki, so it is no different than the rest of the code. — Jeblad 17:32, 27 November 2016 (UTC)
  • Personally, I think Flow is still pretty bad software and I don't really wish to see it spread further at this time. That said, as someone who doesn't use Special:RecentChanges here and who likely won't be impacted by the use of Flow on this wiki, it's difficult for me to oppose. --MZMcBride (talk) 18:56, 27 November 2016 (UTC)
  • Oppose I don't think Flow should be enabled on any pages here, no matter what the excuse. --MF-W 01:05, 28 November 2016 (UTC)

Quick summary: In support, we have Jtmorgan and EpochFail (me, the proposer) because we think it will make it easier for our collaborators to work with us. Jeblad supports saying that he has had positive experienced with Flow on another wiki. I also use Flow on another wiki and I would much rather use it than talk pages (FWIW, I have not drank the koolaide; I do not use VE because I'd rather write wikitext). Ajraddatz sees no issue with this proposal moving forward -- which I think implies light support.

MZMcBride is against this because he thinks Flow is "bad software" but admits he won't be personally inconvenienced. Nemo is against enabling flow on just one page because it might be inconsistent and has concerns over maintenance of Flow (despite clear statements documented above). MF-W opposes with no explanation.

To me, this reads pretty clearly. We have reasoned support from those who stand to benefit. I don't see a clear challenge to the "this will bring more contributors to Meta" argument. We have a report of positive experience from an actual Flow users. From the opposition, I see general statements about not liking Flow ("bad software") from non-users and concerns about it's maintenance state (that have been addressed).

So, this is a bit messy, but I see reasoned arguments (which stand unrefuted) in support and vague statements about software quality and maintenance (that have been refuted) in opposition. Given that Jtmorgan and I are the only ones who will be inconvenienced if things go badly and we'd only be enabling Flow on one page, I think this is consensus enough to move forward with the proposal. --EpochFail (talk) 21:42, 29 November 2016 (UTC)

How utterly convenient that you think your own arguments are unrefuted and opposers' refuted. Maybe an admin should rather determine the result (and I still think this section should be moved to Meta:Babel). --MF-W 15:02, 3 December 2016 (UTC)
Make a list of valid arguments for and against, and disregard who said what. It isn't that many valid arguments, most of what is written is simply opinions. A lot of people misunderstands our goal, thinking the goal is the use of specific tools, and thereby refuse to use anything but pure wikitext. — Jeblad 20:29, 3 December 2016 (UTC)
Hi EpochFail. I think saying Flow is pretty bad software is fairly relevant to a discussion about extending its usage here. Did you want to get into specifics about Flow's problems? If so, we could start with its gibberish topic page titles such as Topic:Rph3qplet97huylg. Or we could discuss how much vertical screen space a single-sentence reply takes up. Or we could examine the crazy low reply depth limit.
It's a bit strange to cast Flow critics as non-users. It's not as though most people here are blindly discussing an abstract concept. We're not discussing a future software product that's currently in the idea phase. It's because people have experienced Flow that they don't like it, in my estimation. --MZMcBride (talk) 08:05, 4 December 2016 (UTC)
I'm reacting "bad software" critiques, that have answers documented in Flow's FAQ. I'm not saying that everyone have to agree with choices that have been made, but I want people to know on which well-founded reasons these choices have been made.
Gibberish topic page titles are like that because of topics centralization. Flow has been designed to allow cross-pages and cross-wiki display. Imagine that you have that conversation on a personal "inbox", and also on Meta:Babel, here and on MediaWiki Flow board. That's possible with development that have to be done, but it needs an unique ID. It is not possible to have multiple topics titled Topic:Hello. However, it is possible to change topic names, to have something more explicit, like Topic:Hello-RdZ3SJY7W5Wtr, but still with that unique ID somewhere.
Vertical space is here to improve readability, compact discussions are not easy to read. That vertical spacing can be changed in your personal CSS.
Concerning replies, Flow has a different system than the not accessible one, based on definition lists, used on old-style talk pages: you don't indent to reply, you indent when you digress. It improves readability too. That's why discussions are like that everywhere else on the Web. Trizek (WMF) (talk) 09:40, 5 December 2016 (UTC)
Except you don't really "indent when you digress", you indent when you make a reply that's not the first reply to a post, even if that first reply was actually the digression, and you get the chronological ordering of the discussion out of whack when doing so. Or else you just shove your reply at the end and hope that context is enough to make it clear to everyone what you're actually replying to, and force everyone reading to follow the mixed-together threads of conversation without any UI guidance helping them to do so.
BTW, which "everywhere on the web" are you talking about? The only places that come to my mind seem to be encouraging one-off throwaway comments rather than in-depth discussion (or are email where messages are expected to include enough quoted context for each message to be entirely standalone).
P.S. To make it clear, I'm replying here in my personal capacity. Anomie (talk) 14:31, 5 December 2016 (UTC)
Hi Trizek (WMF). Your reply reads like that of a paid advocate for Flow, which is perhaps unsurprising given that that's pretty much your professional role. Sure, these questionable design decisions are documented, but that doesn't make them correct. These same criticisms have been brought up many times (a quick skim of mw:Talk:Flow confirms). My guess is that Flow will fail due to the stubbornness of the development team in these areas. Telling users, for example, to edit their personal CSS to fix the vertical spacing is not an acceptable workflow or workaround. I don't need to be convinced that the current discussion system is inadequate, but the proposed replacement is somehow worse. --MZMcBride (talk) 14:38, 5 December 2016 (UTC)
Anomie, my exemple of indentation was about Flow: it doesn't use indentation. The indentation system of wikitext talk pages is not intuitive: when do you indent? To each reply in theory, and you can indent more between two replies to digress. And you can go back to the first mine when the conversation has too much indentations. That's not intuitive -- for beginners, but not only. It also can be painful for an experienced user to understand how to indent; wikis have different ways to do that (colons and/or bullet-points, visual assistance while reading or not...). I think Flow is overall easier to use, and the survey I'm working on has results that confirm that (publication in December if everything goes well).
Replies to your question about "everywhere else on the Web" are in the FAQ.
MZMcBride, if you read me as a paid advocate, I'll also give you some background: I've been hired to be a community liaison because I was highly supporting Flow as a volunteer. Face-smile.svg I support Flow or at least a new structured discussion system because I believe in it. But I'm also very aware of that extension's weaknesses and I do my best to have improvements done. The survey will give us some information that may change things: I don't know if the result will lead to an abandon of Flow and the creation of a new project, or anything else. But I wish we will improve discussions.
We (the team) are aware of criticism made by some users. We also see silent users that use Flow daily and don't complain (despite my questions and requests for feedback). Documented decisions are criticized, they may not be correct, right; the problem is that I see most of time critiques based on "that's changing my workflow". I don't think that's always a valid argument. Re:Customize the interface: that's really common for advanced users, they also use gadgets. Remember that Flow is a work in progress. That's not a finished project and constructive feedback is still welcome to improve it (if there is a decision to improve it).
Trizek (WMF) (talk) 17:12, 5 December 2016 (UTC)
Trizek (WMF): You don't seem to have actually responded to my point, instead you seem to have constructed a strawman of some sort and replied to that instead.
Your FAQ link doesn't seem to mention at all what you are referring to when you say "everywhere else on the Web". The specific question you link merely quotes one guy who says branching conversations are bad (in his personal opinion, as far as I can tell, no examples given), and links to another guy in a footnote who uses StackOverflow and Twitter as his examples of "good" discussion systems. Anomie (talk) 17:27, 5 December 2016 (UTC)
I've been away for a while. It seems that there are a few points to respond to. MF-W, you have raised no argument at all, so your challenge to my assessments to the arguments made falls kind of flat, don't you think? Maybe you could make your own arguments and assessments rather than jumping directly towards attacking my qualities. It seems that Anomie has some concerns about the software in general. I think it's clear that these concerns don't outweigh the benefits to the users we would like to target in this deployment of Flow (ON ONE PAGE!!!), so I'd kindly like to ask him to take his general complaints to a more general forum. MZMcBride says that "saying Flow is pretty bad software is fairly relevant", but only provides his concerns about centralized topic IDs (which many see as a valuable feature) as an example that makes the software "bad". In the past, no arguments about what actually makes the software bad were made at all, so I appreciate his one example. However, I feel like that one example does not detract from the usefulness to newcomers (specifically academic researchers whom I collaborate with) in the Research namespace (in which none of the opposers are active -- even Nemo these days). To state it simply, those of us who are active there (and would be affected) really want to see this happen and I would appreciate if that is taken into consideration. Can someone who opposes this at least acknowledge that they won't be affected by this -- and that everyone who will' be affected by this is in support?--EpochFail (talk) 16:16, 8 December 2016 (UTC)

Abusive User:Ibrahim.ID from the Arabic Wikipedia apparently active on this forum[edit]

A user called User:Ibrahim.ID made a comment on this page on 5 November. This appears to be the same abusive admin from the Arabic Wikipedia who wrote the things I translated here and here, and who ignored repeated requests to comment.

If this is the same user, then it appears that he can read and write in English, and he has an account here. How come that he does not explain the nasty things he wrote?--HD86 (talk) 02:53, 26 November 2016 (UTC)

He was active again on 28 November. He is frequently active on this site and there is probably no practical reason for why he refuses to respond. The only explanation is what he himself told me in the translated messages: he thinks he is too good to talk to someone like me.

It is a shame on Wikimedia to allow a person who said such things to be part of your community. You should at least comment on his behavior and say that it is unacceptable. If you do not do anything, he will keep doing what he does and he will abuse other users.--HD86 (talk) 23:58, 5 December 2016 (UTC)

Wikipedia talk:Teahouse[edit]

It's been brought up that someone from the WMF may want to comment on this conversation regarding the Teahouse on en.wikipedia. Not sure if this is exactly the right place for it, but it seems close-ish. Timothyjosephwood (talk) 21:01, 28 November 2016 (UTC)

Thanks, Timothyjosephwood. I saw and replied. Jtmorgan (talk) 21:29, 28 November 2016 (UTC)

"Mother page" ( content[edit]

I am not sure where to ask, sorry if a wrong place. And it is not some immediate issue, more just curious.

Who is in charge of the Wikipedia "mother page" ( layout and content? Any particular person(s) or the Foundation anonymously? Also what are criteria and source of the displayed Top-10 Wikipedia projects? I do remember a guy (a steward?) once explained it at Jimbo talk page, but I cannot recall now any key words to find it. --NeoLexx (talk) 14:10, 3 December 2016 (UTC)

See Project portals. --MF-W 15:00, 3 December 2016 (UTC)

Ombudsman Commission - selection for 2017 committee[edit]

Hello all, It's coming close to time for annual appointments of community members to serve on the Ombudsman commission. This commission works on all Wikimedia projects to investigate complaints about violations of the privacy policy, especially in use of CheckUser and Oversight tools, and to mediate between the complaining party and the individual whose work is being investigated. They may also assist the General Counsel, the Executive Director or the Board of Trustees in investigations of these issues. For more on their duties and roles, see the Ombudsman commission's main page.

This is a call for community members interested in volunteering for appointment to this commission. Commissioners should be experienced Wikimedians, active on any project, who have previously used the CheckUser/Oversight tool OR who have the technical ability to understand the CheckUser/Oversight tool and the willingness to learn it. They are expected to be able to engage neutrally in investigating these concerns and to know when to recuse when other roles and relationships may cause conflict. (In the past, commissioners have retired from other roles that could cause conflict.)

Commissioners must be willing to identify to the Wikimedia Foundation and to comply with the appropriate board policies (such as the access to non-public data policy and the privacy policy. This is a position that requires a high degree of discretion and trust.

If you are interested in serving on this commission, please drop Karen Brown in the Support & Safety team ( a note detailing your experience on the projects, your thoughts on the commission and what you hope to bring to the role. The commission is deliberately quite small, so slots are limited, but all applications are appreciated. The deadline for applications is January 2. Any timezone. :) Please feel free to pass this invitation along to any users who you think may be interested. Thank you! Patrick Earley (WMF) (talk) 21:18, 9 December 2016 (UTC)