Commons:Village pump/Proposals/Archive/2018/03

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Rate limit

My alt User:Artix Kreiger 2 hit a rate limit with Visual File Change to 8 edit every 60 seconds. What? Artix Kreiger (talk) 19:52, 2 March 2018 (UTC)

You're probably exceeding the preset amount for the number of requests to send to the API simultaneously. While certainly not recommended and highly frowned upon, when adjusted, you could theoretically achieve up to 500+ edits per minute. ~riley (talk) 21:01, 2 March 2018 (UTC)
Resolved

Artix Kreiger (talk) 21:17, 2 March 2018 (UTC)

This section was archived on a request by: Zhuyifei1999 (talk) 00:51, 11 March 2018 (UTC)

I started a discussion about policy on the use of gallery pages at Commons talk:Galleries, concerning usability and linking to categories. Comments welcome. Cnbrb (talk) 16:42, 13 March 2018 (UTC)

SVG diffs

SVG is a text based format. It would be nice to easily see diffs between versions of SVG files. Palosirkka (talk) 09:27, 15 March 2018 (UTC)

I don't think anyone would be opposed to this, but it's more of a Mediawiki feature request than a community decision and therefore belongs in Phabricator rather than here. In fact, it's already there – twice (phab:T44566 and phab:T154176 look like duplicates to me). But WMF developers are busy with things we don't want like Media Viewer, Visual Editor and Cross-wiki Copyvios, which means things we do want (like this) gets the priorities "Low" and "Lowest". —LX (talk, contribs) 20:00, 15 March 2018 (UTC)

Flow - WMF's proposal

There was a recent consensus to uninstall Flow, as was done on EnWiki and Meta. The WMF is offering a new and different proposal.

When Flow is uninstalled it leaves behind broken log entries. At this time, the Wikimedia Foundation does not consider the broken log issue serious enough to fix for EnWiki, Meta, or Commons. However the Foundation has indicated that they will not oppose any volunteer developers who wish to work on fixing the the log issue (Phabricator task T188577). At this time, the Foundation position is that they do not want to uninstall Flow so long as the log issue exists.

The WMF has interpreted the uninstall consensus as a request to expand and improve Flow. Specifically they began work on a new Flow feature, adding a read-only mode (Phabricator task T188577). This mode would ensure that the WMF, or anyone with global Flow-creation-rights, cannot inadvertently create a Flow page here without first removing the read-only setting. The WMF believes this satisfies the goals of the existing consensus.

The WMF proposes completing work on the Flow improvements and deploying the new read-only Flow mode to Commons.[1]

Is there a desire to convert Commons-Flow to the new mode? Alsee (talk) 14:36, 11 March 2018 (UTC)

