Commons:Village pump/Proposals: Difference between revisions

Content deleted Content added

Inline

Revision as of 02:12, 21 December 2017

Welcome to the Village pump proposals section

This page is used for proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Proposals/Archive/2024/06.

Please note

One of Wikimedia Commons’ basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing.
Have you read the FAQ?

Start a new discussion

	SpBot archives all sections tagged with {{Section resolved\|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.

Proposal to uninstall Flow

Flow is a WikimediaFoundation project intended to replace wikitext talk pages with more conventional forum-style discussion page. It is intended to be more inviting to people unfamiliar with wikitext, and intended to benefit experienced users as well. You can view and test Flow at Commons_talk:Flow/tests.

Many of Flow's intended benefits are quickly apparent. Flow has familiar forum style and features. There is a clear "reply" button, and messages are signed automatically. Other intended benefits of Flow have been well documented on the Flow page. However some technical aspects warrant more detail.

Technical limitations

In addition to providing software-structured discussions, Flow's input and storage mechanism are noteworthy. Flow's primary input method is VisualEditor. The VisualEditor engine is also used for all content rendering. In particular, audio and video files are not fully supported at this time. Audio and video files may not display at all, or they may appear as a generic icon. The WMF currently has a task open to improve media support. At the bottom right of the Flow edit window, a pencil icon may be used to switch to a mode where wikitext may be entered. In some cases Flow may render wikitext differently than expected. When saving wikitext, the VisualEditor engine is used to convert supported wikitext to VisualEditor's native content format (HTML+RDFa). The wikitext is then discarded. Flow does not include a separate preview function for wikitext. The VisualEditor mode is intended to serve as the "preview" for wikitext. When switching to VisualEditor to view a "preview", the VisualEditor engine converts the wikitext to HTML and discards the wikitext. When you return to the mode for editing wikitext, the VisualEditor engine is used to convert the HTML into new wikitext for editing. The newly generated wikitext usually resembles the wikitext you originally entered. However anomalies may appear, due to translation of wikitext->HTML->wikitext. In rare cases, reverting an edit may damage the original content. This is because the original wikitext was never saved, and the translation process may not correctly re-create the original version. The translation process also has the potential to generate "tumors", chunks of corrupt wikitext that expand each time you preview or save.

Examples: How Flow handles wikitext

'''Wiki''media'''foundation''

On preview or save, Flow will re-write it in a way that renders the same:

'''Wiki''media'''''<nowiki/>''foundation''

Another example:

{{#if:flag|<span style="color:red;|<span style="}} font-weight: bold">text</span>

On preview or save, Flow will destroy what you wrote:

{{#if:flag|<span style="}} font-weight: bold">text

Current deployment of Flow

The WMF has repeatedly given firm assurance that there are currently no plans to deploy Flow without a local consensus to do so.

Flow is currently available as an opt-in preference on several wikis. This activates Flow as a replacement for an individual's User_Talk page. Most of these are small wikis, activated with consensus as small as 2 or 3 people.

At least one microwiki was fully converted to Flow, based on a consensus of 3.

English Wikipedia: Activity died on all Flow pages, they were deleted and the entire Flow extension was uninstalled by community request. (An RFC was drafted, but the WMF agreed the outcome was obvious and Flow was amicably uninstalled.[1])

Meta Wiki: ~~One Flow page was~~ Two Flow pages were shut down and the extension was uninstalled by an RFC consensus of 26-4.[2]

German Wikipedia: Some individuals are currently discussing running an RFC to uninstall.

Current state of Flow on Commons

Flow is currently installed, and active on two pages: Commons_talk:Flow and Commons_talk:Flow/tests.

An April 2017 RFC to Enable beta function of Flow on own talk page ended Opposed 11-2.

General level of support for Flow

In September 2016, the Wikimedia Foundation ran a Flow Satisfaction survey. A small number of public invitations to the survey were posted, and targeted invitations were sent to almost everyone who had actively opted-in to Flow for their user_talk page. Concerns were raised that this may have severely canvassed participation, however those who ran the survey "insist [] we don’t think this is a canvassed or biased survey" and "It was still open to anyone who wanted to participate".[3]

Amongst the various questions about Flow, the survey found 38% of participants prefer Flow over wikitext talk pages. People are encouraged to follow the survey link above, and read the highly positive (glowing) summary of other survey results. The survey report then recommended that the WMF resume Flow development work and pursue expanded deployment. Resumption of Flow development was then added to WMF quarterly schedules.

Proposal

Uninstall Flow, as was done on English Wikipedia and Meta wiki. Alsee (talk) 22:24, 11 September 2017 (UTC)[reply]

Responses

Support for two reasons:
1. Standard Industry Best Practices say that one of the most important ways to improve the security and stability of a system is to uninstall unused software. This is especially true when that software is undergoing active development. Flow is an unusually complex and invasive extension, hooking into many parts of the wiki. The WMF has drafted extremely vast plans for Flow development that would be extremely invasive into all parts of the system. There is absolutely no reason Commons wiki should risk disruption due to inevitable bugs in an extension that it's not using.
2. If a series of major wikis uninstall Flow, pretty soon the the WMF will be forced to face reality. We are NOT eagerly waiting for Flow to be upgraded and deployed. We really truly want Flow gone. The 38% support in the survey was a Votestacking fabrication, and the glowing Survey Report was somewhere between wishful-self-delusion and propaganda. Alsee (talk) 22:24, 11 September 2017 (UTC)[reply]
@Alsee: There are a lot of allegations without evidence here... Yann (talk) 15:07, 12 September 2017 (UTC)[reply]
Yann, I'm not going to guess what you mean and waste my time digging up cites for random sentences we both agree don't need cites. Would you like to identify your top two concerns? Alsee (talk) 16:02, 12 September 2017 (UTC)[reply]
@Alsee: You can't put up wild allegations without giving evidence. Sorry, but it is to you to back up what you say. Regards, Yann (talk) 16:12, 12 September 2017 (UTC)[reply]
Yann, I am not going to guess what you mean. Would you like to identify your top two concerns? Alsee (talk) 19:25, 12 September 2017 (UTC)[reply]
@Alsee: Copying and pasting the same sentence again doesn't give any more evidence to your allegations... At this point, it is quite clear you have some agenda here... Yann (talk) 20:36, 12 September 2017 (UTC)[reply]
Strong support At the very heart of this wiki lies the presumption that any edit can be reverted perfectly. Flow does not allow that. For that reason and all the others above, it should be uninstalled posthaste. — Jeff G. ツ 00:36, 12 September 2017 (UTC)[reply]
Support uninstalling. I only had to spend one minute to look. I failed to immediately find out how to edit comments made by others. It is also so invasive I didn't understand immediately if wiki markup is understood at all, or how I would format my posts to be semantic and accessible to any reader.
Speaking of accessibility, it's still in baby shoes: <article> elements are not used for comments, but instead a <div> soup. I understand it's a work-in-progress, but still. 2001:2003:54FA:2751:0:0:0:1 01:19, 12 September 2017 (UTC)[reply]
Oppose Flow brings several advantages on talk pages: no need to sign, no need to follow the whole page to get a notification about an answer, etc. These are mostly useful for newbies. Flow should be used on pages where it would be useful (Help desk, COM:UDR, etc.), where most people asking questions do not sign, and do not see the answers because they do not watch the page. Regards, Yann (talk) 10:22, 12 September 2017 (UTC)[reply]
Support uninstalling. My experience using Flow on wikis where I am forced to hasn't been positive. —Marco Aurelio 10:24, 12 September 2017 (UTC)[reply]
Support Correct rendering of pages, including images and video files, are critical for sensible discussion about Commons content on Commons. If newbies don't want to sign their posts, then for goodness sake, someone write a bot script to do it for them. As for expecting long term contributors to this project to switch to using the Visual Editor, forget it. It's been many many years of pointless discussion, and too many years of the WMF blatantly ignoring valid complaints about the different ways in which it failed to work, to expect us to invest our unpaid volunteer time to just get bitten yet again. --Fæ (talk) 10:41, 12 September 2017 (UTC)[reply]
Support --Krd 10:42, 12 September 2017 (UTC)[reply]
Support --Steinsplitter (talk) 11:15, 12 September 2017 (UTC)[reply]
Support per MarcoAurelio & ~~Yann~~Fae. Storkk (talk) 13:05, 12 September 2017 (UTC)[reply]
- @Storkk: If you agree with me, you should oppose this proposal... Regards, Yann (talk) 15:04, 12 September 2017 (UTC)[reply]
  - Sorry for the confusion. Typo/braino after reading the substantive responses. Storkk (talk) 16:20, 12 September 2017 (UTC)[reply]
Oppose I agree with Yann. Flow might not be all the way there but it does have many advantages over traditional talk pages. I would give it a chance and not pull the plug yet. --Jarekt (talk) 13:07, 12 September 2017 (UTC)[reply]
It will brake our talk page notification tools, etc. And handling spam via Flow is a mess, imho. --Steinsplitter (talk) 16:05, 12 September 2017 (UTC)[reply]
@Steinsplitter: Which notification tools are you talking about? Flow completely changes the way notifications are handled, so you can't compare it with the current system. And IMO using {{Ping}} and other templates is a poor hack. Regards, Yann (talk) 16:21, 12 September 2017 (UTC)[reply]
Abstain as long as I don't have to use it. It's disgusting to use it on Wikidata user talk pages, works for simple text and is awful for templates and links, costs perhaps twice the time to input those if they are rendered correctly at all, those using <code> or <syntaxhighlight> don't it seems and needs workarounds not to introduce wrong <nowiki /> tags. --Marsupium (talk) 17:42, 12 September 2017 (UTC)[reply]
Oppose Per discussion below. Proposal seems politically motivated with no strong argument presented to uninstall (vs choosing not to use). Perhaps Flow is unfinished, buggy and may even be the wrong approach for Commons editing participation, but it can be ignored, just as parts of Commons can be ignored. The wikitext interface is a poor one that attracts a narrow subset of the population (typically male, typically nerdy) and is a barrier to many creatives who would otherwise participate here. That might not bother those who are happy to hoover up images from elsewhere, but it bothers me, who wishes we had more photographers (and other artists) contributing directly to Commons. The solution might not be Flow, but it certainly isn't wikitext. -- Colin (talk) 07:52, 13 September 2017 (UTC)[reply]
~~Neutral~~ I tend to oppose mainly as per Colin, however the issue is that even when you don't active it yourself, if a user active it on his talk page, then you have not other choice that to use it. Also the option "source editing" in Flow should at least propose the same taskbar / menu bar (specially with the edittools). And how will this work with our notification system (block, copyvio, nomination for deletion coming from VFC)? the fact that it is a choice "only wikitext" or "only Flow" worried me a bit. I just try to nominate the page for deletion, as a test, and that don't work, therefore likely the VFC notifications will not work too in a "Flow user talk page", hassle to notify the users. Therefore I tend also to support. Christian Ferrer ^(talk) 11:44, 13 September 2017 (UTC)[reply]
- Oppose Keep it as a test, develop the test to highlight the potential problems with Commons. No to an implementation as long as there is no solutions for potential issues. But I even more opposed to a test end just "for the principle". Christian Ferrer ^(talk) 18:08, 13 September 2017 (UTC)[reply]
Support, obviously. -- Tuválkin ✉ ✇ 22:05, 13 September 2017 (UTC)[reply]
Support If there's no consensus to even leave it as a beta feature, then no point in leaving it installed. --Rs chen 7754 00:35, 14 September 2017 (UTC)[reply]
Oppose -- 12:07, 14 September 2017 (UTC) — Preceding unsigned comment added by MichaelSchoenitzer (talk • contribs)
Support Not needed here. --Gestumblindi (talk) 20:21, 15 September 2017 (UTC)[reply]
Support Unused. Should the community change their mind in the future, another proposal can always be made. Train2104 (talk) 16:20, 17 September 2017 (UTC)[reply]
Oppose per Colin and Yann. It may not be a finished product, but removing it simply becuse it is not ready for prime time and only used for testing here, is not any way to imporove anything.It seem as development has started up again, so let's keep it for testing - so Commons does not get forgotten and left behind when other wikis adopt and fit Flow for their needs. --Jonatan Svensson Glad (talk) 04:51, 20 September 2017 (UTC)[reply]
Support complete uninstallation. It is our goal as Wikimedia Commons to help users have a friendlier software. It is logical therefore to remove some cruft, such as the "Topic" namespace which is currently displayed in various places for no gain, and any other facility added by this unused extension for which there is no foreseeable use on this wiki. Nemo 10:57, 29 September 2017 (UTC)[reply]
Oppose I fail to see the issue right now. I will never support Flow in its current form but I don't see the issue with having these test pages and attempting to develop it if that is Wikimedia's goal. EoRdE6^{(Come Talk to Me!)} 21:26, 1 October 2017 (UTC)[reply]
Support There is no point in it existing on Commnons at this point, even on two pages, when there is no plan to roll it out wider. If there are plans to resolve the issues with Flow and bring it back, then do the work on one of Wiki's incubators. Wikimandia (talk) 20:27, 17 October 2017 (UTC)[reply]
Support - I supported it being uninstalled on EN and am supporting here too - To put it in very blunt terms Flow is horrendous and IMHO should be uninstalled on every project ... anyway in short as the saying goes "if it ain't broke don't fix it". –Davey2010^Talk 15:27, 1 November 2017 (UTC)[reply]
Support but only per the previous RfC. Flow should be reinstalled if/when the concerns mentioned in the previous RfC are addressed. Jc86035 (talk) 10:30, 25 November 2017 (UTC)[reply]
Support Flow isn't a wiki-model type thing; it's more like Facebook posting, and as well as images, it doesn't accept things like templates (how would you leave a block template, for example), and posts can't be edited in the normal way. Little side things, like the Notifications system, are okay, but we shouldn't be using non-wiki-model type things in major areas such as discussion pages. Nyttend (talk) 13:01, 4 December 2017 (UTC)[reply]
Oppose Slowking4 § Sander.v.Ginkel's revenge 19:22, 11 December 2017 (UTC)[reply]

Slowking4 - Any particular reason why you oppose ?..... –Davey2010^Talk 19:56, 11 December 2017 (UTC)[reply]

per Colin and Yann. i do not see any reason to relitigate the drama of other projects. you are in effect grave dancing over Jorm's work. failed attempts to improve talk are still useful as scaffolding for the eventual replacement. the fact that i conduct most communication off wiki and ignore all templates is no reason to uninstall all talk pages, or templates, or notifications. Slowking4 § Sander.v.Ginkel's revenge 04:48, 12 December 2017 (UTC)[reply]

Discussion

Question What's the actual status of Flow right now? Shortly after it was announced as a beta feature in 2015, it was put in "bugfixes only" mode (see the statements by User:Quiddity_(WMF) in Topic:So4juczs8f56jvp5). There were talks about moving on to something called "Workflows" instead but it seems that never took off? mw:Flow#Development_status is pretty vague, but there seems to be some movement over at Phabricator (phab:T167928)? As it is, Flow might be useful for some smaller wikis, but it's currently not in a state where it really could be used broadly on a project like Commons. Might be useful for a few select pages, though. --El Grafo (talk) 13:13, 12 September 2017 (UTC)[reply]
If it were uninstalled today from Commons, there's nothing to stop it continuing to be played around with on the beta cluster. If folks are going to keep using main projects like Commons as a test site, especially for "tests" which carry on for more than 2 years, then I don't see the point of having a beta cluster. --Fæ (talk) 13:39, 12 September 2017 (UTC)[reply]
El Grafo, like you have seen on phab:T167928, the development has restarted. No announcement has been done so far because the developers needed to decide on a few things and update some pages to provide the best information to communities. In a nutshell, the improvements listed (wikitext storage of messages, search on a page, or move messages) narrow Flow's scope to user-to-user discussions. Those improvements will be deployed on all existing Structured Discussions pages. Some wikis, including Wikidata, French Wikipedia or Chinese Wikipedia, have chosen to use Structured Discussions on user talk pages (Beta feature) or Help desks. Trizek (WMF) (talk) 14:08, 12 September 2017 (UTC)[reply]
Comment I cannot help but notice that Alsee has 118 edits on Commons, of which only a minority is content. What motivates such a drastic proposal from someone with so little stakes in Commons? Rama (talk) 17:04, 12 September 2017 (UTC)[reply]
Hi Rama. I acknowledge my work on this wiki has been very modest. However I am a well established member of the broader community (mainly EnWiki), and I expect I will be returning here for years to come. I also don't think the proposal is "drastic". It would remove two unproductive pages, and the WMF has already worked out a reasonably easy uninstall procedure. As for my motivation: Wiki-community service. (Based on responses so far, it appears most people agree that posting this proposal was a positive service.) In particular, I am very concerned that WMF engagement with the community is too often painfully-poor. I have taken a special interest in bringing EnWiki community-consensus concerns to the WMF, and keeping the EnWiki community informed of significant new developments by the WMF. It is often painfully difficult getting the WMF to listen to EnWiki, and I've seen how hard it is for other wikis to have any effective voice with the WMF. Other wikis get screwed over. In some cases EnWiki can push to get a problem fixed, and the WMF only fixes it for EnWiki. For example the WMF has begun stealth-deployment of VE as the default editor for new users at all wikis. I caught the issue and EnWiki got it fixed - for EnWiki. The WMF plans to silently do the same at every wiki, unless there is a local consensus to define the wiki as "wikitext primary". The WMF isn't telling wikis that choice exists, they're just going to push out what they want unless someone opens a local discussion on it. The WMF has also decided to phase-out our wikitext editor. They're building a wikitext mode inside VisualEditor as a replacement. It has atrocious performance and faulty previews. EnWiki established overwhelming consensus against it. The WMF is moving forwards with the project, planning to eventually deploy it here and everywhere else. We need more cross-wiki community collaboration to give the community more voice with the WMF. We need more cross-wiki communication, to establish multi-wiki consensus on shared interests. I saw Common's overwhelming rejection of Flow in the last RFC, and I decided to take a step towards establishing a stronger multi-wiki consensus on Flow.

If you like Flow, I hope you will at least respect that I am acting in Good-Faith service of community consensus here (presuming that this proposal continues to get solid support). Alsee (talk) 19:19, 12 September 2017 (UTC)[reply]
Your argument is more about your distrust and dislike of the WMF than about the uninstall of Flow. In fact, I fail to see any argument at all supporting your case in your very own argumentation: your not using Flow is one thing, uninstalling it from projects is quite another. I do not use the Upload Wizard, but you do not see me advocating its removal. Rama (talk) 19:44, 12 September 2017 (UTC)[reply]
Yes, it is quite clear Alsee is not here to improve Commons, but just using this project as a playground for politics... Yann (talk) 20:39, 12 September 2017 (UTC)[reply]

Rama, I gave two clear reasons for uninstall in my !vote. (1) There is no reason the wiki should be affected by development-bugs in an unused extension. If you are going to claim I made no argument at all supporting uninstall, then I'm not sure what productive discussion we can have. And (2) I think there needs to be a reality-check on the future of Flow. If Flow has a long term future, then we should embrace and improve Flow. If Flow is a dead-end, those limited resources may be better allocated elsewhere. Alsee (talk) 22:48, 12 September 2017 (UTC)[reply]
(1) is not an argument for uninstalling Flow, just a statement that Flow is not widely used. "Flow has bugs that open security holes to the rest of the software", for instance, would be an argument for uninstalling (I insist that it is just an example, not an argument that anybody has actually raised). "Flow has bugs, I don't like it an neither do my pals" is an argument for you not using it, for which, well, congratulation (on the day you start contributing extensively to this wiki, I mean).

(2) is not even remotely an argument for uninstalling Flow, it is a judgement of value. That "there needs to be a reality-check on the future" is a vague, unactionable opinion, and a very fine one, that I would support; but it does not entail that an immediate uninstall of Flow is in order. I would support reality-checking lots of things that I would also find unwise to disrupt. Rama (talk) 06:37, 13 September 2017 (UTC)[reply]

Alsee, please stop saying that "The WMF has also decided to phase-out our wikitext editor". This is not true. We've talked before about this, and you know that this is not true. The Foundation's plan for the 2010 wikitext editor continues to be full, normal support for the foreseeable future. Please do not mislead fellow volunteers by saying otherwise to them.

For the rest of you, I apologize for this confusion. I am the product manager for Structured Discussions (Flow) now, so the responsibility for this decision lies with me. I have decided not to de-install this software from this or any other wiki without a solid technical reason for doing so. Custom configurations for each wiki slightly slow down the sites for every reader and editor, and complicates Ops' work, which, unlike the assertions above, actually is a security risk.

If anyone wants to object to the existence of this tool, as used by several communities, then I encourage them to engage in that discussion at the right time and place – which is in the annual plan, not the village pumps for individual wikis. I see the annual plan very much as our "contract with the communities" – we say we will do things, and our communities should expect that we keep to our commitments in that plan. You will find community-requested improvements to this software listed as a priority for this year under Program 5, Goal 3. The talk pages about the annual plan, widely advertised through banners during the process, were the correct places to suggest changes to the Foundation's planned work. Jdforrester (WMF) (talk) 18:13, 13 September 2017 (UTC)[reply]
Jdforrester, you do not get to personally dictate to this community how we run our votes or discussions, and I doubt that anyone wants to be forced to check-in with you every time we have a meaningful vote or discussion. If you have suggestions or advice, that's super, but you are not the boss of me or any other unpaid volunteer contributor. If you want input in the "right" places, then please feel empowered to take our locally established community consensus and put it in those places yourself. Thanks --Fæ (talk) 19:18, 13 September 2017 (UTC)[reply]

Hi Jdforrester (WMF), it's a surprise to hear from you on this subject, given that you have been non responsive for six months[4] on whether you intend to be collaborative or combative regarding the consensus on the new wikitextmode-in-VE editor. For those unfamiliar, there was an overwhelming EnWiki consensus[5] objecting to performance and preview issues with the "NewWikitextEditor". (The last time I tried to use it, clicking preview took over 60 seconds to load, and the rendering was faulty.) As for the "confusion", the plan is for wikitextmode-in-VE to become the default wikitext editor, and for the current wikitext editor to move to opt-in for some unspecified period of time. The WMF's roadmap states: Finally with regards to core work, our intent right from the beginning of our work on the visual editor has been to operate as the core 'platform' for all kinds of editing in MediaWiki, and not just to be another single editor. Depending on how you count them, there are currently six pieces of editor software beyond the visual editor installed on most of our wikis, which gives us six different interfaces by which to confuse users, six different sets of bugs to track down, and six different places where features can interact in unexpected ways and which need to be tested. Our goal is to gradually reduce the number of pieces of software with equivalents based on the single platform.[6] Who wrote that? You did.[7] Maybe I am confused. I don't see how increasing the number of editors will "reduce the number of pieces of software with equivalents" unless you explicitly plan to remove the current wikitext editor. I think most people would consider it a "phase out" to temporarily move the current editor to opt-in, then remove it. Alsee (talk) 19:25, 13 September 2017 (UTC)[reply]
There are a couple of things I like about FLOW but they do not surpass the things I dislike. For example "history" does not work so I cannot see what has changed from when I last looked. Also I am very concerned with us going from two ways to edit Wikipedia to three ways to edit Wikipedia (VE and the old editor to VE, the old editor, and FLOW). Additionally I like new comments at the bottom rather than the top and I hate the fact that discussions jump around within a page (BTW I hate Facebook which also has many of these features). IMO FLOW is in a early stage of development. Doc James (talk · contribs · email) 21:18, 13 September 2017 (UTC)[reply]
- With respect to new posts occuring at the top rather than the bottom, it is not that much of an issue with the current system. Not sure if I want "infinite scroll". Doc James (talk · contribs · email) 23:24, 13 September 2017 (UTC)[reply]
  Doc James, what is your view on removing Flow from communities that don't want it? I am rather concerned that the WMF appears to have reversed position on this. Alsee (talk) 03:44, 14 September 2017 (UTC)[reply]
  If as they say it makes the tech work easier and improves performance I am okay with seeing it stay installed. If the community has agreed something is not to be used than one would expect to see blocks handed out by the community for members who breach that agreement. It would be the use of the tool that the majority oppose that is the real issue rather than the existence of the tool. From what I understand some of the small wikis like FLOW and if consensus exists to use it there than okay. Doc James (talk · contribs · email) 14:20, 14 September 2017 (UTC)[reply]
  Doc James, I seriously question how having Commons configured the same as the Flagship-EnWiki and Meta could make tech work more difficult or diminish performance. It appears to be an implausible claim.
  
  On the other hand almost any programmer can confirm industry EN:Best_coding_practices#Deployment #1 Don't install something you're not going to use and #2 uninstall things you aren't using. Bugs are inevitable, especially when software is under active development. Keeping the EN:attack surface as small as possible is a basic security measure, and generic bugs can't affect a system if they aren't installed.
  
  Is more bad-blood between the WMF&community truly being outweighed here due to priority technical reasons? Or is this about digging in on an agenda to eventually convert Commons and other wikis to Flow? Alsee (talk) 10:22, 15 September 2017 (UTC)[reply]
  Hum, as a non tech person I do not know. I think we can all agree that our talk page systems could use improvement. VE was acceptable and in fact supported as it was and is only optional. Those of us who do not like it are not required to give up their prefered method of editing. This is the fundamental problem FLOW faces in that it has difficulty being introduced gradually.
  
  I am on the other hand happy to see software developed for projects other than EN WP. However I would still like to see significant efforts put into improving the current talk page system. Maybe we need a version of VE that works on talk pages? Regardless we need more community input / involvement in software development. We are NOT like facebook users (these being who FB sells to advertisers) and thus we cannot use software development techniques that FB uses for its users. Doc James (talk · contribs · email) 12:53, 15 September 2017 (UTC)[reply]

Regarding not being a tech person - there's an entire tech staff that can offer advice on the difficulty and impact of uninstalling Flow. As for improving talk pages, that would obviously be popular. But it's hard to get any progress on talk pages when that department seems to view talk pages as a competitor to Flow. I wholeheartedly agree on more community input on development - most importantly before coding starts. The cheapest and most pain-free time to identify and resolve issues is during the concept&planning stage. The NewEditor project was effectively built in secret. Once the prototype was complete is was too late. The WMF has been completely unwilling to discuss changing the design. For the last year I have been unable to get any meaningful response on how the WMF plans to deal with community concerns. I fear the NewEditor project may be driving towards a crisis. Could you inquire whether they plan to force it out as default, if the community considers it a downgrade? Alsee (talk) 05:09, 16 September 2017 (UTC)[reply]

That's a good point by Doc James: "VE was acceptable and in fact supported as it was and is only optional. Those of us who do not like it are not required to give up their prefered method of editing. This is the fundamental problem FLOW faces in that it has difficulty being introduced gradually." In German-language Wikipedia, the community decided in early 2016 to adopt VE as an option for not logged-in and new users. Per default, there are now two edit tabs in German-language WP: "Bearbeiten" (which is using VE) and "Quelltext bearbeiten" ("edit source", using the classic wikitext editor). Logged in users are still able to completely disable VE individually, if they wish to do so. Only through the optional nature and full mutual compatibility (you can always edit the same page in VE or wikitext and switch freely between these modes) VE finally was considered acceptable by the community, I think. As Flow, on the other hand, is not an optional mode for editing discussion pages but something radically different and incompatible with the existing "flow" of editing discussion pages, it's no wonder that the opposition is very strong. Gestumblindi (talk) 18:49, 17 September 2017 (UTC)[reply]

REQUEST FOR CLOSURE. This has been open almost two months, and there has only been one new !vote recently. Alsee (talk) 09:46, 6 November 2017 (UTC) Alsee (talk) 14:39, 2 December 2017 (UTC)[reply]

Seconded. — Jeff G. ツ 19:48, 2 December 2017 (UTC)[reply]

Proposal to include non-CC0 licenses for the Data namespace

Tracked in Phabricator
Task T154071

This proposal is to allow additional licenses to the Commons Data namespace beyond CC0.

Context

Not all licenses allowed under Commons:Licensing are relevant to data sets, this proposal is to allow all those considered relevant to tabulated data and maps, including the display of OTRS tickets to validate specific release statements.

Recent cases of non-CC0 maps in the Data namespace hosted on Commons rely on data exported from Open Street Map (OSM) ({{ODbL}}) and others may rely on map data originally taken from Government released open data, with attribution requirements such as {{OGL}} or Public Domain but not CC0. In some cases map data created on OSM (ODbL) has been released by the same person on Wikimedia Commons as CC0, which would require a release unless the account is verifiably linked with the creating account on OSM.

References

Launch notice on the Village Pump, November 2016.
Proposal for tabular data, April 2016.
Allow structured datasets on a central repository (CSV, TSV, JSON, GeoJSON, XML, ...) - main Phabricator ticket.
Add a data-page-only wiki markup header to datasets - ticket to make Data pages compatible with conventional Commons methods, like categorization and license templates.
Policies for map geo-data stored in the Data: namespace related Village Pump discussion supporting the idea of changing licensing policy for Data namespace.

--Fæ (talk) 12:08, 18 October 2017 (UTC)[reply]

Votes

Support as proposer. --Fæ (talk) 12:08, 18 October 2017 (UTC)[reply]
Support For most regions OpenStreetMap is the most comprehensive map of the world available today. There are hundreds, if not thousands of articles for Wikimedia projects, which would greatly benefit from dynamic maps based on OSM, that could be hosted on Commons. Thus the acceptance of ODbL/OGL licenses would be a great step in the right direction!--Renek78 (talk) 13:48, 18 October 2017 (UTC)[reply]
Support, per previous discussions (referenced below)--Ymblanter (talk) 18:13, 18 October 2017 (UTC)[reply]
Support Indeed more public databases are published under regular Creative Common licenses like the datasets of the Archaeological Survey of Ireland or the National Inventory of Architectural Heritage which were published under {{Cc-by-4.0}}. These datasets include coordinates of archaeological sites and monuments which could be used for maps showing the geographical distribution of such objects. --AFBorchert (talk) 19:04, 18 October 2017 (UTC)[reply]
Support - Offnfopt^(talk) 19:20, 18 October 2017 (UTC)[reply]
Support --Alexander (talk) 20:04, 18 October 2017 (UTC)[reply]
Support with the understanding that any implementation of this proposal includes the necessary support for tracking and propagating the license metadata needed to comply with licenses that have attribution requirements, license link requirements, etc. —RP88 (talk) 00:00, 19 October 2017 (UTC)[reply]
Phab:T155290 is worth watching to see how implementation progresses. This proposal makes the requirement clearer, and I would hope that the implementation means that current automated tools will be able to work in the Data namespace, such as the ability to add any notice. --Fæ (talk) 08:00, 19 October 2017 (UTC)[reply]
Comment This proposal is not sufficiently clear in scope or explanation and I suggest we stop voting and have a discussion instead. -- Colin (talk) 07:19, 19 October 2017 (UTC)[reply]
Support with the comment that having any namespace that is restricted to one license and impervious to tags, categorization, and even wikilinks is a foolish idea. — Jeff G. ツ 13:45, 19 October 2017 (UTC)[reply]
Support Per previous discussions. Thank you Fæ for proposing. Wikimandia (talk) 22:14, 19 October 2017 (UTC)[reply]
Support In my experience, most data relevant for maps below the province/state level is not in the public domain or compatible with CC0. It’s either in OpenStreetMap or open source data provided by governments though Open Government Licenses (e.g., data from the Canadian, NZ, UK and French governments). If the Data namespace is going to maximize its usefulness, I think allowing additional licenses is essential. -Shaundd (talk) 19:50, 30 October 2017 (UTC)[reply]
Info Any RFC result here appears to be moot. The legal response posted below appears to say we can't put anything except CC0 there, and that the WMF currently has no plans to allow us to put anything except CC0 there. I will quote what I believe to be the critical portions: Will the tabular and map data features support non-CC0 datasets? Currently, the tabular and map data features require a license field, that supports SPDX codes to identify the dataset's license. The feature currently supports CC0. In the future, it may support additional Free Licenses, including CC BY-SA or ODbL. Before additional licenses can be allowed, the Wikimedia projects should (1) support attribution and other obligations contained in the license (such as when displayed in the Graph extension and other consumers of tabular and map data), and (2) provide users with appropriate community guidelines on what material and license is acceptable. This support may require additional feature development that is not currently planned, but open for future open source contributions. Alsee (talk) 23:41, 8 November 2017 (UTC)[reply]
Support for both tabular data and maps. Thank you Fæ for starting the discussion. The current licensing requirements unnecessarely limits OSM imports and data from public data repositories, which normally require attribution. While in Wikidata having different licenses for different properties would be a nightmare, having isolated data tables under a free, but non-CC0 license would help bridge the gap. As to the maps, OSM data is preferable to other sources because it matches the current maps the WMF provides. As to the issues that Alsee mentioned, we missed the train on this year's community wishlist, but there is always 2018. Also, AFAIK ODbL data (one of the major usecases here) could be accomodated without further changes to the code, since OSM is already credited in the Kartographer maps, so we could start with that.--Strainu (talk) 23:05, 3 December 2017 (UTC)[reply]
Support --Donald Trung (Talk 💬) ("The Chinese Coin Troll" 👿) (Articles 📚) 10:08, 8 December 2017 (UTC)[reply]

Discussion

There has been much related discussion to this proposal at Commons:Deletion requests/Data talk:Kuala Lumpur Districts.map, at Wikivoyage Traveller's pub and a maintenance category has been created at Category:Data files with Open Street Map coordinates. Short neutral notes have been added to the Traveller's pub and the Village pump to link to this proposal in order to avoid on-going duplication of any discussion. --Fæ (talk) 12:43, 18 October 2017 (UTC)[reply]

Why oh why does Commons always vote prematurely on these things. What is this proposal asking? That we accept any licence "considered relevant to tabulated data and maps". Well GFDL is not in anyway relevant to photographic images (it is designed for electronic computer manuals) yet it is near impossible to get Commons to agree to suspend its future usage for photos because a very very few photographers deliberately use it to prevent their works being re-used outside of Wikipedia. So what the community "considers relevant" appears to be "anything that means we can host it here". This is a major shift from accepting data that is totally without strings (PD or explicitly placed into PD by use of the CC0 declaration) to data that most certainly has strings that have legal backing. It is a shift from work free of any copyright restrictions whatsoever (and thus free of any concern about actually being complex/human/intelligent/etc enough to be copyrightable in the first place) to work that is still under copyright that still has a copyright owner and that is merely licensed with certain conditions. As seen in some linked discussions, it also brings with it the headache of knowing whether taking a small part of that data constitutes a work that is derivative or is just a piece of free non-copyrighted data.

The "BY" part requires us to maintain attribution of the data and any derivative works. While that is feasible for a photo with a description page with plenty room for attribution statements, and photos generally do not get mixed with other photos on any regular basis, it is the mixing of data that is so likely and attractive and easy. The "SA" part requires us to enforce that all derivative works on Commons use the same licence. This is infective. And historically some licences have not mixed well with other licences. So one cannot take e.g. a GFDL image and mix it with a ArtLibre image and produce a CC BY-SA 2.0 montage. Some of the more recent licences are compatible but this requires a level of licence Guru that is beyond most people. Do we really want the headache that is SA to infect our data? Perhaps. But like to know how either of these aspects are going to work before voting. Can someone take open streetmap data and product a CC BY-SA 4.0 image, for example? Or does the resultant image have some bastard licence nobody can put a name on? Just like our normal licence scope is founded on Definition of Free Cultural Works, we need a proposal for data that establishes some fundamentals of any licence that could be acceptable. And I'd suggest we learn from past mistakes and not permit an open field for anyone to invent any home-made licence that looks freeish, but specifically agree as a community which licences we accept. Then we can ensure those licensed works have the infrastructure and documentation here for users to work with them.

Btw, the linked deletion discussion is a classic of Commons voting with their hearts to desperately keep works here, rather than with their heads accepting that honestly the material had been wrongly declared CC0 and should not (currently) be hosted here. We should bear that in mind, that we tend to be foolishly desperate when it comes to wanting to host/keep material and not always accept the legal issues that others point out. I'm not against the idea of accepting some other licences, but it seems to me that is going to require more work to prepare for and consider. -- Colin (talk) 07:19, 19 October 2017 (UTC)[reply]

Looking at the VP discussion, I see User:RP88 rightly raises the issue of compatibility when mixing data by says "Commons has long had to deal with this issue with regards to collages. Adoption of multi-licensing was used to ease some of these license compatibly issues". This isn't a great comparison. Collages are rare, so by and large, most Commons users will not deal with the headache of mixing licences. And if the source images are on Commons or online, then it is easy to link to them so any re-user can be clearly aware of which parts were taken from which source, and identify the attribution clearly also. But multi-licensing does not solve compatibility issues. For starters, it requires the original author to have the forethought to release their work under a variety of licenses. GFDL, CC BY-SA, ArtLibre, etc, etc. Then the person creating the collage has to pic the intersection of licences of their source material. That might mean they are left with just CC BY-SA. So whenever multi-licensed works are combined, and those licences aren't "compatible" you are left with a more restricted licence set. And if those licences aren't compatible to begin with, you actually can't mix them at all. It appears that ODC Open Database License is compatible with Open Government Licence and with Creative Commons Attribution 4.0. This means they can be mixed and you can use either one of these for the result. But while CC BY 4.0 is compatible, is CC BY-SA 4.0 compatible? And what about others? I would strongly suggest we only accept compatible licences, making the concerns of mixing data easier. -- Colin (talk) 07:58, 19 October 2017 (UTC)[reply]

See CC Compatible licences and this chart. It seems that while the three data licences above are compatible and interchangeable, none of them have an SA component. Mixing them with an SA licence like CC BY-SA means the new work must also be SA and thus can only be a compatible SA licence. Similarly, if one mixes non-SA works but chooses to release the derivative work under an SA licence, then that means all future derivative works must also be SA. So while CC BY-SA 4.0 is compatible with ArtLibre aka Free Art License 1.3, you can't take one of these and produce a CC BY 4.0 or an Open Database Licence work. The licences can only get more restrictive as you combine. Are there any SA data licences that are compatible with CC BY-SA? If not, then that's a very good reason to discourage SA completely, and stick with the three fully-compatible BY licenses. Note that the lack of an SA clause in these three licences, permits re-users to produce works that are not free, though of course such works could not be hosted here. -- Colin (talk) 08:36, 19 October 2017 (UTC)[reply]

I agree with the reservations you've expressed Colin. I saw this proposal as "aspirational", i.e. the Commons Community approves of the goal of supporting in the Data namespace licenses that meet the WMF "freedom defined" standard with the proviso that any such support must be consistent with the aims of Wikimedia Commons. If it is impractical to support one or more of these licenses in a manner that honors the terms of the license, or the interaction between the requirements of a license and the Data namespace prevent or otherwise discourage the creation of derivative works (something I feel is outside the aim of Wikimedia Commons), then I don't think those licenses should be permitted in Data namespace (this is what I assumed "considered relevant to tabulated data and maps" was sort-of-awkwardly expressing). To that end, I think any implementation of this proposal should incrementally add support for individual licenses. By the way, as a minor aside, the ODC ODbL does have a share-alike clause (see section 4.4) that is triggered by any use of a "substantial" part of the licensed database. A work derivative of an OGL database and a substantial portion of an ODC ODbL database must be licensed under the ODbL. Licenses that contain share-alike clauses are typically incompatible with each other. Surprisingly, the OpenStreeMap project even considers CC-BY and ODbL incompatible (see Use of CC BY 4.0 licensed data in OpenStreetMap and their ODbL Compatibility matrix). However, both ODbL and newer versions of the CC licenses include compatibility clauses, so it is possible these incompatibilities could be rectified by a future agreement between ODC and CC to add their respective licenses to their lists of compatible licenses. —RP88 (talk) 11:59, 19 October 2017 (UTC)[reply]

RP88, thanks for the info. From this link we can see that the share-alike licences CC BY-SA 4.0 and Free Art Licence 1.3 are fully compatible. But GPLv3 is one-way-compatible only. And other versions are generally not compatible at all as you note. There is a big difference between data and images that I think is relevant to considering SA licences for data, so I think we need to be wary of comments like "this is just like collages". Most uses of images are not collages and most uses of images are not to create derivative works. Wikipedia happily uses any freely licensed image, and different images of various incompatible licences and be mixed with incompatibly licensed text. And my CC BY-SA photos can be happily used in a book that is (c) All Rights Reserved without free licensing because one only needs to state that my photo is freely used and give a link to where they got it from for someone else to re-use it again. I may be wrong, but I suspect many uses for data are to create derivative works, and to mash up e.g. a map with a regional area with a set of locations.

Wrt to your "substantial portion" comment, when does Commons accumulate enough individual pieces of another database that it then becomes a substantial copy of a portion of it? I recall issues on Wikipedia with the DSM psychiatry manual. While it is permissible to quote short texts from another work on Wikipedia, if all our medical articles quote short texts from DSM, then Wikipedia eventually gets too much of the DSM, which is very much copyright protected. So quoting from the DSM is simply disallowed (or at least, it was years ago when I edited more frequently there).

Wrt to the "aspirational" nature of the proposal, I would not be concerned about voting if the proposal was clearly reworded to make it so. But currently it says "this proposal is to allow all those [licences] considered relevant to tabulated data and maps" which is carte blanche open-ended permission. I don't think the community would be wise to authorise that just yet. Much better to consider carefully whether we want to shift from the current "no strings data" to "strings attached data" at all, in other words, to go from having unlicensed PD data to having licensed copyrighted data. That's a big jump concept in itself, before we even consider which licenses are practical to support. -- Colin (talk) 13:31, 19 October 2017 (UTC)[reply]

Collections can indeed include works with incompatible share-alike clauses. Commons is itself such a collection, as I have no doubt the Commons database contains GPL licensed text in the form a PDF somewhere, but the Commons database is not itself required to be GPL licensed. With regards to ODbL's share-alike clause being triggered by any use of a "substantial" part of the licensed database, it is a term-of-art defined by the ODbL, not a feature of copyright law in general and as such only applies to ODbL licensed databases. Your DSM example does not involve the ODbL, so for it you need to look to the threshold of originality and fair use to determine the point at which too much is used. OSM has a nice guideline for their interpretation of "substantial" as it relates to their ODbL licensed database. —RP88 (talk) 14:18, 19 October 2017 (UTC)[reply]

As a quick update from the Foundation, SLaporte and I chatted yesterday about why we currently only accept CC0-released data in the Data namespace. The full legal public response to this issue will take a few days for us to prepare, but we wanted to let you know that we have heard you and the questions being asked. There are a couple of tickets open around this topic that we'll be tracking as well: T154071 and T178210. Thanks for your patience, DTankersley (WMF) (talk) 19:25, 19 October 2017 (UTC)[reply]

@DTankersley (WMF): Just for clarity, and to avoid any later misunderstanding of how we got here, the reason why "we currently only accept CC0-released data in the Data namespace" was not a WMF decision, nor ever voted on by the Community, based on the records of discussions when the concept was created. The idea for the Data namespace came from the 2015 Community Wishlist Survey and was followed up with a discussion on Commons (see links in the proposal). The decision to go with CC0 was not based on any actual legal reasoning, nor even for compatibility with Wikidata, and the discussion and vote to start experimenting with the Data namespace in 2016 only went with CC0 as a starting point, with the option to add other licenses once it got underway. Conflicts with licenses like those used for Open Street Map content and the database were never reviewed.

Before WMF legal publish a statement, could you confirm what specific question is being worked on? Thanks --Fæ (talk) 19:49, 19 October 2017 (UTC)[reply]

@Fæ: We will be sharing why we started with CC0, and some other resources in ODbL. If there are concerns with this topic, or if you do not want us to participate in this discussion (as it seems like you're asking in your post), please send me an email and we can discuss this in that manner. DTankersley (WMF) (talk) 20:58, 20 October 2017 (UTC)[reply]

@DTankersley (WMF): Thanks for the reply. It's probably worth repeating, as you are using "we" to mean WMF Legal and wrote that "we started with CC0". Starting Data namespace files with CC0 was not a choice based on legal considerations, nor was it the choice of the WMF. Consequently the literal "why" would not appear to be helpful in moving forward this proposal.

With regard to "other resources in ODbL", Wikimedia Commons already has many map files hosted which rely on the ODbL just not "officially" in the Data namespace. As far as I'm aware, the ODbL has never been a conflict with Wikimedia Commons hosting in terms of policy or legal constraints. There is the secondary related issue that Open Street Map content often relies on other licenses which include an attribution requirement, in particular data sets sourced from a number of different Government data services (example). I have no idea if these considerations are what WMF Legal want to make a statement about, as it appears tangential to this proposal of extending the Data namespace to non-CC0 licenses.

I have made no request that WMF legal cease participating here, the question was "could you confirm what specific question is being worked on?". That question has yet to be answered, and I have no idea why it is being avoided. I would rather not be left to speculate. Thanks --Fæ (talk) 13:33, 21 October 2017 (UTC)[reply]

Hello, we've posted a response to the legal question of usage of CC0 data in Phabricator. I've copied some of it here:

"According to the Wikimedia License Policy, the Wikimedia projects may only accept material that meets the definition of Free Cultural Works. This includes material that is protected by copyright but released under a compatible free license, or work that is in the public domain because it is not protected or restricted by copyright law.

"Currently, the tabular data and map data features support a CC0 dedication.

"CC0 is suitable for data because:

CC0 does not add extraneous restrictions on factual data points that are not protected by copyright law or other rights.

CC0 is widely used and recommended for sharing datasets.

CC0 is easily compatible with other open licenses, so datasets can be combined or remixed without compliance concerns (other data-focused licenses have more complex compatibility questions like the Open Database License).

CC0 promotes legal predictability and certainty. More restrictive database licenses are tied to the existence of copyrights, neighboring rights, or sui generis database rights that vary from country to country.

"There are many data sources that use licenses other than CC0. Popular examples include Creative Commons Attribution-ShareAlike (CC BY-SA) 3.0 material, used on Wikipedia, and Open Database License (ODbL) material, used by Open Street Maps. As a general rule, people must use material in compliance with these license terms and release their work under a compatible license. However, there are circumstances where material from a source licensed under CC BY-SA or ODbL may be used in a dataset released under CC0."

Please read the rest of the post in Phabricator: https://phabricator.wikimedia.org/T178210 and let us know if there are any further questions about the use of CC0 in the map or tabular data namespaces. DTankersley (WMF) (talk) 01:41, 7 November 2017 (UTC)[reply]

Having read the post in Phabricator, the one-sided question raised and answered by WMF Legal, explores the benefits of CC0, which I think everyone voting in this proposal already knew. The proposal does not say "stop using CC0", in fact we would probably all continue to encourage maps and other JSON data to be published with a valid CC0 license as the preferred and default license for all data. What this proposal does do is make it possible to use other licenses and avoid having to delete "Free Cultural Works" which are clearly within Wikimedia Commons' project scope. Should the proposal fail, the community would be forced to invest a huge amount of volunteer time continuously assessing and debating deletion requests to assess whether claimed CC0 maps which reuse other data sets, sufficiently meet the legal requirements for "material from a source licensed under CC BY-SA or ODbL may be used in a dataset released under CC0", as we have seen in the DR that started this proposal.

In practice, I do not see how the basic observations from WMF Legal about CC0 should sway the outcome of the proposal. --Fæ (talk) 09:43, 7 November 2017 (UTC)[reply]

I agree with Fæ's conclusion. -Shaundd (talk) 14:25, 7 November 2017 (UTC)[reply]

The 2017 Community Wishlist Survey it currently going on (phase 1 Nov 6–19), perhaps we need to add a entry for this proposal there. - Offnfopt^(talk) 14:50, 7 November 2017 (UTC)[reply]

My reading is "put NOTHING there until the WMF adds software support for other licenses". Any CC other than explicit CC0 can't go there. Anything more than negligible quantity of OpenStreetMap will be "substantial" and will invoke the license. They failed to provide any answer on OpenGovernment, and until that say "yes" then I believe that is a "no". The community needed to communicate our questions to WMF-legal more directly, because filtering the communication through other WMF staffmembers got the wrong questions asked and the wrong answers back. Alsee (talk) 23:26, 8 November 2017 (UTC)[reply]

Proposal to migrate interwiki links to Wikidata (wherever possible)

For detailed proposal, see

c:Commons:Bots/Work_requests#Migrate_interwiki_links_to_Wikidata

~~which may be the best place for detailed comments and follow-ups, to keep discussion all in one place.~~

Essentially, now that the template {{Interwiki from Wikidata}} exists and is in wide use, that preferentially shows interwiki links from Commons categories to Wiki articles if possible, and Wiki categories if not, I suggest that:

Interwiki links held locally be de-materialised from here, wherever they correspond to what would be generated via a Wikidata sitelink, the interwikis held on Wikidata, and the {{Interwiki from Wikidata}} template.
Sitelinks to Wikidata items be created as necessary to enable this.
Sitelinks to go to a corresponding category-type item on Wikidata if such a category item exists; otherwise to an article-type item there.
But care to be taken, and sitelinks not to be added, if there is any detectable ambiguity as to which Wikidata item should be linked to.

I suggest that this would have the following benefits:

The interwiki links on Wikidata are more likely to be maintained, and so may be more comprehensive, as Wikidata is the central site where Wiki <-> Wiki interlinks are held.
Interwiki links via Wikidata will automatically reflect any merges or editing of the Wikidata items and which Wiki pages they are connected to.
Better identification between Commons categories and Wikidata is useful in preparation for Structured Data, for understanding categories here, and for facilitating templates that can draw on Wikidata.
In particular, sitelinks are helpful for getting Wikidata-driven templates on Commons to work automatically.
It will no longer be necessary to make separate edits here and at Wikidata to link to a new wiki article in a new language.

User:Fæ has criticised me for jumping straight to COM:BR to raise the proposal for discussion, and he's probably right. ~~But as it is there, with more detail that people might like to comment on, it might be best to go on with the discussion there.~~

Struck, per User:Colin below. Jheald (talk) 19:02, 7 November 2017 (UTC) [reply]

In companion to this, I have also proposed at Wikidata project chat to revise the Wikidata notability guideline and explicitly confirm that such sitelinks are appropriate, to bring policy there de jure into line with what has long been the case de facto. Jheald (talk) 18:06, 7 November 2017 (UTC)[reply]

Oppose There has been insufficient preparation for this proposal. Examples:
1. The assertion "links on Wikidata are more likely to be maintained" is unproven. With a significantly smaller active community on Wikidata, it is more likely that changes to the category structure on Commons will cause drift from any Wikidata syntactical meaningfulness, and Commons contributors are unlikely to want to be forced to edit Wikidata to correct mistakes there. The likely/unlikely assertions need backup with evidence in advance of this proposal.
2. "interwiki links via Wikidata will automatically reflect any merges or editing" is a Wikipedia way of thinking, there is no analysis here of how category changes, including amending hierarchies, sub-categorization, mass re-categorization or even category renaming will be maintained via Wikidata's P/Q arcane number systems, nor whether Commons contributors will now be expected to do that Wikidata analysis and changes before they can get on with doing smart quick categorization with cat-a-lot. This is an area that could do with a simple guide and backup analysis of the practical use, before running ahead with proposing mass changes that result in Commons categories being controlled or frozen via Wikidata due to the burden this introduces.
3. With on-going discussion at Wikidata, the foundation of this proposal is not yet fixed. Wikidata must have its house in order before proposing mass changes on Commons.
4. "sitelinks not to be added, if there is any detectable ambiguity" there is no agreed guide on how this will be measured, nor even where the locus of future disputes will be.
Please make a proposal when there is a credible foundation of evidence and best practice to support it. If the changes create an avoidable additional burden on Wikimedia Commons volunteers interested in maintaining categorization, then that is not in the interests of this project. --Fæ (talk) 18:21, 7 November 2017 (UTC)[reply]

@Fæ: Really? Do these objections really add up?

Yes, the Wikidata-specific community is small. But Wikidata is where editors from every community go to manage their interwiki links, via the "quill" icon in the interwiki part of the sidebar. If they want their new page to be sitelinked to any other wiki, they go to wikidata. They do not, I suggest, very often come here. It's what Wikidata was built for, and why interwiki links via Wikidata are likely to be more extensive and less stale than interwiki links here, which according to User:Jarekt he hasn't systematically updated for at least 5 years. No, I don't have any numbers to back that up; but I am sure if anyone is really interested they could look to see how many interwiki links have been added at Wikidata in the last year, and what proportion of those have been added to a category here. Personally I'd be surprised if it was even 5%.
In thinking about category changes here, yes all sorts of refinement happens but I submit that it is rare if a category has a role, that that role gets handed to a different category. Yes the category may get renamed or merged, but the software should be able to follow that, and update sitelinks accordingly. More often in hierarchy refinement, cat-a-lot is used to create and populate subcategories, without changing the meaning of the original category. Also worth considering is that if the information on Wikidata is not updated, that will typically break incoming links from Wikis, which tend to follow P373 statements on Wikidata rather than interwikis. The interwikis on Commons currently really only determine links from Commons categories to Wikis. To make sure links in both directions get updated, it would probably be no bad thing for them to be all managed in the one place.
"Detectable ambiguity". The different ways I could think of to detect ambiguity are set out in the more detailed proposals I posted at COM:BR (which you criticised as being unhelpfully technical for a policy discussion, which needed to first establish the generalities). If people have thoughts about any further ways to identify abiguities, please do bring them to that discussion at COM:BR.
Wikidata policy. Yes, it would be profoundly unhelpful if we were to add sitelinks and Wikidata was to delete them. But I don't think that's going to happen. I think there's broad acceptance in the community there of article-type items sitelinking to categories here, as over half a million such site-links currently bear witness to. It would be useful to confirm that explicitly in Wikidata policy. But it seems to me useful for the two discussions to run in parallel -- I don't see any benefit in holding up this one to wait on the other one. Jheald (talk) 19:00, 7 November 2017 (UTC)[reply]

Responding to ping: Thanks for your responses, however you have left the questions open ("likely", "I am sure", "should be", "probably", "I don't think"), apparently expecting others to provide evidence to back up your proposal. The burden of proof is on the proposer. Nobody expects you to do this on your own, but the proposal should only be put to the community when the assertions of benefits or impact made in the proposal can be verified. Without being given those basics, people are voting yes/no on wishes and guesstimates, and we should be able to do better than the type of popularity vote that leads to Brexit and President Trump. Thanks --Fæ (talk) 19:33, 7 November 2017 (UTC)[reply]

Comment Could I suggest, for crying out loud, that we just have a discussion. You know those things where people try to find some common agreement and work towards a goal? Instead, as seen above, when Commons votes you just get person A saying all sorts of polarised things in favour and person B saying all sorts of polarised things against, rinse and repeat, and we never advance, never progress towards agreement. Despite JHeald's request, we currently have comments/votes on two pages. I would strongly recommend using a community page like this one, rather than an obscure bot page that fewer people have in their watchlists. This isn't really about running a bot (yet) but whether the community thinks the migration of these links is a good thing. -- Colin (talk) 18:38, 7 November 2017 (UTC)[reply]

Fine, let's have the discussion here then. Jheald (talk) 19:00, 7 November 2017 (UTC)[reply]

Support the idea of retiring old style interwiki links which everybody else stopped using since Wikidata come along. In the past I was the one that occasionally run interwiki update bot, but have not done so for last 5 years since Wikidata project started and everybody else migrated to Wikidata based interwikis. As a result many of the links are likely very stale. So I agree that we need to migrate, but details about how would vary with namespace:

File: All interwiki links should be removed
User: Old style should remain
All the rest except for Category and Gallery. Should rely on Wikidata sitelinks.
Gallery: I would suggest using {{Interwiki from Wikidata|Wikidata=Q????}}
Category: This one should have majority of links. There are 2 possibilities:
1. Add {{Interwiki from Wikidata}} without hardwired q-code and rely on having Wikidata sitelink from either article-item or category-item
2. Add {{Interwiki from Wikidata|Wikidata=Q????}} with hardwired q-code and not use Wikidata sitelinks

Option #1 is much easier to maintain as any correction would have to be done only in one place and you would not have to keep q-codes on Commons in synch with Wikidata sitelinks. The challenge of option #1 is that if you have the usual setup with sitelink from article-item to Commons-category and than someone creates Commons-gallery than article-item sitelink might get changed to the gallery. At this point Commons-category will loose its interwiki links. So option #1 would only work if we agree that sitelinks to Commons categories should take precedence over sitelinks to galleries, and than convince Wikidata Community that that is a good idea. Let me, ping @Multichill and Zolo: , who might also be interested in this discussion. --Jarekt (talk) 20:09, 7 November 2017 (UTC)[reply]

Probably best to focus on categories. For me {{Interwiki from Wikidata}} in it's current form is just the start. Maybe spend some time on improving the template so it shows some nice description in your local language based on Wikidata? That would really add benefit from grabbing data from Wikidata. Multichill (talk) 20:38, 7 November 2017 (UTC)[reply]

That's the {{On Wikidata}} template. I'm not sure that we really want to take up space in the header of every category though, when there's already a link to Wikidata in the sidebar (assuming the site link variant is used). I thought it had already been the consensus to replace the old-style interlanguage links for years, and I've been deleting them and replacing with site links whenever I see them. It would be preferable for a bot to do it. --ghouston (talk) 04:38, 8 November 2017 (UTC)[reply]

Gallery, I don't see much value there. Category to main concept is the way to go. — regards, Revi 09:22, 23 November 2017 (UTC)[reply]

To me, good galleries would be our preferred introduction to a topic from outside -- they would have curated images, and some descriptions. I could see linking both a gallery and a category, I suppose. Carl Lindberg (talk) 14:30, 24 November 2017 (UTC)[reply]

You mean linking category and a gallery in same wikidata item? That is technically not possible. It is in Wikidata dev's radar for at least 3 years, and it's still not possible. — regards, Revi 09:57, 2 December 2017 (UTC)[reply]

Support Strongly support, it is only a question of time. In the beginning Commons itself was questionable separate (image data store) project. In time all growth together. In effect the interwiki-links on Wikidata get much much more proven as a single page on Commons (alle projects can data changes on here watchlist and also Commons). Anyway I don't see that problems described by Fæ. So I see really no reason why Commons should go alone separated from WD. -- User: Perhelion 13:17, 11 December 2017 (UTC)[reply]

Watch creations by default

An editor has requested comment from other editors for this discussion.
If you have an opinion regarding this issue, feel free to comment below.

Should the "Add pages I create and files I upload to my watchlist" preference be checked by default on this wiki? It already is on other wikis. If the consensus is in favor of this proposal, then task T178750 can be approved. GeoffreyT2000 (talk) 19:53, 20 November 2017 (UTC)[reply]

Support This checkbox is in the "Advanced options" section of Special:Preferences#mw-prefsection-watchlist. — Jeff G. ツ 14:02, 30 November 2017 (UTC)[reply]

Discussion

Comment I'm surprised to read that it's not default. I think that would make a lot of sense. --El Grafo (talk) 13:17, 30 November 2017 (UTC)[reply]
So am I. — Jeff G. ツ 14:02, 30 November 2017 (UTC)[reply]
Support Enabling this would only make life easier for our new users. Guanaco (talk) 03:05, 3 December 2017 (UTC)[reply]
Support This is already the default on every other wiki. --Donald Trung (Talk 💬) ("The Chinese Coin Troll" 👿) (Articles 📚) 10:10, 8 December 2017 (UTC)[reply]
Support Also surprised this wasn't already set. Carl Lindberg (talk) 16:45, 9 December 2017 (UTC)[reply]
+1 ok Christian Ferrer ^(talk) 17:01, 9 December 2017 (UTC)[reply]
I do not have a strong opinion on this one, just to remark that for those of us who create a lot of categories this can be pretty annoying.--Ymblanter (talk) 20:19, 9 December 2017 (UTC)[reply]
Support: in general, where a feature is helpful to new or occasional contributors but annoying to ‘power users’ (like Ymblanter immediately above), it should be opt-out because the latter can be presumed savvy enough to turn it off while the former may not even be aware it exists as an opt-in.—Odysseus1479 (talk) 20:40, 9 December 2017 (UTC)[reply]
Strong support: Some of the watchlist categories seem to be off by default on en.wp, and I have many times helped newbies get watchlisting to work as expected by flipping a toggle in Preferences. It would be a nice thing to have it work the first time. I support setting this ON by default on Commons. -- econterms (talk) 20:21, 11 December 2017 (UTC)[reply]

Grant patrol to license reviewers

I think license reviewers should be able to "patrol" by default, as the two user rights are closely related in purpose. When completing a license review, it should be standard practice to mark the file as patrolled. In terms of user trust, currently any reviewer in good standing would receive the patroller user group on request. Guanaco (talk) 07:14, 29 November 2017 (UTC)[reply]

I agree.--Ymblanter (talk) 08:39, 29 November 2017 (UTC)[reply]

Yes, this is quite logical. Yann (talk) 08:47, 29 November 2017 (UTC)[reply]

No objections. But isn't the case mentioned above already covered with the license reviewer group containing the autopatrol user right? --Didym (talk) 11:06, 29 November 2017 (UTC)[reply]

@Didym: Editing the file page doesn't mark the file itself as patrolled. Guanaco (talk) 11:21, 29 November 2017 (UTC)[reply]

Then forget about the second part of my comment. --Didym (talk) 13:01, 29 November 2017 (UTC)[reply]

Support — Jeff G. ツ 13:21, 29 November 2017 (UTC)[reply]

Sounds good. License reviewers are held for higher standard than Patrollers, anyway. — regards, Revi 09:55, 2 December 2017 (UTC)[reply]

Support. -- Geagea (talk) 04:18, 3 December 2017 (UTC)[reply]
Support This actually makes a lot of sense. --Donald Trung (Talk 💬) ("The Chinese Coin Troll" 👿) (Articles 📚) 10:08, 8 December 2017 (UTC)[reply]
+1 Christian Ferrer ^(talk) 17:03, 9 December 2017 (UTC)[reply]
Support — D Y O L F 77^[Talk] 21:55, 10 December 2017 (UTC)[reply]

Plural category names

All of our categories are designed to hold more than one object (including subcategories, pages, and files). Most of them do hold more than one object. For those category names which are not proper names or taxonomic, they should be in plural form. For instance, I would like to see Category:Duplicates rather than Category:Duplicate. — Jeff G. ツ 15:22, 6 December 2017 (UTC)[reply]

Well, what you are proposing is already official Commons policy: Commons:Categories#Category_names ;-) Category:Duplicate is a bit different in that it is a maintenance Category that is filled automatically with files tagged with {{Duplicate}}. I'd prefer it to be named Category:Duplicated files, but renaming it might break some things … --El Grafo (talk) 16:52, 6 December 2017 (UTC)[reply]

I agree on "Duplicate". Established project categories shouldn't be renamed unless we change their scope or unless the name otherwise would be confusing, since renaming causes "issues" within the project, and as long as we insiders know what they do, that's sufficient. "Duplicate" is a good example of when not to move: anybody who understands "Duplicates" or "Duplicated files" will know what "Duplicate" means. Nyttend (talk) 13:36, 7 December 2017 (UTC)[reply]

Allow archiving of other users' overlarge talk pages

When user talk pages hit Category:User talk pages where template include size is exceeded, templates no longer function. This includes all deletion alerts and signatures, making those alerts almost useless: the user is given no direct link to any of the deletion discussions, nor even any suggestion that there might be a problem, and there is no working link to the alerter's talk page.

I just noticed this on User talk:Talmoryair, who ironically hit the template limit immediately after a final warning for copyright violations. All subsequent messages, which may or may not be about further copyright violations, just say "Template:Autotranslate", and the user had no option to put things right.

So I suggest that Commons:Talk page guidelines and Category:User talk pages where template include size is exceeded be updated to explicitly allow any user to add {{subst:User:MiszaBot/usertalksetup}} to a user talk page that has hit this limit. --Gapfall (talk) 19:05, 10 December 2017 (UTC)[reply]

Support — Jeff G. ツ 20:17, 10 December 2017 (UTC)[reply]

Conditional support: I think there should be guidance to the effect that an active user should be alerted to the problem first, and that others should only act if the user fails to address it in a reasonable time. Most people will comply with a polite request, or ask for help, without any feathers being ruffled.—Odysseus1479 (talk) 21:30, 10 December 2017 (UTC)[reply]

@Odysseus1479: How much time, a week? — Jeff G. ツ 21:49, 10 December 2017 (UTC)[reply]

I think what’s “reasonable” would depend on the circumstances: if the user is obviously active on the site, after only a few hours I’d start to get the impression a notice was being ignored … but if a firm time-limit is wanted, a week ought to be plenty, even where the user hasn’t edited since being alerted.—Odysseus1479 (talk) 22:09, 10 December 2017 (UTC) P.S. I wouldn’t object to a shorter time: my main point is to say “ask first.” – 22:12, 10 December 2017 (UTC)[reply]

Could we just subst some of the old templates? Or would archiving still be better? Carl Lindberg (talk) 01:52, 11 December 2017 (UTC)[reply]

If someone says no, that should be respected.

I run a notice shrinker on my talk and a few others. If anyone would like this for their page they can drop me a message. Example diff --Fæ (talk) 02:43, 11 December 2017 (UTC)[reply]

No, that shouldn't be respected. No user "owns" their talkpage. We need to be able to have proper communications with all users, no user should be able to protect their talk page to disallow any user from editing it, so it should go to reason that transcluding too many templates would do just that. If a user wants to have a "long talk page" that shouldn't matter. Warning about copyright etc are dictated in policy, and the "means" to leave such should be a must for all user talk pages. --Jonatan Svensson Glad (talk) 04:16, 11 December 2017 (UTC)[reply]

It's rather a question of whether folks are okay with not turning this into a bureaucratic and provocative argument about you-don't-own-your-own-talk-page. My view is that boiler-plate notices like those for copyvios and DRs are no big deal on a page where the user already has 20 or 50 of the darn things. We can safely presume that they know exactly what they mean and have read the earlier boiler-plate text.

It would be more useful to adapt the javascript of the DR notification gadget to "degrade gracefully", by it noticing when transclusion is going to fail, and instead leave a more basic summary, like "A DR has been raised on <this file>, please see <DR link>" which need no transclusions to do exactly the same job. --Fæ (talk) 11:55, 11 December 2017 (UTC)[reply]

Well, to be fully i18n we need to transclude that sentence as a template no matter the lenght or design of it, --Jonatan Svensson Glad (talk) 12:01, 11 December 2017 (UTC)[reply]

Sure, however this proposal is a good example of how we are never going to be i18n compliant in everything, and probably don't want to be. It's a pragmatic decision that harms nobody considering we are talking about a very small number of pages. --Fæ (talk) 12:04, 11 December 2017 (UTC)[reply]

The DR notification gadget change is a positive idea and gets to the heart of the problem which is inherently technical. If it notices there are too many notices already and it may hit the template calls limit, then realistically for error fallback behaviour it should just produce a link to the discussion and nothing else. seb26 (talk) 15:34, 11 December 2017 (UTC)[reply]

So far as I understand it, {{Autotranslate}} is there on every template (and signature link?) to make the text appear in the native language of the reader, according to their Commons settings. If an English-language editor substs it, it'll become fixed in English at that point. --Gapfall (talk) 11:41, 11 December 2017 (UTC)[reply]

Returning to basic facts, my search shows there are just 58 main user talk pages where this is an issue, the rest are subpages like archives which should not be touched anyway. Such a small number of pages, many of which are users who are no longer active, should not set a precedent for policy changes. Push comes to shove, I could add the lot to my template shrinker (which simply comments out the most obvious notice transclusions) and this would get solved without forcing archive processes on anyone. --Fæ (talk) 14:36, 12 December 2017 (UTC)[reply]

If template shrinkage would be less contentious than archiving, sure, good idea. Your example is efficient but a little on the terse side - would expanding it with a brief explanation ("There is a problem with your upload File:XYZ.jpg. Please see [link].") be a good idea? With an exclamation mark icon to hopefully get the message across to users who don't read English. --Gapfall (talk) 09:28, 13 December 2017 (UTC)[reply]

Support with an alert and one - two weeks to do it themselves. --Jarekt (talk) 03:30, 11 December 2017 (UTC)[reply]

Oppose fix your code. rewrite your templates in lua. the fact that you persist in breaking the dysfunctional talk page with your bloated adversive warnings is not the editor's problem. it is yours. stop wasting everyone's time with your inability to collaborate. Slowking4 § Sander.v.Ginkel's revenge 04:22, 11 December 2017 (UTC)[reply]
@Slowking4: How do you suggest we "rewrite ... templates in lua"? — Jeff G. ツ 05:03, 11 December 2017 (UTC)[reply]
- - apply Commons:Lua to Category:Deletion templates; Template:Autotranslate . the nested calls explode size. over reliance on automated suite of tools that break talk, rather than text which would not. or you could automatically configure use talk with archiving, since the feature appears to be necessary. and you could cleanup this Category:Templates using an unknown approach for internationalisation Slowking4 § Sander.v.Ginkel's revenge 18:41, 11 December 2017 (UTC)[reply]

Comment Actually, {{subst:User:MiszaBot/usertalksetup}} isn't great on its default settings ("minthreadsleft = 0") because that could potentially archive the entire talk page in one go, which might be unwanted or confusing. But a variant with the threads-to-keep tweaked to roughly match the template limit (from looking at User talk:Talmoryair, 100 threads?) seems inoffensive. --Gapfall (talk) 11:41, 11 December 2017 (UTC)[reply]

Strong support it would probably be best to make a bot to archive all discussions older than 365 days automatically, and all IP user talk pages should always be archived after 180 days (archived not blanked, and certainly not deleted), some users have walls and walls of deletion request notices and warnings, these should probably all best be archived for readability's sake. I suggest two simultaneous archiving system, the current opt-in ArchiverBot and SPBot archiving system, and a non-removable auto-archive for posts and/or discussions older than a year (unless otherwise specified). --Donald Trung (Talk 💬) ("The Chinese Coin Troll" 👿) (Articles 📚) 14:27, 12 December 2017 (UTC)[reply]
@Donald Trung: Do you have a source for "180 days"? — Jeff G. ツ 15:44, 12 December 2017 (UTC)[reply]
When user is asked to archive their talk page, they usually do so. I've seen few people archiving their usertalk when asked. If you want to "force archive other's usertalk", I believe there should be some clause "You must contact the user and give the chance to clean up themselves. You can only forcibly archive the user talk page if the user failed to reply within $month or $week or even $quarter." — regards, Revi 01:29, 13 December 2017 (UTC)[reply]

The problem isn't cleaning up, it's that templates stop functioning. You'd have a $month or $quarter of any further alert templates given to that user arriving blank, probably without the templater realising. In cases like User:Talmoryair (who seems to have provided OTRS proof for questioned uploads in the past), we risk losing useful content because the user isn't being clearly told that their images may be deleted (many of these templates don't even mention the filename and just print the words "Template:Autotranslate" when they break), and the user doesn't react to resolve anything. --Gapfall (talk) 09:28, 13 December 2017 (UTC)[reply]

I think giving user chance to clean themselves up before doing it outright is mellow-er than just archiving it outright. If you are getting hundreds of talk page notification templates that even cause the template transcluding starts to break, we can assume they are (highly) active on Commons, and would get a talk page notification in reasonable timeframe, and act upon it. Everyone might have different preferences on archiving, and I wouldn't like if somebody did it in the way I don't like. (Of course in this case, no archiving wouldn't be an option here.) — regards, Revi 15:39, 16 December 2017 (UTC)[reply]

Anecdotal, but I made such an archive request to the user who prompted this proposal, a week ago, and they've ignored it. They've also uploaded 250 more images since then. (They possibly don't read English fluently, and I can't embed an autotranslated version of the archive request template because templates have stopped functioning on their talk page.) --Gapfall (talk) 09:08, 19 December 2017 (UTC)[reply]

@Gapfall: I made a similar request to Slowking4, fat lot of good it did. That was after a prior attempt over three years ago. — Jeff G. ツ 09:30, 19 December 2017 (UTC)[reply]

that's right, not my responsibility to fix your broken notification code. do not read them anyway. you want to spam people's talk with broken code, you fix it. shifting the burden for your broken processes to others is a symptom of just how broken this place is. Slowking4 § Sander.v.Ginkel's revenge 09:44, 19 December 2017 (UTC)[reply]

I support that, with an attempt at communication or not, because honestly, in almost such cases I'm wonder if the users even care or watch their talk page... It already happened that I took the freedom to do it, I mean to archive a user talk page. I'm not able to find this talk page, but if I remember well the user seemed not to be active since a few month, (years?), did never answer in DRs or did never try to resolve source/permission issues. I was frustrated to see my notifications no working in the talk page. I was pretty sure that he would not have done it and would not have answered a request in that way. Therefore I did it. Christian Ferrer ^(talk) 18:28, 16 December 2017 (UTC)[reply]
Oppose The only purpose of user talk pages is for the benefit of the user concerned. It is unfortunate that the wiki software can't cope with a large number of templates, but if templates don't display properly, the user has an easy fix (archiving). It seems like what you are trying to do is force the user to read and care about the message, and I don't think forcibly archiving their page for them will do that. Some people just want to be a little obstinate, and I don't think forcing them to appear to toe the line is a smart way to deal with a perceived problem. That said, if the user complains they weren't notified of something, they of course have no leg to stand on, as long as the notification would have worked had the page been more reasonably maintained. In essence, my position is that while broken talk pages are a mild annoyance, instituting a policy to force compliance to some arbitrary rules is worse for the project than the broken talk pages are. Storkk (talk) 10:42, 19 December 2017 (UTC)[reply]
Oppose - If an editor doesn't wanna archive their tlakpage then that's up to them - We shouldn't force them!, If long user talkpages are breaking templates then it's the templates that need fixing not the users talkpage. –Davey2010^Talk 14:29, 19 December 2017 (UTC)[reply]
Support We can't "fix" templates without subst'ing them and leaving a bunch of unreadable junk in the wiki text, or removing all the boxes and stuff that's supposed to make it look good. Even if we subst all the templates, you'd still deal with a huge unwieldy page. As per Slowking4, some users just don't care about working with other people in a reasonable way. If the user doesn't care about stuff being added to the talk page, then why should they care about it getting archived?--Prosfilaes (talk) 06:37, 20 December 2017 (UTC)[reply]
- i care about working with people, which leaves off the autocrats of commons. i win awards for collaboration. which is why i would oppose, adversive projection of responsibility to fix broken code upon uninvolved editors. fix your incompetence, do not make others archive your incompetence. Slowking4 § Sander.v.Ginkel's revenge 02:12, 21 December 2017 (UTC)[reply]

@@ Line 345: / Line 345: @@
 *{{o}} - If an editor doesn't wanna archive their tlakpage then that's up to them - We shouldn't force them!, If long user talkpages are breaking templates then it's the templates that need fixing not the users talkpage. –[[User:Davey2010|<span style="color: blue;">'''Davey'''</span><span style="color: orange;">'''2010'''</span>]]<sup>[[User talk:Davey2010|<span style="color: navy;">'''Talk'''</span>]]</sup> 14:29, 19 December 2017 (UTC)
 *{{support}} We can't "fix" templates without subst'ing them and leaving a bunch of unreadable junk in the wiki text, or removing all the boxes and stuff that's supposed  to make it look good. Even if we subst all the templates, you'd still deal with a huge unwieldy page. As per Slowking4, some users just don't care about working with other people in a reasonable way. If the user doesn't care about stuff being added to the talk page, then why should they care about it getting archived?--[[User:Prosfilaes|Prosfilaes]] ([[User talk:Prosfilaes|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 06:37, 20 December 2017 (UTC)
+**i care about working with people, which leaves off the autocrats of commons. i win awards for collaboration. which is why i would oppose, adversive projection of responsibility to fix broken code upon uninvolved editors. fix your incompetence, do not make others archive your incompetence.<font face="Vijaya">[[User:Slowking4| Slowking4]] § [[User_talk:Slowking4|Sander.v.Ginkel's revenge]] </font> 02:12, 21 December 2017 (UTC)

Commons:Village pump/Proposals: Difference between revisions

Revision as of 02:12, 21 December 2017

Contents

Proposal to uninstall Flow

Responses

Discussion

Proposal to include non-CC0 licenses for the Data namespace

Votes

Discussion

Proposal to migrate interwiki links to Wikidata (wherever possible)

Watch creations by default

Discussion

Grant patrol to license reviewers

Plural category names

Allow archiving of other users' overlarge talk pages

Navigation menu

Commons:Village pump/Proposals: Difference between revisions

Revision as of 02:12, 21 December 2017

Proposal to uninstall Flow

Responses

Discussion

Proposal to include non-CC0 licenses for the Data namespace

Votes

Discussion

Proposal to migrate interwiki links to Wikidata (wherever possible)

Watch creations by default

Discussion

Grant patrol to license reviewers

Plural category names

Allow archiving of other users' overlarge talk pages

Navigation menu

Search