Responses (Flow)

  • No. The WMF's proposal is worse than useless. I trust the WMF not to create new pages here, and if such a page were to appear it can just be speedy deleted per existing consensus. Once the logs are fix we can reconsider uninstall.
    I'd like to quote Jdforrester, a lead project manager at the WMF: "Custom configurations for each wiki slightly slow down the sites for every reader and editor, and complicates Ops' work", and he further describes such custom configurations as "a security risk".[2] Commons is the only site slated to use this Flow configuration. (Note: The WMF's 'technical' arguments have been rather POV-driven. The WMF opposed uninstall based on the above "custom configuration" argument, however uninstall would only make Commons conform to the largest wiki (EnWiki) as well as our global hub (Meta). Then the WMF wants to put Commons into a unique new configuration in order to prevent uninstall. As Jdforrester explained, there are solid technical reasons not to do that without a good reason. Then WMF tries claim the logs are serious enough to prevent uninstall, while simultaneously claiming the issue is too insignificant to fix for EnWiki and Meta. Then the WMF wastes work building a useless new Flow mode instead of just fixing the logs.) Any work to build, test, apply, or maintain this custom configuration would be a complete and utter waste. I am not afraid new Flow pages will appear, and if they do appear we already have a delete button for unwanted pages. This only serves to make Flow bigger and more complex.
    The new Flow feature claims to achieve the goals of the original proposal. As the WMF appears interested in those goals, and appears to have difficulty understanding those goals. I will attempt to list some goals, as I view them. This list is not necessarily complete. The new Flow mode does nothing to address:
    1. Eliminate all side-effects of the Flow installation, including but not limited to an entire namespace (Topic).
    2. As long as Flow is installed the code continues to execute, listening-for and handling all Flow-commands sent to it over the internet. The new Flow code merely adds another layer of complexity to processing commands sent to Flow. As Flow is unused here, there is no justification for Commons to be subject to undiscovered bugs that currently exist in Flow. There is also no justification for Commons to be subject to bugs in ongoing changes to that code. The fact that the code is running and processing incoming internet messages opens an additional door for security threats. There's a very good reason standard computer security practice is to remove code that isn't being used, most importantly anything that is listening for commands from the internet.
    3. Developer time is a valuable commodity. There's an endless backlog of things that we want and need. Every dev-hour spent expanding or maintaining Flow is a dev-hour diverted away from things we do want and need. Wasting time building an utterly useless new Flow mode just compounds the problem.
    4. Hoping for the WMF to stop persistently and pathologically re-interpreting every criticism of Flow as a community request to expand work on Flow. The WMF's current proposal a painfully ironic repetition of this.
    5. Another hoped-for goal is for the WMF to stop refusing to improve talk pages, and the continual response that we have to switch to Flow if we want anything. Yes, we want improvements, no Flow is not an improvement. Either improve talk pages, or start a new project from scratch. Having Flow installed everywhere is fueling ideas that Flow is progressing towards globally replacing talk pages. Any improvement to talk pages are treated as wasteful and directly undermining an eventual switchover to Flow. Flow is resulting in sabotage-by-neglect of talk pages.
    6. In case I missed anything, I suggest the WMF consider how they would respond to a request for LiquidThreads to be installed and left unused, while people were writing and deploying major changes to that code. It's a zombie project. Flow is LiquidThreads2. Having unused Flow installed here is nothing but a hazard and pure technical debt.
      Alsee (talk) 14:36, 11 March 2018 (UTC)
  • Yes and I find the title here totally disingenuous. The "new mode" is a complete disabling, functionally equivalent to removing Flow. The developers say they have more confidence in the stability of the system by doing this than by physically removing the code, and I se no reason not to extend them good faith. As remarked above, "Developer time is a valuable commodity." If they say this way of achieving the desired functional result is expected to require less developer time, I don't see any reason to doubt them. - Jmabel ! talk 16:29, 11 March 2018 (UTC)
  • Meh (but more importantly, Objection to the absurd rhetorical framing of this section) - "The WMF has interpreted the uninstall consensus as a request to expand and improve Flow" is a bizarrely misleading frame to put on this question. That makes it sound like they said "nevermind what you all want, we're going to keep making Flow BIGGER and MORE INTRUSIVE" as opposed to reality which is that putting it in read-only mode is specifically to accommodate the community's request not to use Flow on Commons without creating those log issues. Whether it's the best approach, I don't know (mainly per my comments in the other thread). — Rhododendrites talk |  15:47, 17 March 2018 (UTC)
  • I feel as Rschen7754 below, but overall I object as this is not what was requested and decided. The English Wikipedia had hundreds of topic pages, all of them got removed and the wiki is up and running without issues. Meta-Wiki problem was that they wanted a Flow board migrated, they did so and removed the extension and Meta-Wiki is also up and running without issues. As for Commons: similar situation as was with Meta-Wiki, except that there are no Flow boards to migrate and every Flow board can go. I'm (and others) are still waiting for a convincing reason why Flow cannot be removed in the same fashion as enwiki and metawiki. People with tech knowledge on the Phabricator task is also arguing about the lack of reasons not to do the same here. Thanks, —MarcoAurelio 18:22, 17 March 2018 (UTC)
  • I agree with Rschen7754. With all due respect but I find the WMF's defence a bit odd. If uninstalling flow really creates so much problems. Why do it a second time. I would appreciate a statement that there will no more pilots with invasive and hostile software in the future. And let's stop pretending that uninstalling and using a kill switch are the same thing. Perhaps they are the same in developers-jargon but they are not the same for ordinary people. Let’s translate the situation to an everyday situation. Someone installed software you don’t want so you go to the computer store because you don’t know how to uninstall the software. The next day you go back to the store believing that the software is uninstalled because that is what you asked for. To your surprise the personal tells you that the software isn’t uninstalled but they made sure you cannot use it anymore. I can’t speak for the WMF-developers but I wouldn’t accept such a situation. So no, let’s not try to fool us by trying to convince us that uninstalling and a kill switch are the same thing. Natuur12 (talk) 14:50, 26 March 2018 (UTC)
  • Natuur12's comparison appears to be accurate. Flow is still around and visible in various places, where it consumes valuable screen estate and otherwise consumes our limited user resources. For instance I see the namespace in Special:AllPages and a list of titles which, if clicked, present the user with some confusing warnings. Is work still ongoing? Because this seems quite far from the proposed "functional equivalent of uninstalling", which would mean making sure the user can never bump into any trace of Flow from the present user interface and can never tell it was ever installed other than by clicking on actual proofs that it was (such as old URLs, logs). --Nemo 17:52, 26 March 2018 (UTC)

Discussion (Flow)

  •  Comment I don't see any need to "delete" or to "uninstall" anything, if the community don't want a development of this tool, it's fine. Just let the things as they currently are, a test, and forgot these pages as a dead project, that's all. Again some work and potential technical issues for nothing, IMO. Christian Ferrer (talk) 17:23, 11 March 2018 (UTC)
  •  Comment In the conversation that we've been having this week, I said that the WMF is happy to support the goal of these proposals, which is to remove Flow from Commons. We're going to do that by deleting the existing Flow pages, and then deploying a config change that will ensure that nobody is able to create any new Flow pages or posts. This is what Alsee describes above as an effort "to expand and improve Flow," which I find puzzling; it's actually doing the exact opposite of that. We agree that Flow should be removed from Commons, and that's what we're doing. The specific technical implementation of how the developers will achieve that goal isn't up for community consenus. Choosing the best technical solution for a problem is a job for the experienced developers on the team. I look to them for information and judgment on how to implement a solution; that's what they're for.
However, as Alsee has offered six more goals for the project, I'll respond to each one.
    1. "Eliminate all side-effects of the Flow installation, including but not limited to an entire namespace (Topic)." In the plan that I've described, the Topic namespace will be deleted and disabled; nobody will be able to use it anymore.
    2. Alsee is concerned that deleting and disabling Flow will still leave Commons open to experiencing bugs related to the Flow code. That's not the case; bugs that affect Flow shouldn't affect wikis that aren't using it. He's also concerned that there are security risks involved in code that is "listening for commands from the internet." Security risks in the code are evaluated and handled by our senior developers.
    3. "Developer time is a valuable commodity... Wasting time building an utterly useless new Flow mode just compounds the problem." It's true that developer time is expensive. Our senior developers have determined that deleting and disabling Flow is the most efficient way to achieve the goal of removing Flow from Commons. Uninstalling the Flow extension would take a lot more time, and would involve more risk.
    4. "Hoping for the WMF to stop persistently and pathologically re-interpreting every criticism of Flow as a community request to expand work on Flow." I believe that goal is being met; criticism of Flow on Commons is resulting in the removal of Flow from Commons.
    5. Alsee wants the WMF to work on fixing problems with talk pages, rather than deflecting those conversations in order to support the Flow project. I agree with this goal. We're currently finalizing the Annual Plan that will be submitted for the 2018-2019 fiscal year, and the plan includes a large-scale community consultation about fixing talk pages -- starting from the beginning, by coming to consensus on the problems that we all agree need to be fixed. This conversation that we're having right now isn't the proper venue to have that discussion; it'll happen during the 2018-2019 year. The action that we're taking to remove Flow from Commons doesn't affect that future consultation one way or the other.
    6. "I suggest the WMF consider how they would respond to a request for LiquidThreads to be installed and left unused, while people were writing and deploying major changes to that code." That would actually be perfectly fine; I'm not sure why Alsee thinks that would be a problem. Again, the decisions about technical implementation should be made by our senior developers.
I believe that addresses all of the concerns, but I'm happy to continue discussing it, if people want to. -- DannyH (WMF) (talk) 19:27, 11 March 2018 (UTC)
  • I think that the desire of Commons to have the extension completely uninstalled should be respected. But, it does not have to be done today. If this "kill switch" is to be used as an interim solution, then so be it, but it should not be the permanent solution. --Rschen7754 19:54, 11 March 2018 (UTC)
  • DannyH (WMF) it was just announced that the new mode is scheduled for deployment on Commons the day after tomorrow. I'm really hoping you can tell me this is simply due to a communication gap, and that the WMF isn't deliberately deploying the mode here while there's an RFC underway. Thanx. Alsee (talk) 14:13, 17 March 2018 (UTC)
Alsee, as I've said before, the specific technical implementation for how we remove Flow from Commons is not up for community consensus. It's a technical decision, which is made by the senior engineers. We're following the community consensus to remove Flow from Commons. -- DannyH (WMF) (talk) 15:26, 17 March 2018 (UTC)
DannyH (WMF) is there a communication problem here? We are not discussing the previous consensus. We are discussing a new one. (The RFC is currently running neutral, and the result could go in either direction.) Are you saying that the Read-only-mode is MANDATORY, PERMANENT, AND IRREVOCABLE? Are you saying that the WMF preemptively refuses any and all future consensus result to remove read-only status? Are you asserting that once read-only status is applied, that there is some technical reason that it would be dangerous to ever remove it? Alsee (talk) 06:55, 18 March 2018 (UTC)
Alsee, we are following the consensus to remove Flow from Commons. The specific technical implementation for how we do that is up to the engineers, and is not up for community consensus. We're going to remove Flow by deleting the two existing Flow pages and disabling the feature. We've exported all the conversations from those two pages, and I've posted them here: User:DannyH (WMF)/Commons Flow export and User:DannyH (WMF)/Flow tests export. Then we're going to use the "kill switch" config change to make sure that nobody can create any more Flow pages or Flow posts. This RfC is objecting to the config change. As I said, the specific technical implementation for how we're going to remove Flow from Commons is not up for community consensus. -- DannyH (WMF) (talk) 18:03, 18 March 2018 (UTC)
DannyH (WMF) you are not answering the question that was asked. Do you not understand me, or are you deliberately not answering?
I'll try to make it clear and easy for you. If two years from now, Commons has a consensus that Flow is better and we want opt-in Flow userpages like Chinese Wiki has, will the WMF enable it here? Alsee (talk) 18:41, 18 March 2018 (UTC)
Alsee, I guess I didn't understand you; thanks for the clarification. Yes, if Commons wants to use Flow later on, it will be possible to undo the config change. The same is true if we uninstalled the extension; it would still be possible to reinstall it. Does that help? -- DannyH (WMF) (talk) 22:19, 18 March 2018 (UTC)
DannyH (WMF) now we are making progress. As you just said, a second consensus can lift the read-only config. This is RFC on whether read-only config should be applied on Commons. If the config is applied while the RFC is in progress then it may result in consensus to immediately lift that config.
Actively forcing out an unwanted config would be far worse than passively doing nothing in response to the previous consensus. Alsee (talk) 05:13, 19 March 2018 (UTC)
Alsee, the current consensus is to remove Flow from Commons. We're following that consensus, and the specific technical implementation that we're using is to delete the pages, replace them with wikitext exports, and then use the config setting to disable Flow completely. At that point, if the Commons community had a consensus to bring Flow back to Commons, we would follow that, and the technical implementation that we would use is to remove the config setting and allow people to create more Flow pages. In both cases, the technical implementation would be up to the senior engineers to decide, and isn't up for community consensus. If you would like to restore Flow to Commons, then you should start an RfC about that instead. -- DannyH (WMF) (talk) 05:23, 19 March 2018 (UTC)
@DannyH (WMF): The problem is trust. Trust in the reasons given here and the motives behind that reasons.
Flow was advertised as a software, that has no negative implementations if it would be removed. Now you say, that it has so massive negative impact if you uninstall it even on a wiki, where it had only two pages for testing purpose, that it must not be uninstalled, in other words: it's a very dangerous peace of software, that must not be deployed anywhere else until this proclaimed danger is eliminated. If the software is really that dangerous as you and the devs proclaim here, why didn't you pull the emergency brakes asap as you noticed it, and stopped any deployment anywhere else? Why do you want to infest projects with this, as you say, dangerous piece of software, if they only want to test something? An imediate stop of deployment would have been the first step, if you really regard this software as unretractable. And as you didn't do this, there are two possible motives: You didn't want to compromise a pet project by some devs even against known dangers, like it ad been done with VE and MV, or your claim about the danger is just overblown to keep it installed with some strawman reasons.
A piece of software, that is as dangerous as you proclaim that Flow is, should raise red alerts as soon as the danger is known, but nothing has happened from the devs, it was all up to the community to react. Why was this so? Sänger (talk) 05:41, 19 March 2018 (UTC)
DannyH (WMF), while I agree with Sänger's comment above, I fear it is creating confusion when uninstall arguments are mingling with the read-only topic. I request that you carefully note that I am trying to draw a line between the two topics.
You can't claim to be following an older law if you directly violate a newer one. You can't claim to be following a boss's older instruction when you directly violate a newer one. If the result here is that Commons doesn't want to be configured read-only, you can't claim you are following an older consensus. That is obviously invalid.
You can stand on the bad-ground that the WMF is unwilling to spend money fixing the log issue and therefore unwilling to uninstall Flow, but you cannot claim an older consensus trumps a newer one. You can't claim Commons is set to read-only because of an old consensus if the newer result doesn't want read-only. That would be compounding passive-disregard for the first consensus with an active assault against consensus. Alsee (talk) 16:01, 19 March 2018 (UTC)
Sänger: There's no practical difference between "uninstalling" Flow (as we did on English Wikipedia) and "disabling" Flow (which is what we're going to do on Commons). In both cases, the Flow pages are deleted, and there's no way to access them or create any new ones. The only difference is what the backend code looks like, and it's up to the engineers to determine that. Roan says that the redlinks for deleted Topic pages throw errors when the software doesn't know what Topic pages are anymore, and the team had to invest unnecessary time in dealing with that when they uninstalled Flow from English Wikipedia. This isn't a crisis that requires global action; it's just the engineers determining the best way to accomplish a goal.
For your larger point, I know that you're saying that you don't trust my word or the word of the engineers, and that you suspect that we're lying in order to protect a pet project. I agree with you that sometimes WMF product teams have not been honest about their motivations in the past, and that has been damaging and unnecessary. I'm not doing that here, but I'm not surprised that you don't believe me. All I can do is act in a trustworthy way. In this case, that means that we're removing Flow from Commons, and uninstalling it from wikis that haven't used it. We don't want to uninstall it here, because as I said, it's a lot more work for no practical benefit.
Alsee: What I'm saying about the RfCs is that the specific technical implementation of how we remove Flow from Commons is not bound by community consensus. We're removing Flow from Commons, which I believe is the outcome that you want. The specific way that we accomplish that goal is not determined by this RfC. -- DannyH (WMF) (talk) 17:24, 19 March 2018 (UTC)
There's a huge difference: Either to get completely rid of Flow, or to just insert a software switch to disable Flow for now. Is there a possibility to restrict access to the software switch to commons bureaucrats, and completely lock out every single dev and functionary from the WMF? That would be a fine solution, but as long as everything stays as it is, and only a weak software switch, that any dev can change at will, I don't trust the solution. I've seen what evil dev can do with the horrific stuff Eric perpetrated with superprotect. IIRC he was not sacked for this despicable behaviour, not even officially reprimanded. <pa censored> If the WMF gives up completely about Flow, and really, even technically, surrenders to the community, a simple software switch is not enough. Sänger (talk) 18:25, 19 March 2018 (UTC)
Sänger: The ticket for the "kill switch" disable-Flow setting says that nobody can create Flow pages, regardless of user rights. Bureaucrats, stewards, etc won't be able to do that. The only way to enable Flow will be for the engineers to turn off that config change. This is also the case for uninstalling Flow -- again, the only way to enable Flow would be for the engineers to reinstall it. Both methods are functionally the same. For the other issues: I agree with you that superprotect was a bad idea, and in the past, product managers have made other foolish errors, including me, unfortunately. I'm working to make sure that we learn from those mistakes. Erik and Fabrice haven't worked here for several years. But the people who are here now need to earn trust, by being trustworthy people. -- DannyH (WMF) (talk) 18:40, 19 March 2018 (UTC)
That "Kill Switch" is inserting a meagre line of code somewhere, that can be removed at whim. It's not a de-installation of that unwanted stuff. How can devs be barred from being able to change that line without community consensus? Methinks the re-deployment of Flow is a bigger effort than just removing/disabling a line of code. Sänger (talk) 19:16, 19 March 2018 (UTC)
We don't have rogue engineers who will re-enable Flow on Commons for no reason. I think everybody agrees that the question of whether Flow is on Commons is a big deal, and not something that someone would do lightly. We're removing Flow from Commons now, and I don't see any reason why that would change without serious discussions. -- DannyH (WMF) (talk) 00:33, 20 March 2018 (UTC)

And a heads up in general: I posted on the thread at Commons:Village pump that we've deployed the two tickets that we've been discussing: the Flow "kill switch" and "uninstall Flow from wikis that aren't using it". We're doing this as part of the consensus to remove Flow from Commons. Obviously, I know that Alsee has been opposing the "kill switch" config change, but that's an issue of the specific technical implementation of the remove-Flow consensus, which is up to the engineers to decide. -- DannyH (WMF) (talk) 18:53, 19 March 2018 (UTC)

DannyH (WMF) if the application of read-only turns out to cause any problems and it has to be lifted, are you willing to give your personal assurance that it will not be reapplied without an explicit consensus to reapply read-only? Alsee (talk) 22:49, 19 March 2018 (UTC)
Alsee: I'm sorry, I don't think I understand your question. "Read-only" isn't a feature of the product, it's the mechanism we're using to remove and disable Flow on Commons. Using that specific technical implementation step is up to the engineers, and isn't up for community consensus one way or the other. Does that answer your question, or am I missing something? -- DannyH (WMF) (talk) 00:33, 20 March 2018 (UTC)
DannyH (WMF) what you are missing is that the WMF deployed read-only in a disruptive state. The two pages could not be removed from the maintenance category for active deletion workflows. The false categorization could not be removed by non-admin workers, it could not be removed by administrators, it could not even be removed even by WMF staff without invoking a site-reconfiguration to lift read-only first. However that problem appears to have been circumvented when the deletion-result was unexpectedly changed from keep to delete. Deleting the entire page indirectly eliminated the irremovable workflow category. I will be quite unsurprised if other problems, potentially more serious, arise from this read-only kludge. I really don't want to pile on yet another lie / broken-promise from the WMF when your claims turn out to be false that read-only is functionally equivalent to uninstall. Flow pages were deployed here without consensus to do so, and based on a claim that there were "minimal ramifications from enabling two testing pages".[3] Yet here you are saying that the ramification of creating even a single Flow page is that the extension is permanently unremovable. Of course that is also false. Whether it's 2 years or 20 years or more, the software is eventually going to be removed as obsolete. All of the work building read-only, and all of the time spend arguing over it, will be nothing more than pure-waste. All of that time and effort wasted, just to expand and perpetuate the technical debt of an eventual uninstall. Alsee (talk) 18:56, 20 March 2018 (UTC)
Alsee: Well, it sounds like the immediate issues here have been solved. It sounds to me like your concerns are more about what might happen in the future -- an unexpected deployment decision, or technical issues that might arise from the config change. I guess we can pick up that conversation later on, when something changes. -- DannyH (WMF) (talk) 19:04, 20 March 2018 (UTC)
DannyH (WMF) the fundamental problem for years has been a bad WMF-Community interface. You have abundantly acknowledged past problems above, and for the 300th time we're being told we can't fix the past but you'll do better today. You say above how you want to build trust, yet today you're repeating the same exact problems.... and even managing to find new areas to further destroy almost non-existent trust.
One of the repeating themes is that the WMF builds code in secret, or builds code after being strongly alerted that there is a problem, and then the WMF gets locked into destructive modes of doubling down on the already-built code. And look what's happening again. Read-only got built in secret. It was actively kept secret, while people were banging on the doors asking what was going on behind those secret doors. You tell me, does building code in secret build trust? If the software had been built in good-faith, you would have offered the solution. Instead the WMF entered trench warfare mode, doubling-down on that the code had to be used whether it was wanted or not. You explicitly stated that you would ignore any consensus to lift read-only mode. You tell me, does a declaration that you are going to ignore the community build trust? And here's my main question:
If there is a newer consensus lift read-only, why are you entering battle mode against it? Can you cite any technical reason that the wiki can't be left with no Flow pages and without read-only? It doesn't even have to be a technical reason, can you cite any non-technical reason that you would actively oppose the community if it wants read-only lifted? The only rationale you offer (repeatedly) is that you are claiming to be following an older consensus. That is either a gross misunderstanding of consensus or it's an empty excuse. A newer consensus always takes precedence over any older consensus. You have verbalized no comprehensible reason for doubling-down read-only. Of all the reasons I can imagine for you to oppose liffing read-only, none of them are good. Please, help me stop imagining bad reasons. Please, offer me one good reason that you would actively oppose a consensus to lift read-only. Alsee (talk) 21:22, 20 March 2018 (UTC)
Alsee, I think one problem here is that you're seeing "read-only" as a feature that matters. It's intended as an extra lock on the door, so that we could delete all the Flow pages and make sure that nobody will try to create any new ones. I don't think anybody is interested in doing that, but we figured it would help people breathe a little easier, knowing that the door is double-locked. Besides that extra security, it doesn't do anything. So I can't imagine a reason why someone would want to remove the double-lock, and still keep Flow deleted. It wouldn't serve any purpose. So I don't understand what the practical reason is for why you want to remove that lock. I do understand the principles that you're talking about -- that WMF product teams should be communicating more, there should be less done in secret, product teams should be more up front about plans and motives. I feel like I've been doing that. We removed Flow from Commons because Commons doesn't want to use it. We double-locked it so that everyone would know that it wasn't being used here anymore. We didn't do the "uninstall" because it would have been a waste of time and money, for no practical purpose. That's it. I'm not in battle mode, because there isn't anything to battle here. You wanted Flow off Commons. Flow is off Commons. I'm pretty sure we can just move on and work on something else. I'm sorry if there's something I'm not seeing, but I don't think there's anything to fight about. -- DannyH (WMF) (talk) 23:09, 20 March 2018 (UTC)
DannyH (WMF): "we figured it would help people breathe a little easier, knowing that the door is double-locked" that is certainly a reasonable thought, however what happened is that the WMF locked us out of the room and decided among yourselves what to put in our heads. If there had been open communication we could have discussed the available options, and only built read-only if it was actually worth doing. And please note that you did not answer my question. You say that you don't think there's anything to fight about, but you're here declaring that the WMF will ignore any consensus against read-only. If the community considers read-only to be worthless or even detrimental, why push it out and then fight against removal?
I see that you are making a major effort to engage here. But are you here so that the WMF and community to work together to figure out what we're going to do? Or are you here on a PR mission to smooth over rollout of the secret internal decision? It's hard to have a constructive discussion when you're saying that the secret-discussion result is irrevocable and the community will be ignored. Alsee (talk) 03:16, 21 March 2018 (UTC)
Alsee: I want to go back to a separation I was talking about earlier: the Goal and the Implementation. What I mean by "Goal" is the actual, practical outcome that people will notice -- what happens on the user end. In this case, the goal was to get rid of Flow on Commons. That goal was achieved by deleting the pages, replacing them with wikitext exports, and making a config change so that nobody can create any new Flow pages. That's done now; goal achieved.
What I mean by "Implementation" is the code that the developers use to reach that goal. In this case, the config change that you're referring to as "read-only" is a change in the code. You can't see it from your end.
During this conversation, I've said something several times: the specific implementation that the engineers use is not a matter for community consensus. The community does not vote on what happens in the code. That is something that the engineers do. You absolutely get a say in what happens on the site -- in this case, Flow not being on Commons anymore. But you don't get a say in what the code looks like. The config change is part of the code, and you do not have power over what happens in the code. So when you say that you want to hold RfCs for or against a specific piece of code, then I have to say no, we will not respect community consensus either for or against specific lines of code. We don't write code by community vote. I'm not battling over it, because it's not something that you and I battle over. It is not a thing that you influence.
As for my motives, and why I'm engaging: I'm here talking to you because it seems like you're really upset, and I wish that I could reassure you that things are actually okay. I understand why you're suspicious that you're being lied to -- in the past, people have lied to you. I'm not lying to you now, but I get why you think I would be. But I know that there's nothing underhanded happening here. Flow has been removed from Commons. We can really just move on. But you're having a hard time, and it's obviously just you and me paying attention to this conversation, so I figure I'll keep talking and maybe it'll help you feel better. -- DannyH (WMF) (talk) 03:40, 21 March 2018 (UTC)

The problem with trust and Flow is, there is not that much trust about Flow, as it's sold to the communities with false presumptions, a non-existent dichotomy between VE and Flow is propagated by the marketeers of Flow. There was even a "survey" about Flow, where against the facts this dichotomy was very central, used as a promotion for Flow. This "survey" was as well deliberately sent only to proselytes to bend the outcome towards Flow even more. If you don't stop spreading falsehoods about VE on talkpages just to promote Flow (and the renaming of Flow to "StructuredDiscussions" for pure promotional reasons against the fact that current discussions like this are structured as well, just more flexible, is part of that enterprise), why should we trust the devs and the marketeers in the WMF about Flow? Sänger (talk) 05:30, 21 March 2018 (UTC)

Sänger: I agree, there's been a lot of hype for Flow that was not really honest, and that made it counter-productive, just frustrating people and doubling down on arguments that don't go anywhere. I became the Director of the Contributors team a couple months ago, and one of the things I'm doing is helping all the teams move away from that style. WMF product teams need to communicate a lot more, and a lot earlier, and we need to take criticism seriously. When people are upset, we need to reflect on our own motives and behavior, and make sure that we're doing the right thing and telling the truth. We're working right now on documenting those principles, and posting them on mediawiki. But I know that's not a thing that I can say, and have people instantly believe us and trust us. Trust is something that you earn, and I'm actively working with the product teams on earning that trust. -- DannyH (WMF) (talk) 16:44, 21 March 2018 (UTC)
OK, it's a bit hard to believe as long as in topics like this one the devs wanted to close with false reasons, just to let the discussion die and still ignore, are still without a valid answer, and this post by me in that thread was hidden by an IP-vandal, and nobody tried to undo that (I can't, because they banned me first for my (perhaps a bit too) outspoken opposition against Flow, and a month later for no reason at all). In this topic the devs make the false claim, that a structure is not a structure, and that machine readability is something most desirable for talk pages, where primarily humans interact and machines are not even secondary. They simply don't listen to anything that affects their project in a possible negative way but insist on their rose-coloured perspective. It's quite frustrating to see, that any valid argument is just brushed away, even with proven falsehoods, and you get banned obviously for saying so.
It would be a bit more believable, if those who spread those stuff in the past to promote this project would show signs of re-evaluating their attitude and start listening to the communities, and not only the proselytes. Sänger (talk) 19:02, 21 March 2018 (UTC)
Sänger: Yes, those are examples of the kind of behavior that I am working to change. Some of the people involved in those discussions no longer work in that capacity. I'm working with everyone to learn from those mistakes, and stop acting that way. It's a long-term goal that will take a lot of work. I agree with you that that is not the way that Foundation product teams should respond to members of the community. -- DannyH (WMF) (talk) 01:50, 22 March 2018 (UTC)
DannyH (WMF) you said teams should be more up front about plans and motives. Do I need to note again that you are not being up front about your motives? You're not gaining any trust when you don't live up to your own words, when you're being glaringly evasive. Do I really need to ask again why you care if read-only is active?
You said above "one problem here is that you're seeing "read-only" as a feature that matters", implying that it does not matter. Then why do you care if read-only is active? I'd really like to get back to more substantive matters, but we're stuck discussing why you are unwilling have those discussions. We're stuck discussing why you're being glaringly evasive. Alsee (talk) 09:50, 21 March 2018 (UTC)
Alsee, I feel like you're not understanding the main point that I'm making. I really am answering your questions, but there's a disconnect that I can't figure out how to bridge. Please tell me if the following sentence makes sense to you: WMF engineers and product teams make decisions about writing and maintaining backend code, and those coding decisions are not up for community consensus. Can you tell me if you understand what I mean? -- DannyH (WMF) (talk) 16:44, 21 March 2018 (UTC)
DannyH (WMF) I think I do understand you. In a better universe we would be working as partners in good faith with abundant trust and abundant understanding. When it comes to technical, legal, and consensus: Technical and legal should only be pulled out as trump-cards in good faith, when there are indeed technical or legal issues that override all other concerns. And in those cases, that should be the end of that. As you noted, sometimes WMF product teams have not been honest about their motivations in the past. A supposedly technical decision that is driven by non-technical motives is not a technical decision. That is a decision on the non-technical agenda. I think only case where a good-faith technical decision would require covert motives is when there is an unresolved security hole.
The conversation you are trying to have is that technical trumps consensus. The conversation I am trying to have is that there is no technical claim here. There is no pressing technical reason why Commons should or shouldn't be set as read-only. As I see it, your refusal to offer a motive for refusing to remove read-only is effectively an acknowledgement that there is no pressing technical justification.
We both agree that there have been problems in the past, and that the best we can do is try to rebuild trust and collaboration today. However when today you try to assert a "technical trump card" that is either invalid or has the appearance of being invalid, you paint the WMF into a corner where we can't trust the WMF in the future. There is no technical claim to whether read-only should be active or not. Furthermore the covert discussions about uninstalling Flow were either covert because they were driven by non-technical motives, or they were pointlessly covert and it created an inescapable impression that they were driven by non-technical motives. In either case I believe it warrants revisiting that discussion in a more open manner. Alsee (talk) 22:47, 21 March 2018 (UTC)
Alsee, I don't think you understand me. What I'm saying is that the config change that you call "read-only" is a technical decision. It is a piece of code, a method of solving a problem. When I talked with Roan about how we handle removing Flow from Commons, the technical decision that he made was to use that piece of code. When you say that you want him to remove that piece of code, you are trying to interfere with a technical decision that is Roan's job, and not yours.
As for the secret discussions: when there is a community request that involves a technical change, the correct way to handle that is for me to talk to the team. We discuss possible methods of handling the situation, and if it's a difficult decision, we gather more information and look at pros and cons. This happens outside the view of the community because that's the way that people's jobs work. We have meetings and talk about things. That is not sinister, it is routine.
I think that your concern about covert discussions started because I went on vacation for a few days. Roan and I talked on Monday and decided what we would do, and then I went to Disneyland on Tuesday with my husband to celebrate his birthday. I was there until Thursday, and came back to work on Friday. I had decided to not post about the technical decision on Monday because I knew that there would be discussion about it, and I didn't want to disappear for three days in the middle of that. I waited until I got back on Friday to post about it.
Obviously, I know that I'm not going to convince you that Roan and my husband and Walt Disney and I are just going about our normal business, and not scheming against you or the Commons community. I'm just saying that's what happened. -- DannyH (WMF) (talk) 01:45, 22 March 2018 (UTC)
DannyH (WMF) it sounds a lot like you're saying that promoting one political party to the top of search results is a "technical decision" if the keywords are written in a config file. An effective way to wrap up the "technical" topic is if you can use the word in a sentence resembling "The technical reason Commons can't have the same config as other wikis is...". Is there any remotely credible claim that it would interfere with back-end operations? If you left your read-only code in place, but just didn't config Commons as read-only? You won't give any rationale at all.
You said I think that your concern about covert discussions started because I went on vacation for a few days. No, no no. That's a serious misunderstanding. The timeline begins Feb 6 when Mattflaschen effectively put a veto (-2 code review) on the Gerrit Patch. The comment was Under discussion by the team. Do not merge at this time.[4] Ok. Fine. Exactly one week later I posted a polite request on Phab: It's been a week since progress was halted without explanation. Could you or anyone explain the holdup?[5] And it was not just me. For weeks, several people were asking on Phab and on Gerrit. Even developers were given brick-wall non-responsive replies. You showed up at the THREE week mark. You stated that the WMF's non-communication was going to extend to the FOUR week mark. Aklapper then slapped me with a Phabricator code of conduct warning for unrealistic expectation that questions asked by individuals will have to receive a [quick] response.[6] Then, after four weeks of WMF-non-communication, you made the situation worse. You announced that the WMF was never going to engage in dialog. Any scraps of information you did offer were explicitly useless. After four weeks of the WMF being unwilling to talk, you declared that the WMF was now unwilling to listen. As much as you may believe that the WMF has improved, though this entire process the WMF has refused to engage in any dialog. Zero. Zero is not an improvement. You're here talking about the aftermath, but this discussion is hollow if you insist it will not have any effect. Alsee (talk) 22:46, 22 March 2018 (UTC)
Okay, I can go back to January, if it'll help. This is what I posted in early March: "re: the communication problem. I do apologize for taking so long to respond, it was rude on my part. The explanation (not a good excuse) is that there was a change in leadership in the Product team in late January, and then we jumped into annual planning and budgets, which took my eye off this response. But, yeah, that was rude of me, and not your problem. Sorry again."
If you want more details, I can supply them. I got the position as Director of Product for the Contributors team in mid-January. This position has a lot more responsibility -- instead of just leading the Community Tech team, I'm now responsible for six teams. So I spent a lot of January getting to know all the other teams, and finding out where there were problems that I could help fix. Also, for the last week of January, we had the annual All Hands meeting, which I was helping to run. Immediately after All Hands, we started working on the Foundation's annual plan, which is a lot of work, especially since I just started leading the team three weeks ago. It was a crazy busy time for me.
In early February, I had a discussion with the Collaboration team about this request to uninstall Flow from Commons. It was sensitive and complicated, so I wanted to be involved in the discussions, but we didn't totally agree at the end of the first conversation, and we set up more time to talk later. So I was the bottleneck in early February -- I just had too many things to take care of, and I needed to focus on the annual plan and the budget. I didn't get back to talk to the team about this for another couple weeks. So the team was waiting for me, and they probably didn't want to say "we're waiting for Danny, who keeps blowing us off," which was kind of them. I finally got back to the team at the end of February, and we figured out a response, and then there was the Disneyland trip for three days, so I saved the post for when I got back on March 3rd. I know that it was aggravating to wait for me all that time, and not know what was going on. I did apologize for it, and I apologize again, it was thoughtless of me.
You also say that through this process I've refused to engage in any dialogue, which I have to say, I kind of have engaged in that. That is the thing I've been engaged in since March 3rd. -- DannyH (WMF) (talk) 23:14, 22 March 2018 (UTC)
@Alsee: Leave it. They have as much as admitted, that Flow is so badly programmed, that it has to be deleted from all projects, where it's not in use, ro prevent it from wreaking havoc there like it did here. Because of this bad programming it can for now only be deactivated to keep the other software from being compromised. Danny apologised for a) being slow and b) not having a better solution, it won't come back here without a proper community consensus,, not even for testing. Yes, a proper uninstall would be the best and most acceptable solution, but as long as the devs are now admitting their bad programming and stop promoting this unretractable software anywhere else, it could be fine. If there is any new project compromised with Flow after now for testing purposes, the AGF-attitude will quickly evaporate, Flow is now officially not suitable for any new project, as it's not possible to get rid of it in a acceptable way after a decision against it.
@Danny: Will you make sure, that Flow will not get installed on any new project until it's really possible to revoke the installation in an acceptable manner (and no, this software switch is just a weak emergency solution, not something acceptable for the future). Grüße vom Sänger ♫ (talk) 05:43, 23 March 2018 (UTC)
DannyH (WMF) as I said, this discussion is hollow if you insist it will not have any effect. When I said dialog, I didn't mean irrelevant chit-chat.
Saying the task was "under discussion", then giving no response at all, created the impression that it was under discussion for a month. But let's say I and others are at fault for filling that vacuum with fears that this was a familiar pattern.
Whatever the reason for the delay, it could have been followed by dialog of the issues and options. But it wasn't. It was followed by an announcement that code had already been built. This created an impression that a "final" decision had been made internally. But let's say that impression was also wrong.
At that point, you declared the radical position the WMF was unwilling to even discuss even leaving Flow installed without read-only, much less any of the issues and options on uninstall itself. And you still won't offer any rationale for that radical stance.
The rationale for not uninstalling Flow appears to be full of holes, but how can we discuss that when you declare (with no basis whatsoever) that there can't even be dialog on even leaving Flow installed without read-only?
Please tell me, at what point was the WMF willing to engage in constructive dialog with the community to sort out what we (WMF&community) want to do? Alsee (talk) 06:45, 23 March 2018 (UTC)

I've just looked around the old discussions I was involved in about Flow, mostly on Lilas talk page in the good, structured layout, not Flow, and came about your name quite some time. I think this here sums up quite good what's to be said about Flow, and Flow hasn't changed so much since then, it's still just useful as a trollspace and for chitchat. What I came about as well was some stuff with the enWP, where you seem to have collaborated with Eric to get more Flow pages against the explicit wishes of the community working over there. That was after Erik declared his open all-out war against the communities with MV/SuperProtect, so everybody @WMF should have been very aware that further acting against the community will not be a good idea and not met with much enthusiasm, but there didn't seem to be any change in attitude at all. There was some delight once Lila declared that failed project as such, but it soon emerged, that it was still developed further, some newspeak renaming of Flow to StructuredDiscussions was done, and it was promoted again quite soon after everybody hoped for a learning curve within the WMF, but there was none. Grüße vom Sänger ♫ (talk) 22:14, 23 March 2018 (UTC)

Empower Bureaucrats to revoke Administrator and Bureaucrat bits

Bureaucrats should be empowered to revoke Administrator and Bureaucrat bits, as they may currently grant those bits per COM:CRAT. Currently, only Stewards may perform this function, and such actions and requests for them are only logged on Meta. See also this edit by Steward @Ajraddatz: .   — Jeff G. ツ please ping or talk to me 17:09, 17 March 2018 (UTC)

Could this be qualified more clearly? In theory, desysop or decrat only happens after a self-request, a formal community vote, after the account has been blocked due to violations per BP (though a desysop vote may still be needed if the circumstances remain controversial), or due to going past the agreed inactivity limits. Are there any more than these four scenarios that a Bureaucrat might remove these rights and stay within policy? --Fæ (talk) 18:05, 17 March 2018 (UTC)
@Fæ: There are also emergencies, such as rogue admins and hacked passwords. Allowing crats to perform this function as they close requests removes complexity and lessens workload for both crats and stewards.   — Jeff G. ツ please ping or talk to me 05:39, 19 March 2018 (UTC)
The role of Bureaucrats is not one that handles emergencies, either in theory or practice. Typically, requests at BN wait for days rather than minutes for a response. Both rogue use of sysop tools and suspected hacked accounts require solutions that get applied in the shortest time possible. --Fæ (talk) 20:00, 20 March 2018 (UTC)
I honestly find pinging a steward in case of an emergency quite easy; most likely easier than b'crats ;) --Zhuyifei1999 (talk) 19:49, 26 March 2018 (UTC)
 Oppose: 'Crat removing 'crat bits. My opinion is that there has to be a level of separation there for security purposes. I'm more meh on 'crat removing administrator bits provided they are doing so in a purely "paperwork" capacity, with notification (at COM:BN), and after ensuring it meets policy. That is how it is done on other projects and it seems to work fine. --Majora (talk) 18:11, 17 March 2018 (UTC)
 Oppose; no need, current system is working just fine. —MarcoAurelio 18:15, 17 March 2018 (UTC)
 Oppose Given the controversies involving bureaucrats in recent years, no thanks. --Rschen7754 18:25, 17 March 2018 (UTC)
 Oppose first of all I doubt the proposal here is intended to only apply on Commons. General discussion of the idea can happen anywhere, but an effective proposal would need to be handled at Meta. Secondly, the capability to remove a bit has much more serious security implications than the capability to add a bit. The very first action by a compromised or rogue account could be to revoke every other bureaucrat and admin. That would instantly kill off the entire population of defenders. In fact I would suggest serious software-enforced rate-limits on any account (even staff accounts) with the ability to remove high-ranking bits. The ability to add bits should also be rate-limited, so a horde of privileged sockpuppet/meatpuppet accounts can't be instantly raised. Is there any valid case where someone should to create or revoke a dozen bureaucrats on one day? Or create or revoke a hundred admins in one day? Security for that sort of mass-change should be rooted in tech staff who have a physical presence at the machines. Alsee (talk) 19:39, 20 March 2018 (UTC)

Proposal to import the English Wikipedia's version of the Module/Template for Reply

This would involve importing: 

{{{{{|safesubst:}}}#invoke:Reply to|replyto|<noinclude>example=Example</noinclude>|max=50}}<noinclude>
{{documentation}}
</noinclude>

The current template is limited to 5 recipients, does not display an error message when cutting off remaining recipients, does not support a chosen display name, and does not use a prefix. With this import, we would be able to: "reply to up to 50 people at once" (if 50 is too high, we could discuss another number) rather than just 5; ping a user & add her/his chosen display name, instead of her/his user name; and specify prefix (specified in the doc, but nonfuctional) parameter, like in en:Template:Reply to. Also, 5 is a low (and odd) number, and ideally there should be an error message displayed when you try to ping more than the supported number, too.

This proposal borrows heavily from Template talk:Reply to. I have brought it here to reach a larger audience. You may be more familiar with one of the following redirects: {{Re}}; {{Ping}}; {{Mention}}; {{RE}}; {{Rto}}; {{Reply}}; {{Replyto}}; {{Reply-to}}; or {{Antwort}}.   — Jeff G. ツ please ping or talk to me 03:53, 20 March 2018 (UTC)

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2018/03&oldid=298566687"