Wikipedia:Village pump (WMF)/Archive 2#IP Address Masking Confirmed As Mandatory

• Support as nom. They should simply insert the new comment without a needless Rube Goldberg round-trip-translation. It is inexcusable that the Foundation has such gross disregard for fixable wikitext corruption. Alsee (talk) 18:43, 28 October 2020 (UTC)
• Support the need to fix this fundamental flaw before deploying this tool. Barring that, local WP instances should have the option to disable it until it is fixed. Developers might complain that these are edge cases, examples of GIGO, but garbage exists, and the Wikimedia software does not prevent it from existing. The reply tool should simply post an indented (LISTGAP-compliant, presumably) reply, regardless of the text around it. If it can't do a simple reply for some reason, it should emit an error message asking the editor to reply using regular editing. I would love to trust the developers to deploy a mostly working tool and then diligently fix bugs, but as we have seen with the still-in-beta Visual Editor, well-described bugs that damage wikitext and cause headaches for gnomes are not being addressed (e.g. three-year-old {{phab|T162291}}; there are plenty more of those). Developers have moved on to the next shiny thing. – Jonesey95 (talk) 21:24, 28 October 2020 (UTC)
• Oppose, as the benefits of Discussion Tools clearly outweigh the issues. The upside is large: editors not familiar with markup will be better able to participate in talk page discussions, a critical part of editing. The bugs are, as the discussion below documents, rare. I have been using the 2017 wikitext editor, which also uses Parsoid, for a couple years now, in mainspace and on discussion pages, and have never run into a Parsoid parsing bug. "Just go back and re-architecture the entire project when it's already nearly complete to prevent some occasional bugs" isn't a reasonable demand to make. Vahurzpu (talk) 00:08, 29 October 2020 (UTC)
• : {{ec}} The 2017 wikitext editor does not use Parsoid in the way that DiscussionTools does. Making an edit to an un-Parsoid-parsable page using the 2017 wikitext editor does not make any changes to the wikitext other than those you typed in, whereas replying to a comment on such a page does. * Pppery * _{it has begun...} 02:00, 29 October 2020 (UTC)
• Support Alsee's proposal: alter the design to avoid round-trip-translation. "Something must be done. This is something. Therefore this must be done." --Guy Macon (talk) 01:41, 29 October 2020 (UTC)
• Question: Is there some way I can cut and paste the Wikitext from some random page, send it through the dual conversion, and see the result? I would ask that the result show up in some sort of sandbox with no ability to save, not in the edit window where a single click might publish the undead thing. --Guy Macon (talk) 01:41, 29 October 2020 (UTC)
• :@Guy Macon, mw:Parsoid/Round-trip testing has information on how to do that. In this particular context, you could also just use the Reply tool for a while (e.g., in a Sandbox page) and see what happens, or look at https://dtcheck.toolforge.org/dtstats.html and see what's actually happened during the last ~16,500 real-world uses. Whatamidoing (WMF) (talk) 06:47, 29 October 2020 (UTC)
• :{{u|Guy Macon}}, User:Enterprisey/parsoid-round-trip, hot off the press. Enterprisey (talk!) 07:16, 29 October 2020 (UTC)
• Oppose. I'm not thrilled with Parsoid, and I'm particularly not thrilled with HTML/RDFa. As a practical matter, however, both are here to stay. They are part of the core wikimedia architecture that exists today. Likewise, the model of "convert wikitext to HTML/RDFa, manipulate it in that domain, then convert back to wikitext" is not going away; it's part and parcel of the whole Parsoid architecture. To demand that tools be designed to avoid the round-trip translation is tilting at windmills.

:Wikitext is a disaster. I'm not sure if it has a formal grammar, but if it does, it's absurd, allowing constructs which make no sense to anybody who has ever tried to write a parser. So we've got multiple parsers, each of which is broken in a different way. And, with wikitext being hand-generated, it's bound to be written badly. There's tons of unparsable wikitext in the wild right now. If it gets mutated during a round-trip, well, garbarge-in, garbage-out. The more we get away from hand-written wikitext, the better off we are. If there's some bumps in the road, that's the price we have to pay. Parsoid is a line in the sand. It may have bugs, but there's one place they need to get fixed. And HTML/RDFa, despite its problems (I'll be happy to rant about that in another forum), is at least a fixed target with a real grammar against which to write tools. — Preceding unsigned comment added by RoySmith (talk • contribs) 01:55, 29 October 2020 (UTC)

• :{{ping|RoySmith}} Actually, Parsoid has a PEG tokenizer based on several thousand parsing IO tests (I want to say on the order of 10-20k). See :mw:Parsoid/Internals#Architecture. --Izno (talk) 03:24, 29 October 2020 (UTC)
• ::{{u|Izno}}, That may be true. But surely any grammar that allows:
• ::
• ::This is italic and also bold and now just bold.
• ::
• ::is just farshtunken. -- RoySmith (talk) 21:46, 29 October 2020 (UTC)
• ::: I didn't claim that the grammar was sane. :) --Izno (talk) 23:34, 29 October 2020 (UTC)
• {{ec}} I would prefer using the edit filter to block edits made using DiscussionTools which corrupt the wikitext, but the edit filter isn't currently given enough information to tell whether an edit is made using DiscussionTools, and this proposal does present a serious problem, so I have to support the current suggestion as an interim measure. * Pppery * _{it has begun...} 02:00, 29 October 2020 (UTC)
• :@Pppery, I hope you'll try out the Reply tool yourself. In the meantime, here are all of the dirty diffs at enwiki from the last seven days: [https://en.wikipedia.org/?diff=985597349] and [https://en.wikipedia.org/?diff=985811612]. They remove a single stray space from the end of a line (spaces that do not show when you are reading the page, because the old PHP parser drops them). There have been some serious bugs in the past (e.g., [https://sv.wikipedia.org/w/index.php?title=Wikipedia:Bybrunnen&diff=prev&oldid=48094324 this bug], which was fixed months ago), but I would classify removing a stray space as a minor problem. Whatamidoing (WMF) (talk) 06:32, 29 October 2020 (UTC)
• Oppose The benefit of Discussion Tools is that more casual editors will be able to engage in talk page discussions by breaking down technical barriers for new participants. The harm is that bad wikitext continues to be bad wikitext. If you want a different parser, write a different parser, but I'm not going to support keeping our talk pages inaccessible just because Special:LintErrors exists. — Wug·a·po·des​ 02:26, 29 October 2020 (UTC)
• :{{A note|Developer note}} FYI there are far more barriers that just writing a different parser - buy in from the WMF for one, but more importantly any existing quirk in wikitext would either need to be kept, which hinders how "different" the other parser would be, or removed, which would require consensus (devs, community, or both?) and effort to both decide, clean up existing uses that would be broken, etc. A different parser would only compound the issues of the differences between the current parser used to render everything and the parser Parsoid uses. DannyS712 (talk) 02:38, 29 October 2020 (UTC)
• ::I was suspicious that a new parser would be a miracle solution, so thanks for clarifying the design considerations. As an aside, this is my first time using the reply button (thanks for the link @Whatamidoing (WMF)), and seeing it with my own eyes just convinces me more that this would be a boon for editor recruitment and engagement. — Wug·a·po·des​ 02:53, 29 October 2020 (UTC)
• :::@Wugapodes, thanks for the ping. The three Wikipedias that tested it and then asked for it to be turned on by default (and the Editing team actually agreed to so far; there are a couple of requests pending but not approved yet) are all working with the Growth team on newcomer retention. However, the initial analytics results aren't back yet, and this probably requires an A/B test (planned for November or December), so I can't tell you whether it's actually having the effect you (and I) expect. Whatamidoing (WMF) (talk) 06:04, 29 October 2020 (UTC)
• Oppose this feels like nitpicking over edge cases. I'm using the tool right now (per instructions of Whatamidoing below in js file), I think it's quite neat. I haven't ran into any issues so far, and it feels like a good tool. This whole "enwiki doesn't subscribe to anything new developed" is a bit meh. And if there are bugs, it'll be like any other software with bugs, and I'm sure they'll fix it. Also + Roy above and Izno below. ProcrastinatingReader (talk) 10:22, 29 October 2020 (UTC)
• Having used this for almost a week now, I'm even more strongly opposed to this. I think this is a well built tool that will facilitate better talk page discussions. This should go live as planned. Reply-link is great, but it wasn't enabled by default and every now and then there's errors on trying to reply; this tool I haven't had such an error with yet. I have not seen any problematic replies in my usage. Very rare, exceptional GIGO cases are totally not a good reason to hold this. This seems stable for production usage, and it seems like it's been thoroughly tested for edge cases, which is reassuring to me as well. Large benefits here which outweigh any small 'errors', and we've got few common usage (ie not-(stress)test) examples of errors here. ProcrastinatingReader (talk) 19:09, 4 November 2020 (UTC)
• Oppose per the data below provided by {{u|PPelberg (WMF)}}. A 1% error rate that is still being examined is, I have to say even looking at this page, a lower error rate than is generated by editors in normal editing. I'm guessing as I continue to use the tool I will find more issues but knowing that the "bad code" problems highlighted here are being tracked, and are at such a low rate, is enough to reassure me. Best, Barkeep49 (talk) 01:09, 30 October 2020 (UTC)
• Support per Jonesey95 above and [https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(WMF)&diff=986283444&oldid=986279795 below]. Post-release it’s too easy to focus on the next project and not fix the issues here. Cavalryman (talk) 19:58, 1 November 2020 (UTC).
• Oppose: Properly participating in Wikipedia discussions currently requires learning a strange syntax; the new tool improves accessibility for those deterred by this first hurdle. This especially includes users who already constructively participate using VisualEditor, which is unavailable on talk pages. Making it easier for users to discuss conflicts will probably reduce the amount of unnecessary edit wars and the amount of "discussions" occurring in edit summaries of reverts instead of talk pages. No software will ever be free of bugs, and rejecting the tool for the rare occurrence of fixable bugs would be a mistake. ~ ToBeFree (talk) 21:31, 1 November 2020 (UTC)
• Oppose - While the new discussion tools aren't perfect, they seem to be a substantial improvement in the user experience, even for seasoned editors. The few parsing inconsistencies that exist would be rare edge cases for talk page discussions. Kaldari (talk) 17:09, 4 November 2020 (UTC)

• {{re|Alsee}}, do you have a diff where developers have indicated they're not going to fix this issue? Like you I'm in favor of the goals of this project. I would love for the enwiki community to be able to work collaboratively with the foundation rather than in an us vs them manner. That might not be possible but I worry that the outcome of RfC being successful will be that the foundation writes of enwiki in terms of how it develops this and so we miss out on the value altogether. Frwiki is hardly a small wiki; has there been community discussion about the relative benefits to current drawbacks of the implementation there? Best, Barkeep49 (talk) 21:56, 28 October 2020 (UTC)
• :@Barkeep49, I think the answer to your question would depend upon what you call "this issue". I'm not so sure about these claims.
• :* In Alsee's first diff, Parsoid automagically resolved a stripped tag error on a talk page about six weeks ago. Resolving Special:LintErrors is generally considered a good thing to do. Moving the blank line around the hidden HTML comment is less desirable, and I believe there's a bug report for this (it might be in the list that will get resolved this WP:THURSDAY).
• :* In the second diff, my teammate and I were testing a bug report from Alsee at the mw:Beta Cluster testing site back in February. This was early-stage testing, months before the tool was offered as a Beta Feature to any community. This page was corrupted when a wikitext table had all of its formatting syntax with ::: inserted in front of it. (Wikitext tables require the table formatting codes, such as |-, to be the first characters on the line.) Broken wikitext is expected to produce broken pages, especially when we're talking about super-early stages of software. To make it harder to create this problem accidentally, the Reply tool hasn't let editors insert tables or templates for months now, unless you put the wikitext in yourself. A longer-term solution requires a significant technical change to wikitext, which may be discussed in the coming months.
• :* In the third diff, Alsee ran a test with this content: {#if:x|This should be red 2.. I have seen Alsee post this string as a deliberate 'stress test' several times on at least three wikis now, but I've never seen an editor type anything like that in a real comment. There's a bug report for this in Phab, and I understand that it's priority is set to reflect its rarity.
• :These diffs are not representative of the everyday experience of using the Reply tool. If you'd like to see real-world diffs, you can check [https://en.wikipedia.org/w/index.php?hidebots=1&hidecategorization=1&hideWikibase=1&tagfilter=discussiontools-reply&limit=250&days=7&title=Special:RecentChanges&urlversion=2 RecentChanges here at enwiki].
• :You can also look at [https://dtcheck.toolforge.org/dtstats.html this table of diffs by wiki], if you want a quick way to find diffs that are more likely to be broken in some way. The problem rate is low and falling. Most days, about one out of 150 Reply comments have a whitespace change, and another 1 in 150 have a non-whitespace change. (Fun fact: Parsoid isn't the only software that causes 'dirty diffs' on talk pages. WP:WikEd does, too.)
• :If you're interested in why both the Reply tool and User:Enterprisey/reply-link.js are using Parsoid to place comments, then I can tell you more about that, but I think you might be better off trying out the Reply tool for yourself. Unless someone deliberately corrupts this page, then you can try it out right here. Click on https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(WMF)&dtenable=1 and look for the little [reply] links at the end of each signature. I recommend clicking over to the "Visual" section and using the toolbar to ping me or to add a link to your reply. Imagine a world in which you never have to remember how to spell or correctly capitalize editors' usernames. :-D Whatamidoing (WMF) (talk) 22:17, 28 October 2020 (UTC)
• ::Although I'll give you a hint now: @Izno replied while I was typing, and I didn't have to deal with the edit conflict that would have triggered in any of the regular wikitext editors. Whatamidoing (WMF) (talk) 22:19, 28 October 2020 (UTC)
• :::{{u|Whatamidoing (WMF)}}, I'm not sure how much of your reply is really meant for me and how much is a "I'm going to reply to this comment so I can say everything I want to." Going off the idea that it's at least actually partially directed at me, I have tried the tool. I found it impressive at the early stage I tried it and I found the foundation responsive to the concerns I did raise - more responsive than I'd have actually expected. This is partly why I asked Alsee the questions that I did; I wanted to make sure I wasn't missing something/ Best, Barkeep49 (talk) 22:40, 28 October 2020 (UTC)
• ::::@Barkeep49, if you copy the first happy lines from m:User:Whatamidoing_(WMF)/global.js ([https://meta.wikimedia.org/w/index.php?title=User:Whatamidoing_(WMF)/global.js&diff=20189786&oldid=20032761 this diff]), then you can use it all the time. I haven't tried out Enterprisey's reply-links myself, but it's obviously popular, especially with the improvements he made a few months ago. Maybe someday you can tell me how the two compare. Whatamidoing (WMF) (talk) 22:51, 28 October 2020 (UTC)
• :::::{{U|Whatamidoing (WMF)}}, thanks for the links to these diagnostic tools. Do similar tools exist for VE while it is still (I hope) being debugged? [https://fr.wikipedia.org/?diff=175713003 Here is an example of a broken edit] from this tool. I don't know the rules on fr.WP, so I don't know if this was technically a GIGO edit, but it looks like an editor unwittingly altered the formatting of another editor's comment in a significant way, which is usually unacceptable. Given the small scale on which this tool is currently deployed, and based on my experience with stale VE bugs, I worry that multiplying the frequency of this sort of edit by 100 or 1,000 will lead to a lot of problems that developers will dump on gnomes to fix after they have moved on to something more fun than fixing tricky bugs. – Jonesey95 (talk) 02:53, 29 October 2020 (UTC)
• ::::::@Jonesey95, what do you mean by "significant way"? It stripped out a line containing only colons between two comments by the same editor. That editor wrote a comment with four colons, then added a blank line with three colons, and then wrote another comment with four colons immediately afterwards. Under our rules about WP:LISTGAPs, any editor would have been justified in removing those stray colons manually.
• ::::::The Editing team is working with the Parsing team to reduce the "dirty diffs". The current rate is low and falling. I encourage you to try it out and see what you think about it yourself. Whatamidoing (WMF) (talk) 06:16, 29 October 2020 (UTC)
• ::{{re|Whatamidoing (WMF)}} I was not going to bother mentioning this experience, but having seen the conversation here I did want to weigh in as someone who actually has used Discussion Tools before on Meta recently.
  First, I find the extension very convenient to use and rather nifty, too. However, I did have some weird bugs that occurred during the global RFC I had drafted (m:Special:Diff/20666993 & m:Special:Diff/20688139). I see why the first diff happened given my initial error with {{tag|h2|o}} vs {{tag|h3|c}} (though I don't think it gave the intended result there). It is not clear why the second one happened. I get that my RFC used some advanced formatting and stuff, but it made me feel bad to see I accidentally broke the tool (and/or the tool broke my RFC).
  Finally, I get that what {{u|Alsee}} had written was likely just a stress test, but I regularly use the {{Magic word|gender}} magic word and would hope its usage is properly in the tool. –MJL ‐Talk‐^☖ 05:18, 27 November 2020 (UTC)
• :::The second change happened because you had a copy of Template:Div col end without any Template:Div col begin to balance it.
• :::Right now, you can't insert templates in the visual mode, but there's no fundamental reason why template such as Template:Gender couldn't work. Whatamidoing (WMF) (talk) 21:39, 27 November 2020 (UTC)
• :Barkeep49, you asked if there's a {{tq|diff where developers have indicated they're not going to fix this issue}}. I think this link will do: [https://phabricator.wikimedia.org/T263709#6503764 Phab post by the project manager]. Context: The manager is discussing just one of the symptom cases (the tables example). He states they aren't even going to try to fix that case. Their "fix" to avoid corrupting the page (for that particular problem case) is to detect that case and then fully break the REPLY button. The REPLY button won't corrupt the page if the button refuses to let the user post any reply at all. I reported this issue directly to the manager seven months ago. That post from him is exactly one month ago. If they're not fixing that specific case, they clearly don't intend to fix the underlying cause. Alsee (talk) 23:10, 29 October 2020 (UTC)
• As [https://www.mediawiki.org/w/index.php?title=Topic:Vbp5bbixpqsqtv3s&topic_showPostId=vbpr2uo6fwhwf2mh#flow-post-vbpr2uo6fwhwf2mh I've said at least once], this proposal is DOA. The technology stack powering DiscussionTools is coming whether you want it or not. I would invite other editors to read through that thread and the other forked thread that Alsee disruptively started {{em|twice}} to try to kill the implementation, as well as the responses from just about everyone else (to wit, the developers have worked issues identified where it is the tool that is at fault and asked for further {{em|specific}} details; Alsee failed then to provide them, so I guess I'm happy there are 3 observed questionable problems above).
• :Further, in almost all cases I've seen where round-tripping has caused an actual corruption rather than a suboptimal edit, it has been the fault of frankly bad wikitext. --Izno (talk) 22:06, 28 October 2020 (UTC)
• This seems out of our scope. Software back-end is the domain of the MediaWiki.org community, and WMF-wide configuration policies are set on Meta. The most we can do is decided whether to enable or not enable Discussion Tools on EnWiki. — Wug·a·po·des​ 02:14, 29 October 2020 (UTC)
• :If you all decide that you'd like to test this as an opt-in-only Beta Feature, then I can make the request for you. I do not know what the response would be. Whatamidoing (WMF) (talk) 06:42, 29 October 2020 (UTC)
• :: I think it would be useful. For an opt-in beta feature, I do not think we need a formal RfC or anything similar.--Ymblanter (talk) 07:32, 29 October 2020 (UTC)
• :::I for one would prefer going ahead with the current rollout scheme across all wikis unless there is consensus to do something different. It seems enwiki is excluded in phase 3 in {{phab|T266303}}; what phab task is tracking the deploy to enwiki? Is it roughly known when will it be deployed, and will it be a beta feature at that point or is it enabled-for-all, under the current plans? Unrelated, it seems sometimes the "Reply" button sends me to the top of the page rather than to the comment I've just posted (I have to scroll back down manually). ProcrastinatingReader (talk) 12:12, 29 October 2020 (UTC)
• I've only tried in one niche discussion, but is this tool able to distinguish between * and :? eg in Special:Diff/986048398 it added a : when most of the replies were bullets (it also added a space). This was when I was responding to the main comment, btw. Side feature request: to add a reply to this section I have to edit source. Not sure if it's easily possible, but in the long run maybe some kind of "Add reply" functionality when replying to a section/main discussion rather than an individual user? It may be more difficult to achieve, if at all, I know. ProcrastinatingReader (talk) 14:02, 29 October 2020 (UTC)
• :It does know about list types, but it uses that only for when you're replying to something that's already in a list. I.e. it'll sensibly reply to an * comment with * and a : comment with :. When you're just replying to a top-level section (which isn't in any sort of list), it'll default to :. I took a look at the replies where you were, and they're already super-mixed -- in the HTML output there's 5 dl and 4 ul lists, so it's a bit of a mess, and one could argue that even if it was trying to guess based on overall usage it'd have landed on : for that reply.
• :The reply links trigger off of finding a block of text with a signature, which is why replying to this section-as-a-whole isn't present. I do agree it'd be helpful if it better supported non-described sections, even if they're less common... DLynch (WMF) (talk) 17:19, 29 October 2020 (UTC)
• ::Oops, sorry, I gave outdated information. We matched the list type up until about a month ago, when we started replying to everything with :. We decided that we’re still evaluating how best to choose which indentation type should be used for replies... so having a half-done selective approach in place was probably worse than a consistent one while we’re thinking about it.DLynch (WMF) (talk) 19:20, 29 October 2020 (UTC)
• :::@DLynch (WMF) thanks for this. That's fine, was just curious. BTW, the preview on "Source" actually shows bullets. Every new line is an additional bullet. I actually kinda liked that, but that's not how it saves, so it feels a bit misleading to show it in preview. But otherwise, great work on this reply stuff to all devs/others involved! It's quite cool! Hopefully it encourages talk page participation even more. ProcrastinatingReader (talk) 19:03, 4 November 2020 (UTC)
• ::::Oh hey, thanks for pointing that out! We hadn't noticed the preview issue -- it's a side-effect of forgetting to remove the list-type inference there when we did everything else. A fix for that has been committed and will work its way out in the next deploy cycle. DLynch (WMF) (talk) 16:34, 5 November 2020 (UTC)
• As you all consider this, I thought it would be helpful to do two things:
• : 1. Share how the Editing Team is thinking about and addressing the risk that edits made with the DiscussionTools make changes to talk pages other than adding content.
• : 2. Address the statements and diffs in the original post.

: What follows isn't exactly "bite-sized." Tho, I thought thoroughness would be worthwhile in this context. If anything here prompts new thoughts or questions, please let us know...

• : 1. The potential for DiscussionTools to impact other parts of the page.
• :* The core of this proposal is the need for edits made with DiscussionTools to not affect talk pages beyond adding the content people are posting with it. We relate to this proposal in so far as we, too, see it as a requirement that edits made with DiscussionTools should not impact other parts of talk pages, especially in ways that make them more difficult to edit and understand.
• :* As Whatamidoing (WMF) mentioned above, to help us all ensure the tool is working in ways we expect, we've created a way to detect when edits made with DiscussionTools do anything beyond adding new content to talk pages. You can play around with it here: https://dtcheck.toolforge.org/dtstats.html.
• ::* To date, the tool has analyzed over 16,500 comments.
• ::* In the past 5 days, an average of ~1.30% of comments do something other than add new content to talk pages. In the past 30 days, an average of ~1.20% of edits made with the Reply Tool have changed other parts of the talk page in some way.
• ::* Note: The most common change we see is space characters being removed at the beginning or end of comments. We're working to eliminate these as well.
• :* Since we started tracking this kind of edits on 3-September, we've seen the 5-day average "dirty diff rate" fall 83%, from ~6% → ~1%.
• : 2. Statements made in proposal
• :: {{tq|Discussion Tools round-trip double-translation causes content corruption to the existing page}}
• ::: In principle, this statement is true: edits made with the Reply Tool have changed other parts of the page. Although, evidence suggests (see: https://dtcheck.toolforge.org/), the incident rate of these "changes" is falling, and we now have a mechanism to proactively detect when these changes occur.
• :: {{tq|The problem wouldn't exist if they didn't use round-trip-translation}}
• ::: Some context as to why we have been using Parsoid to save comments made with Discussion Tools: "[Parsoid] makes it possible for the software to work out the structure of the page and thus more reliably insert replies in the correct position on the page. Secondarily, by sending talk page content through Parsoid, it enables the reply tool to work on transcluded pages." More context here: https://w.wiki/jGS.
• :: {{tq|...examples demonstrating Discussion Tools content corruption}}
• ::: [https://fr.wikipedia.org/w/index.php?oldid=174398363&diff=prev&diffmode=source Example 1] (fr.wiki)
• :::* This is an issue we're tracking and talking about a fix for. You can track the progress on this work on Phabricator here: T262448.
• ::::* Note: Matma Rex shared some helpful context about the impact and cause of this category of issues in T262448#6499606, "Many of the diffs we're seeing look really bad because they remove closing tags that actually seem to be matched to an opening tag at a glance, and are only unmatched because of incorrect nesting resulting in the relevant node being implicitly closed earlier."
• ::: [https://en.wikipedia.beta.wmflabs.org/w/index.php?title=User_talk:Whatamidoing_(WMF)&diff=414991&oldid=414990 Example 2.1] & [https://meta.wikimedia.org/w/index.php?title=User_talk:Alsee&diff=next&oldid=20438644&diffmode=source Example 2.2]
• :::* The above seem to be cases where an edit is made with the Reply Tool on a page that contains broken/incomplete table syntax. As of April 2020, the tool is disabled on most affected pages (T246481). We think this protection might not have worked as expected in this case because of the speed with which these edits were made. See: T263709#6502328.
• :::* As shown in the second example, it’s still possible to intentionally avoid that workaround, e.g. by opening the reply tool in one browser tab, and then adding the broken syntax to the page in another; or posting multiple comments very quickly. Fixing this is possible, but would cause posting replies using the tool to be slower in the common case where the page isn’t affected by this bug. We investigated this issue back in September and decided it would be safe to not fix this considering, what we see as, the low likelihood of this occurring in "real" usage (T263709#6503764).
• :::* Long-term, the solution to this problem requires extending wikitext, so that corrupted syntax can be isolated from the rest of the page. We are planning a technical RFC to do this. You can track the progress on this work in Phabricator here: T230683.
• ::: [https://meta.wikimedia.org/w/index.php?title=User_talk:Alsee&diff=next&oldid=20438542&diffmode=source Example 3]
• :::* This seems to be similar to the issue we talked about earlier this year.[https://www.mediawiki.org/w/index.php?title=Topic:Vcwvt3bq03o5gv8h&topic_showPostId=vf2qsuu6npon0blb#flow-post-vf2qsuu6npon0blb Topic:Vcwvt3bq03o5gv8h]
• :::* As a result of that interaction, the Editing Team decided not to address this issue considering:
• ::::* There are Parsoid-compatible ways of achieving the same intended effect.
• ::::* We are not currently aware of any instances where the syntax you are using here has been used on live talk pages.
• :::* Technically, this is the same issue as T262448 (unmatched closing tag), and may get resolved along with that.
• :: {{tq|There are likely hundreds, if not thousands of different examples that trigger content corruption.}}
• :::* As noted above, to date, the tool has analyzed over 16,500 comments. Over the past 30 days, ~1.20% of edits made with the Reply Tool have changed other parts of the talk page in some way.
• :::* We'd value you having a look at the kinds of changes contained in this "~1.20%" metric by inspecting the diffs we're tracking. If you see diffs that you think involve serious problems, please let us know here, in Phabricator or by commenting on the tool's talk page at mw.org: Talk:Talk pages project/replying. Here is a link to the tool you can use to review all edits made with the Reply Tool: https://dtcheck.toolforge.org/dtstats.html. PPelberg (WMF) (talk) 00:53, 30 October 2020 (UTC)
• :Thanks @PPelberg (WMF), this is helpful context. I'll just note that one kind of "reply" I can't do yet (as I've installed the tool per @Whatamidoing (WMF)'s invitation above) is I cannot participate in the response part of the RfC. Is that in scope for this project? Best, Barkeep49 (talk) 01:07, 30 October 2020 (UTC)
• ::{{tq|I'll just note that one kind of "reply" I can't do yet...}}
• ::To make sure, we're on the same page, in stating the above are you referring to being able to use the Reply Tool, or something like it, to submit a vote (e.g. Support or Oppose) in the ===Discussion Tools RFC responses=== section?
• ::If yes, then this is a use case we've started to think about (see: phab:T259865); I've also added the use case I think you are highlighting here to the task's description (see: phab:T259865#6590520).
• ::{{{tq|Is that in scope for this project?}}
• ::I think the safest answer would be to say "no" in so far we do not yet have specific date in mind for when we will work on supporting this use case. This is not to say we do not think it's important or we won't end up getting to it.
• ::Rather, we think getting the "communication primitives" (e.g. responding on discussion-style conversations and adding new topics) to a place where people who are newer to the wikis can communicate with others instinctively and ways that comply with community conventions should take precedent. You can see a bit about how we're thinking about the project in this update: Talk_pages_project/Updates#4_Sep_2020.
• ::{{tq|...this is helpful context}}
• ::Oh good. If any other questions come up, please do let me or anyone else know. We're striving to make the work around this project as legible as possible. PPelberg (WMF) (talk) 02:00, 30 October 2020 (UTC)
• :::PPelberg (WMF) I remain mystified at your apparently intense desire to not fix it. If you inserted the new comment into the original page content, all of these problems would be solved in a single stroke. Instead you're expending work chasing after a variety of symptoms, in some cases you're "fixing" it by fully breaking the reply button so the user can't reply at all,[https://phabricator.wikimedia.org/T246481] you are going to have to chase after all of the new cases that crop up, and then you're leaving us screwed after your immediate project wraps up. Even if you manage to fix today's list of examples, tomorrow's corruption cases are never going to be fixed. We're supposed to file phab tasks on them, and these kind of tasks just vanish into the infinite-backlog on phab after the immediate project closes. Alsee (talk) 06:13, 30 October 2020 (UTC)
• :::PPelberg (WMF) I just found that DiscussionTools blanked an entire comment in a completely different section![https://ko.wikipedia.org/?diff=27504320] How is that not a screaming showstopper?!?!? Alsee (talk) 07:46, 30 October 2020 (UTC)
• ::::{{tq|I just found that DiscussionTools blanked an entire comment in a completely different section.}}
• ::::[https://ko.wikipedia.org/?diff=27504320 This diff] was unsettling to us as well – thank you for linking to it, @Alsee. We investigated this diff when we noticed it ~2 months ago.
• ::::The result of that investigation: the bug that caused this concerning edit was not caused by DiscussionTools, but rather by MediaWiki failing to handle edit conflicts when the replica databases were out of sync. This blanking would've happened regardless of what editing interface/tool someone used.
• ::::So folks are aware: we fixed the underlying issue that caused [https://ko.wikipedia.org/?diff=27504320 this problematic diff] in T261715.
• ::::Note: you'll see the problematic diff happened on 6-September-2020 and the patch to resolve it was committed on 1-September-2020. The reason that patch did not prevent this particular issue is because the patch landed on ko.wiki (a Group 2 wiki) on Thursday, 10-September, four days after the edit happened. PPelberg (WMF) (talk) 15:33, 30 October 2020 (UTC)
• :::@PPelberg (WMF) that is the context I was talking about. Thanks and best, Barkeep49 (talk) 14:47, 30 October 2020 (UTC)
• ::::Roger that, okay. Thank you for confirming, @Barkeep49. PPelberg (WMF) (talk) 15:35, 30 October 2020 (UTC)
• :::::PPelberg (WMF) I have stuck that one from the example list. With that one out of the way, could I get a response to my comment (06:13 , 30 October)? There's now something like a dozen known independent cases where DiscussionTools will randomly corrupt the existing page (not all included in my example list). Those cases will randomly be serious or "minor". New ones are found week after week, month after month, and will continue year after year. Alsee (talk) 19:30, 30 October 2020 (UTC)
• ::::::{{tq|...could I get a response to my comment (06:13 , 30 October)?}}
• ::::::For sure. Although, can you please point me to the specific point within [https://w.wiki/jYW the comment] you posted that you'd value a response to? I'd been thinking I'd responded to that post, tho, you may be seeing something I'm not. PPelberg (WMF) (talk) 01:03, 31 October 2020 (UTC)
• :::::::PPelberg (WMF) sorry for the delayed response. I'm disappointed that I find not a single word from you responding to anything in my earlier comment,[https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(WMF)&type=revision&diff=986168791&oldid=986144724&diffmode=source] and I'm confused that you think you did respond. My later comment about the blanked-comment turned out to be completely unrelated to DiscussionTools, and your response on that was also completely unrelated to Discussion Tools. If we strike that pair of off-topic comments, there's no response my earlier comment.
  Moving on, the RFC response is currently barely over half basically saying that DiscussionTools is better than nothing, regardless of the problem. Nearly half object and want the problem fixed. Before you built the product, seven months ago, I alerted you that there was a problem and people would object. You knowingly and needlessly built a defective design. I, and others, are mystified at your apparently intense desire to not fix the problem. We want you to stop wasting precious dev hours fixing bugs that shouldn't be fixed. One of your "bugfixes" amounts to stopping an airliner from crashing into into the runway by deliberately self-destructing the plane in the air.[https://phabricator.wikimedia.org/T246481] Why oh why would you make the product even more broken instead of fixing it? We want you to fix the underlying design flaw. If you inserted the new comment into the original page content, all of these problems would be solved in a single stroke. I believe it would beneficial to the Foundation-Community relationship if you agree to fix it, and I believe it will be another perpetual irritant in the wound if you don't. Alsee (talk) 13:52, 22 November 2020 (UTC)
• {{ping|PPelberg (WMF)}}, I realise that you don't just set a "if we reach x% of edits having a bug, we ship", but you've impressively dropped the bug rate thus far (80% or so, I believe you said). Notwithstanding any substantial changes to the timeline, how much more time is intended in pre-(broader)-release for squashing the blighters? I'm sort of ambivalent at the moment, mainly because of the increased possibility of the tool to have errors outside of the reply itself, which are both harder to detect, more problematic, and if not detected immediately, more fiddly to fix manually. But the progress made seems positive (I am not qualified to weigh in on the pros and cons of not directly using source as the proposal advises), so I'm more on the general tool. Nosebagbear (talk) 10:26, 3 November 2020 (UTC)
• :hi @Nosebagbear – thank you for this question. A couple of comments in response below...
• :{{tq|...how much more time is intended in pre-(broader)-release for squashing the blighters?}}
• :Assuming you are referring to how much more time do I anticipate us needing before we'd consider offering the Reply Tool as an opt-in Beta Feature at en.wiki, I can share some of what we have planned before doing this:
• :* Listening for what consensus emerges in this RfC.
• :* Making the Reply Tool available as a Beta Feature at an additional ~250 wikis to ensure it continues to work in ways people expect at a broad range of wikis. See phab:T266303.
• :* Monitoring how the latest round of backend improvements (see: Phab:T262408) impact the rate at which edits made with DiscussionTools do anything other than add new content to pages.
• :* Talking with people who have used the Reply Tool at en.wiki using the script @Whatamidoing (WMF) shared in [https://w.wiki/k7c this comment] to understand the extent to which the tool is working as expected.
• :...I appreciate you likely asked the above seeking an estimated date or number of weeks/months before the tool is offered here. Tho, considering the unknowns involved with them, it's hard to offer that at this time. Of course, when we have a better sense of time, we will make sure it is widely known.
• :{{tq|...the increased possibility of the tool to have errors outside of the reply itself, which are both harder to detect, more problematic...}}
• :Had you and I been having this conversation in August, I would've agreed with you about it being harder for us to detect, at scale, when edits made with the Reply Tool do anything other than adding new content to pages. Although, we now have a tool that enables us (you, everyone in this conversation, the Editing Team, etc.) to detect this category of errors. If you are interested in exploring this for yourself, you might check the tool's "dirty diff detection" results for yesterday, 3-Nov-2020: https://dtcheck.toolforge.org/dtcheck-2020-11-03.html.
• :Please let me know if anything here prompts new thoughts or questions. PPelberg (WMF) (talk) 17:08, 4 November 2020 (UTC)
• I think this is a bug. It's adding a new line between what it's replying to. I believe this fails enwiki's MOS:LISTGAP. ProcrastinatingReader (talk) 02:05, 5 November 2020 (UTC)
• :Nope, a new line there is fine since it is not a list being replied to. --Izno (talk) 04:02, 5 November 2020 (UTC)
• WMF devs, another thing: I was replying to a discussion and it was closed between the time I started typing and clicked submit. After doing this, the page refreshed and my entire reply was lost (it was not added as an edit). I think this behaviour is undesirable; an error should be shown or the opportunity to save ones reply. ProcrastinatingReader (talk) 20:40, 16 November 2020 (UTC)
• : A comment you have drafted being "lost" without warning does sound undesirable; thank you for saying something about this, ProcrastinatingReader. A clarifying question for you: can share in more detail what a discussion being "closed" in this context means? One thought that comes to mind: the conversation was archived. In the meantime, here is a ticket where we can define the issue at hand: phab:T268069. PPelberg (WMF) (talk) 19:52, 17 November 2020 (UTC)
• ::@ProcrastinatingReader an update for you: it looks like @Matma Rex was able to reproduce, and subsequently fix¹, the issue you experienced.
• ::---
• ::1. phab:T268069#6631447 PPelberg (WMF) (talk) 18:41, 20 November 2020 (UTC)
• :::@PPelberg (WMF) ah, sorry, I had this on my list to reproduce again and get some useful data/steps for you, but it totally slipped my mind! When I say "closed" I mean someone comes along and "closes" the discussion using eg Template:Archive top. I saw that Gerrit change and it says "This is probably because it was added inside a transclusion's HTML?" -- technically, when a discussion is closed, it "wraps around" the discussion rather than transcluding all the content, so HTML wise it'd be added inside the HTML, so that comment sounds about right.
• :::I've reproduced this with @GeneralNotability's help. Basically, see User_talk:ProcrastinatingReader#Category:Pages_using_Infobox_GB_station_with_unknown_parameters. I clicked "reply" on the latest comment, wrote up a message, then asked someone else to "Close" the discussion. The close caused Special:Diff/989736218. After they close, I click "reply". Effect: The page refreshes, and my reply is lost.
• :::I'm happy to test this again once that Gerrit commit is live on here and see if that fixes it? Just let me know when it's live. ProcrastinatingReader (talk) 19:02, 20 November 2020 (UTC)
• :::Also note, in case it helps, in this case my reply was to the very last comment (which would've been right above the {{t|abot}}), but when I initially expeerienced this bug iirc it was not the last reply, so I think this happens regardless of where the reply is in the closed discussion. Though note my memory may be faltering... ProcrastinatingReader (talk) 19:04, 20 November 2020 (UTC)
• ::::@ProcrastinatingReader this additional context and reproduction steps are a big help - thank you for writing them up. I've added this information to the task where work on this issue is being done. ''See: phab:T268069#6647101.
• ::::{{tq|I'm happy to test this again once that Gerrit commit is live on here and see if that fixes it? Just let me know when it's live.}}
• ::::You testing this again once the patch arrives at en.wiki would be great; I will ping you here when that happens. PPelberg (WMF) (talk) 00:13, 25 November 2020 (UTC)

Every piece of software has bugs. Deciding when a piece of software is ready to release is a matter of weighing the value of getting it shipped vs the severity of the known bugs (plus the risk exposure of the bugs you haven't found yet). At some point, you decide that it's good enough, and ship it. Then you have a big release party, celebrate your accomplishments, and hold your breath until the first wave of bug reports come in, hoping that none are too serious.

There's no such thing as perfect. If your release criteria is that you've eliminated every bug, "both known and as-yet-unknown cases", you'll never ship. And then the value of the software is zero.

Where that balance falls depends on what you're writing. If your program's job is to detect that a 737 is about to stall, the consequence of getting it wrong is that hundreds of people die. If your program's job is to insert a comment in a talk page, the consequence is that somebody has to revert the edit. So, clearly, the release criteria are different. To insist that it not be shipped because there are known bugs is absurd. -- RoySmith (talk) 21:40, 30 October 2020 (UTC)

:That's a great philosophy, but it implies that developers will be willing to fix bugs that are reported post-release. The WMF developers have a spotty track record on doing so (e.g. the three-year-old {{phab|T162291}} Visual Editor bug; there are plenty more of those, and pleny that are much older). Once bitten, twice shy. – Jonesey95 (talk) 22:07, 30 October 2020 (UTC)

::{{u|Jonesey95}}, Just like it's absurd to think software will only get released when there's zero bugs, it's absurd to think every reported bug will get fixed. There's a finite amount of developer time. Every day somebody spends working on one thing means there's something else that didn't get worked on.

::

::I'm not privy to how WMF does things internally, but typically each bug gets scored based on how bad the problem is, how much value there will be in fixing it, and an estimate of how much effort will be required to fix it. Not unlike our importance/quality scoring system for articles. Or our plethora of "article needs improvement" templates. Surely adding a {{t|Citation needed}} template to an article is tantamount to filing a bug against it. We've currently got 412,324 of those. We should stop writing new articles until we get all of those fixed, right?

::

::I see that T162291 was triaged as low priority. I gather from your comments on the phab ticket that you disagree. Such is life, people don't always agree on how bugs get prioritized, just like editors don't always agree on what edits should be made to an article. -- RoySmith (talk) 01:47, 31 October 2020 (UTC)

:::I'll just add to what Roy wrote that, assuming the data offered by PPelberg is correct (and I have zero reason to distrust it), the current error rate is for this tool is in the ballpark, if not less, than our manual error rate. Like I know I did a whole bunch of reply indenting wrong before (using :::: when I should have been using *::: for instance) and if this tool can get that correct then our fellow editors (in this case primarily those who need screen readers) benefits. Best, Barkeep49 (talk) 01:57, 31 October 2020 (UTC)

::::{{ping|Barkeep49}} One reason I have some concern is that the current set-up is generating bugs that cause issues outside of the posted reply. This has a couple of effects on your's and Roy's comments above. Issues (other than ones that completely bork the whole page) are much more likely to be missed, so the error rate can be both more substantive than the manual rate but also be harder to fix. If the tool damages a post elsewhere (say the one it's replying to, which is most likely), and the poster doesn't notice, it's quite possible several posts will come in before someone notices. As with pending changes, fixing it in that circumstance becomes way more fiddly. So it's not quite an "apples to apples" consideration Nosebagbear (talk) 10:20, 3 November 2020 (UTC)

:::::What kind of error impacts how I feel about it happening. Erasing other's comments is a big concern if it's happening 1% of the time. Some of the other errors shown don't really bother me if it's at a 1% rate. But correctly writing syntax that would otherwise have had errors if be made by a human edit is the dog that doesn't bark and it's why I mention it. And some of those human made errors, as in my example of using :::: when it should have been *::: are likely never fixed. So I am just as concerned about the errors this tool fixes as the errors it introduces. Best, Barkeep49 (talk) 16:48, 3 November 2020 (UTC)

::::::Indeed, by the end of the work, I and others will not need to fix WP:LISTGAP issues on talk pages. --Izno (talk) 17:10, 3 November 2020 (UTC)

:RoySmith I don't think your comment resembles the current issue. I am not asking them to fix multiple bugs. In fact I want them to stop wasting time and resources fixing these bugs. Insert the new comment into the page source and the number of translation-corruption bugs becomes zero. Fix the design and the time spent hunting and fixing this class of bugs becomes zero. Alsee (talk) 07:42, 31 October 2020 (UTC)

::{{ping|Alsee|RoySmith}} This right here is the correct solution, and would solve almost every issue I currently have with this system. IIRC, this is what reply-link (which I'm writing this comment with) already does, and it works fine in 99% of cases. In that remaining 1%, it instead errors out and fails to post instead of corrupting the rest of the talk page. Someone will probably say "but making new editors have to go into wikitext mode if there's a problem is Bad™" but that's simply the only option available. Community consensus after Flow imploded was that any further attempts to build new discussion features must be done exclusively as an extension to wikitext talk pages and integrate seamlessly. Unless the WMF somehow gets consensus to throw out wikitext entirely (yeah, that's not happening), new discussion features must not break things for editors using plain wikitext exclusively. Internally to the WMF, this should be looked at the same way Linus Torvalds looks at the "kernel updates must never break userspace software" policy, i.e. an immutable rule that can never be broken under any circumstances (with the sole possible exception of extremely critical security fixes).

::

::Luckily, the WMF's developers have an extremely simple solution to this issue: don't commit back any of the wikitext that was pulled from the page. Visual Editor doesn't really have a choice here, but Discussion Tools does. Pull the wikitext and run it through the parser for previews if you want to, but only actually convert back and commit the added wikitext from the new reply. Congratulations, you've just fixed every single potential issue with this system in one fell swoop. In any event, per WP:TPO this should really be the only acceptable course of action. Automated tools should never be allowed to touch existing comments (beyond archiving, of course, but even then that's moving full sections to a different page without modifying the wikitext contained within) without strong consensus that it's a good and necessary decision that won't break anything. Nathan2055^{talk - contribs} 04:13, 5 November 2020 (UTC)

:::Nathan2055 it's of course fine if you decided to not !vote, but was that possibly an oversight? Given your comment I was a bit surprised when I didn't find you in that section. Alsee (talk) 11:53, 22 November 2020 (UTC)

{{archive bottom}}

There will be an online event [https://lists.wikimedia.org/pipermail/wikimedia-l/2020-November/095865.html] next week Tuesday organized specifically by Wikimedia UK and the Wikimedia Foundation for the English Wikipedia in relation to the strategy. More details are provided at the link. I have no relation to its organization, though I am planning to attend, but I would like to remark that this could be a chance to have some conversation and to break the usual circle WMF proposes something - Community does not care - WMF comes with a specific proposal - a shitstorm - WMF bacls down - nothing is done, problem not solved. We are now at the stage of "Community does not care", but the process is certainly going to affect us - and I hope this is a chance to think how it will affect us and what we can do about it.--Ymblanter (talk) 20:01, 10 November 2020 (UTC)

We should learn that either the recommendations are now subdivided into priorities initiatives or we can discuss priorities initiatives related to the recommendations. Either way, we can now vote "Support", "Oppose", or "Comment" on whatever priority initiative you would like to discuss. Link: :m:Strategy/Wikimedia movement/2018-20/Transition/Discuss. --George Ho (talk) 00:15, 23 November 2020 (UTC)

Just in case, here is the list (i.e. simplified versio) of initiatives: :m:Strategy/Wikimedia movement/2018-20/Transition/List of Initiatives. --George Ho (talk) 03:30, 23 November 2020 (UTC)

After the rebranding process was delayed by the Board, they decided to create an ad-hoc committee to advise (method as yet unknown) the ad-hoc Board Committee on Branding, with reps drawn from several routes. Most of these are smaller groups that could be specifically contacted, so this is more spreading the word to the c.1000 who signed the community open letter (of which roughly 150 were, at time of signing, active on en-wiki). Current deadline for self-nominations is the 12th December has now been changed to the 31st January

"Seeking to improve the Brand Project process, we are looking for community advisors to give input from various Wikimedia movement perspectives. The goal is to re-launch the brand discussions with a clear and transparent process in March 2021, and to conclude the conversations with a decision by the end of the fiscal year (July 2021). Though we will be approaching specific groups directly asking for advisors, I am updating the general Brand page with details, so there is clarity & transparency regarding the process."

"The Brand Committee is looking for a small set of advisors who are able to engage thoughtfully on the importance of branding to the Wikimedia Movement’s 2030 goals. Advisors will be asked to reflect on more than processes: they will be asked to think about the strategic goals of the brand names and logos within the movement, and how to equitably structure decisions around them. Ideal advisors therefore have experience representing the movement to the public, as well as understand the internal needs of the movement’s work as something multidimensional and open. The number of advisors will be between 7 - 9 people, in an effort to support active participation within the committee, and to keep the process on track, to “un-pause” in March. By then we strive for a clear sense of a process with which the broader community will be able to engage. We have identified 3 main groups we would like advisors from:"

They estimate it will be between 6-9 hours/month.

The full details on submitting and so on are at [https://meta.wikimedia.org/wiki/Talk:Community_open_letter_on_renaming#Looking_for_community_advisors_to_Board_committee_on_Brand on the open letter's talk page]. In theory there should be some degree of consensus on who the two reps are - I'm not sure how that's being handled for this particular rep "source", but would encourage anyone to take a look at the talk page over the next week or so. Nosebagbear (talk) 15:04, 3 December 2020 (UTC)

:Is there a magical way to make an auto-updating total? --Guy Macon (talk) 17:41, 3 December 2020 (UTC)

:You've seen what [https://en.wikipedia.beta.wmflabs.org/wiki/Bert they are planning to do with the logo in the default desktop skin?] These people know nothing about branding. — Alexis Jazz (talk or ping me) 18:05, 3 December 2020 (UTC)

:Can't we vote on putting the rebranding project in the freezer? Also, shameless plug for the userbox: {{User:Alexis Jazz/W?F}}. — Alexis Jazz (talk or ping me) 18:26, 3 December 2020 (UTC)

The WMF has issued a public statement in support of underrepresented communities in the movement, among which LGBTIQ+ here https://meta.wikimedia.org/wiki/Community_Resilience_and_Sustainability/2020_December_Foundation_commitment_of_support_for_LGBT%2B_volunteers

--Nattes à chat (talk) 14:07, 9 December 2020 (UTC)

:It's long been overdue in my opinion. Thank you, {{u|Mdennis (WMF)|Moonriddengirl}}! –MJL ‐Talk‐^☖ 18:29, 9 December 2020 (UTC)

{{atop|A non-starter with a tendency to become a time-sink--Ymblanter (talk) 21:38, 13 December 2020 (UTC)}}

All Wikimedia projects should be CC0, not copyleft licenses. The knowledge shall be public domain and used for any purpose, and without the restriction/need to attribute license, Wikipedia and contributors. The only true free knowledge are under public domain. talk@TRANSviada 14:58, 13 December 2020 (UTC)

:

:TRANSviada, that is not going to happen. Quite aside from anything else, it would mean having to blank all {{NUMBEROFPAGES}} pages on Wikipedia and starting again from scratch (and perhaps 60 million of the 67 million images currently on Commons); unless material is already in the public domain or the authors choose to release it Wikipedia articles remain copyright to their authors, and very few people would be willing to release their contributions into the public domain (and bear in mind that most pages are the product of multiple authors, and it would only take one to object). ‑ Iridescent 15:11, 13 December 2020 (UTC)

:::{{ping|Iridescent}} It doesn't mean that; it just one solution. Another solution would be to make past contributors re-license to CC0. People are wiling to what's the default, so put CC0 as the default. Period. Why there isn't an option to release contributions on Wikipedia under CC0? See, Wikipedia aren't allowing it to happen. To start, Wikipedia should default all new contributions to CC0. talk@TRANSviada 15:19, 13 December 2020 (UTC)

::::

::::To repeat since I don't think you heard me, {{em|that is not going to happen}}. There is no way on Earth that most contributors are going to release their copyrights into the public domain—particularly with images, there are a lot of people who literally rely on Wikipedia credit for their livelihoods—and to repeat, it only takes one objector in the history of a page to block the release of that page. Even if everyone {{em|were}} happy, the logistics involved would bankrupt Wikipedia since you'd need to get the formal consent of all {{NUMBEROFUSERS}} editors in Wikipedia's entire history before it could proceed. (I'm not sure you appreciate the scale of Wikipedia. For this page alone—which is a very low-traffic page which has only existed since May—releasing it into the PD would require the explict consent of [https://xtools.wmflabs.org/articleinfo/en.wikipedia.org/Wikipedia:Village_pump_(WMF) 161 different people].) The Wikimedia Foundation is the custodian of the copyrighted material it hosts on its sites, not the owner; what you're proposing is functionally equivalent to proposing to a bank that they empty their customers' accounts and spend the money themselves. Your second proposal, of making CC0 the default, would kill Wikipedia within days, since few if any of the {{circa|3000}} regular editors who are responsible for Wikipedia's content would be willing to continue donating their time to Wikipedia if they weren't being credited, so all you'd be left with is a very poor-quality social network. ‑ Iridescent 15:36, 13 December 2020 (UTC)

::::: I sure did not heard you, but I did read your words with my eyes. Wikipedia should PD the {{em|text}}—this is the content I'm mainly proposing—since the beginning, and then default CC0 with the license release. People already spend their time on Wikidata which releases the data as CC0. The same can happen to Wikipedia. Just default it to CC0. Wait 'til AI suppress humans on researching and writing; they won't care about licensing. BTW you're supposing stuff about those 3000 editors. talk@TRANSviada 15:48, 13 December 2020 (UTC)

:::::: You are entitled to your opinion, of course, but I have to agree with {{u|Iridescent}}: not only is it not going to happen – but it {{em|should}} not happen. I'm sure you are aware how the ShareAlike part of our Creative Commons Attribution-ShareAlike license actually helps keep our content free for everyone and for any purpose, which would not be possible under CC0. Without ShareAlike, anyone can make a derivative work and just run with it giving no one any rights to the derivative portion. For instance, translating an English-language public domain encyclopedia article into Spanish and reserving all rights for the translation does not sound "true free knowledge" to me at all. – Finnusertop (talk ⋅ contribs) 16:20, 13 December 2020 (UTC)

::::::: Y'all trying to bait me with personal attacks, but I have higher standards. Just because Stallman public domained his code and then got butt-hurt they wouldn't share their improvements back doesn't means Wikipedians should be butt-hurt. This already happens. The true free data is the one which anyone can use for any purpose, inclusive to make it proprietary. talk@TRANSviada 16:30, 13 December 2020 (UTC)

::::::::There are no personal attacks here, and this has nothing to do with Stallman or anyone else being butt-hurt, but it is simply a matter of finding the best nethod to create free content that anyone can use but not copyright for themselves. Let's close this thread per the comment below as a clear nonstarter. Anyone who wants their contributions to be public domain can do so, as this is a more free (I was going to write freeer but the triple "e" seemed wrong) alternative than our standard. Phil Bridger (talk) 20:41, 13 December 2020 (UTC)

• I'm tempted to close this as a clear nonstarter that has no community will behind it, let alone enough consensus for us to need to get the WMF involved. I'll leave that to the next editor just to make it clear, but please curtail this before it spirals too long. {{u|Sdkb}} ^talk 19:55, 13 December 2020 (UTC)

{{abot}}

{{Moved from|Wikipedia:Village pump (miscellaneous)|Sdkb, 19:38, 11 December 2020 (UTC)}}

A Swiss Medium author named Lemon Gras wrote [https://lemongras.medium.com/how-this-message-for-donations-from-wikipedia-is-accidentally-threatening-ef3b1d543b08 How this Message for Donations from Wikipedia is Accidentally Threatening] with suggestions on how to improve. Could we make sure people at WMF see that article and consider it? A1415 (talk) 12:32, 7 December 2020 (UTC)

: The Lemon Gras's comments look really interesting. If only they could make their version of a message shorter than the original.... --CiaPan (talk) 14:30, 7 December 2020 (UTC)

:: They did say their version needs revising. I guess it's supposed to be a starting point for a discussion, rather than a final answer A1415 (talk) 15:46, 7 December 2020 (UTC)

:::Except I have to dispute some fairly key components. The social proof area is a fairly common issue but they all fall down in that they fail to note that WMF fundraising may have a range of issues, but it is effective. Social proof is absolutely right when it comes to imposing restrictions, but people actually like being special when it comes to being kind or doing something moral, like donating. And then, "if you can’t give but you believe in what Wikipedia is all about, we are always looking for new contributors to help.” made me furious, as it directly proposes that fiscal donations would be more important to Wikipedia than editing donations. Nosebagbear (talk) 10:30, 8 December 2020 (UTC)

::::I can see where you're coming from there, but if it was rephrased I'd actually really like the pairing of a call for contributions with the fundraising banner. Adding a link to our tutorial could be give us a huge influx of new editors. {{u|Sdkb}} ^talk 15:28, 8 December 2020 (UTC)

:Definitely an interesting read. The social proof part was something I noticed but I didn't want to second guess the marketing folks, but it's interesting someone who seems to know what they're talking about had the same thought.

:Also, is it alright if we move this to the WMF pump? {{u|Sdkb}} ^talk 15:28, 8 December 2020 (UTC)

The author has since deleted this article. Pity: I would have liked to read it. -- llywrch (talk) 21:12, 15 December 2020 (UTC)

:{{u|Llywrch}}, hmm, not sure why they deleted it and it looks like the Internet Archive missed it, but I was able to retrieve the text portion from Google cache, which is just missing the screenshots. I'm not sure how long Google will hold it for, but here's the link: http://webcache.googleusercontent.com/search?q=cache:o6wDNPZJuO4J:https://lemongras.medium.com/how-this-message-for-donations-from-wikipedia-is-accidentally-threatening-ef3b1d543b08&hl=en&gl=us&strip=1&vwsrc=0 {{u|Sdkb}} ^talk 21:32, 15 December 2020 (UTC)

:: Having read the cached version, I'm not sure why either. In terms of criticism, the piece is obvously thoughtful & pretty tame: more of a critique about how to better present their message than (the usual) criticism about the "give us $$$ or Wikipedia will die" tone or that the Foundation is raising too much money. -- llywrch (talk) 16:22, 16 December 2020 (UTC)

:::I read it too. It seems like fair comment and reasonable advice. · · · Peter Southwood ^(talk): 05:15, 17 December 2020 (UTC)

:It seems the author deleted not only that article, but their entire Medium account and all its content. I don't know why that happened, but I doubt it's to do with that specific article. A1415 (talk) 17:53, 31 December 2020 (UTC)

Please answer my following query

Who is the designated person in Wikimedia foundation who is designated as publisher and/or legally responible for content publshed on wikimedia foundation owned websites and domains ?

(Previously it was somebody called Lila Tretikov) — Preceding unsigned comment added by 2405:201:4004:705A:9961:93A2:5896:349D (talk) 08:23, 20 December 2020 (UTC)

:The Wikimedia Foundation doesn't "own" Wikipedia per se. It hosts it, and owns its domain names and trademarks. Wikipedia itself is run by volunteers and individual editors retain the legal ownership of the material they contribute. I don't believe there's such a position as an individual "designated publisher". Lila Tretikov was the WMF's executive director between 2014 and 2016. The current executive director is Katherine Maher. – Joe (talk) 10:39, 20 December 2020 (UTC)

::Actually, I learned that the designated person is Tony Sebro, Deputy General Counsel, of Wikimedia Foundation. — Preceding unsigned comment added by 2405:201:4004:705A:9961:93A2:5896:349D (talk) 12:32, 20 December 2020 (UTC)

Can users upload a non-free file locally to Wikipedia (not to the Commons) to use in discussions and then in an article.

What are the restrictions and points to watch out for. — Preceding unsigned comment added by 2405:201:4004:705A:9961:93A2:5896:349D (talk) 17:14, 21 December 2020 (UTC)

:Yes, you may upload non free files to Wikipedia, keeping in mind WP:NFCC. Particularly, they must be used in an article once uploaded, and may not be used in other places, such as talk pages. --Izno (talk) 17:54, 21 December 2020 (UTC)

:However, note that in order to upload a file locally to Wikipedia (whether a free or a non-free file), a user needs to be registered and WP:Autoconfirmed. Nsk92 (talk) 18:51, 21 December 2020 (UTC)

:If you're not autoconfirmed, you can go to Wikipedia:Files for upload to request that a file be uploaded. Vahurzpu (talk) 02:45, 22 December 2020 (UTC)

{{Atop|result=Misplaced; the appropriate venue from suggesting new projects is meta:Proposals for new projects. {{Nac}}{{u|Sdkb}} ^talk 01:07, 25 December 2020 (UTC)}}

This idea might seem really stupid… It could have been thought of before, because, let's be honest, it's hardly original. I'm just throwing it out there for the internet to judge. Maybe this project page is dedicated to submitting more developed ideas. If so, I apologise.

Wikipedia is an encyclopedia. As such, a more verbose style is generally discouraged. An enyclopedia, needless to say, has a rigid structure, which needs to be observed. Content needs to be rigidly structured, because most people don't read the article for its own sake -- they read it (or more accurately, they read the conveniently placed Google infobox) because they want to know when Charlemagne was born, not because they want a summarised version of his entire life, legacy and domestic policy.

The exception being people who want intimately familiarise themselves with Charlemagne. The sort of people who, when they're older, want to write a book called 'The Life and Times of Charlemagne'. They're probably going to use the Wikipedia article as a starting point (unless they've been tasked with doing an unimaginative middle school presentations, in which case it's probably going to be their only source). And while Wikipedia certainly is a good starting point, maybe there is room for something... more?

A collection of essays the wiki way: one essay for each viewpoint, edited collaboratively, to form a canon of the world's knowledge. Sure it might not an authoritative or definitive version, but it would be a slightly more centralised solution to a problem that is usually solved by a wide variety of blogs, explanation videos on YouTube, and longer-than-allowed Twitter threads.

A couple of possible failure modes:

• Horcruxes: Wikipedia is already prone to edit warring. It turns out that people have wildly varying opinions about how to best display certain information. This problem might intensify if you're not just editing an objective Wikipedia article on epistemology, but writing an essay on epistemology that is potentially deeply intertwined with your own world view, you might get a bit touchy when someone else decides to overturn your delicious phrasing with their own cheap talk full of meaningless tautological redundancy. If you have an opposing viewpoint, you can of course just fork the essay, or rather, write a competing one, but people are probably going to be even more invested when they're not working on a purely non-personal article designed to represent the most popular arguments on a subject, and I don't think it would be wise to have 15 different essays on Wittgenstein and skepticism. To put it more poetically, the author might invest part of his soul into the creation of the essay, so that he may live forever in his position on the correct pronunciation of the word 'Quetzalcoatl' (I don't encourage writing essays about the pronunciation of words -- I'm just making a point).
• Underrepresented viewpoints: As with Wikipedia, there would, naturally, be people who would contribute more than the average contributor. It would be safe to assume that essays reflecting on the viewpoints of these people might be better maintained, and perhaps better written, assuming that people with an extremely good grasp of the English (or any other) language are more likely to be more active on such a project.
• Wildly varying quality: Again, a problem which isn't unique to this kind of project, but might be more strongly pronounced. You can start an article on Wikipedia by giving a short summary on the topic. You probably shouldn't write a five line long essay on a subject, and call it a day. It might also be more difficult for non-native speakers like me to contribute to essays, if we can't express ourselves well enough.
• It's not an encyclopedia: There'll probably be a topic nobody cares enough to write an essay enough. Of course there'd be lots of essays on philosophy, economics, or politics. But maybe nobody's imagination is sparked by computational complexity. I don't know how this would play out in real life, so maybe it's not as bad as I make it out to be.

That would be it, essentially. Please excuse some of the more obvious (both syntactical and semantical) mistakes I've made, it's midnight here in Central Europe, and I'll go back to bed now. Merry Christmas to all, and to all a good night! Milanandreew (talk) 23:17, 24 December 2020 (UTC)

:So, Google Knol? --Izno (talk) 23:55, 24 December 2020 (UTC)

• I think it's an excellent idea, it's just not what we do on enwiki. But, I could absolutely see proposing this as a new WMF project. And as a sister project, it would be easy to have inter-wiki links, like the one just above to meta. It could share the :m:Help:Unified login system so anybody with an account here would automatically have an account on the new wiki. And, since it's its own project, it wouldn't be hobbled by our notions of WP:NPOV, etc. -- RoySmith (talk) 23:58, 24 December 2020 (UTC)
• Medium (website)? Or any other blogging platform? ProcrastinatingReader (talk) 00:36, 25 December 2020 (UTC)

{{Abot}}

File:Symbol watching blue lashes high contrast.svg You are invited to join the discussion at Wikipedia:Village pump (proposals) § Proposal to change logo for 20th anniversary. — Wug·a·po·des​ 22:46, 13 January 2021 (UTC)

I don't know of this is the right venue, but [https://wikimediafoundation.org/wikipedia20/ this link], the celebration link, leads to a page that includes [https://wikimediafoundation.org/wp-content/uploads/2021/01/wp20_datapage_promo.png] this image, which contains the copyrighted and trademarked 2018 FIFA World Cup logo. (CC) Tbhotch^™ 04:27, 15 January 2021 (UTC)

:It looks like a tiny screen shot to me. If that's not fair use, I don't know what is. – Jonesey95 (talk) 16:14, 15 January 2021 (UTC)

Read this in another language • Subscription list for this newsletter

File:Junior Contributor Reply Tool and full page edit completion rate.png

The Reply tool is available at most other Wikipedias.

• The Reply tool has been deployed as an opt-out preference to all editors at the Arabic, Czech, and Hungarian Wikipedias.
• It is also available as a Beta Feature at almost all Wikipedias except for the English, Russian, and German-language Wikipedias. If it is not available at your wiki, you can request it by following these simple instructions.

Research notes:

• As of January 2021, more than 3,500 editors have used the Reply tool to post about 70,000 comments.
• There is preliminary data from the Arabic, Czech, and Hungarian Wikipedia on the Reply tool. Junior Contributors who use the Reply tool are more likely to publish the comments that they start writing than those who use full-page wikitext editing.[https://nbviewer.jupyter.org/github/wikimedia-research/Discussion-tools-analysis-2020/blob/master/Engagement-Metrics/Reply-Tool-Workflow-Engagement-Metrics.ipynb#Reply-Tool-(Wikitext-and-VE)-vs-Full-Page-Wikitext]
• The Editing and Parsing teams have significantly reduced the number of edits that affect other parts of the page. About 0.3% of edits did this during the last month.[https://dtcheck.toolforge.org/] Some of the remaining changes are automatic corrections for Special:LintErrors.
• 30px A large A/B test will start soon.[https://phabricator.wikimedia.org/T252057] This is part of the process to offer the Reply tool to everyone. During this test, half of all editors at 24 Wikipedias (not including the English Wikipedia) will have the Reply tool automatically enabled, and half will not. Editors at those Wikipeedias can still turn it on or off for their own accounts in Special:Preferences.

File:New Discussion Tool v1.0.png prototype.]]

The new tool for starting new discussions (new sections) will join the Discussion tools in Special:Preferences#mw-prefsection-betafeatures at the end of January. You can try the tool for yourself.[https://patchdemo.wmflabs.org/wikis/3e14959a196db0f7b0c32a35c99dc0fc/w/index.php/Project:Teahouse] You can leave feedback in this thread or on the talk page.

File:White square with question mark.png

During Talk pages consultation 2019, editors said that it should be easier to know about new activity in conversations they are interested in. The Notifications project is just beginning. What would help you become aware of new comments? What's working with the current system? Which pages at your wiki should the team look at? Please post your advice at mw:Talk:Talk pages project/Notifications.

–Whatamidoing (WMF) (talk) 01:02, 23 January 2021 (UTC)

:About the discussion tool:

:

:*It is buggy. E.g. when I reload the page while I have a "reply" section open, it doesn't discard that section but keeps it open, which is not wanted with a page refresh)

:

:*Where is the preview?

:

:*Why is VE the default? VisualEditor should never be the default.

:

:*Why is the edit summary hidden in an "advanced" section? Edit summaries should be the default, not something tucked away.

:

:*I made this in "Visual" mode, and I notice that using "bullet points" in my reply (not an outlandish feature on a talk page surely?) creates the dreaded VisualEditor "nowikis". Please, no...

:That's from a first test using only the very simplest of things (nothing fancy). Are you really sure that this is Beta-ready and shouldn't be labeled "Alpha" and kept away from live environments? Fram (talk) 16:05, 26 January 2021 (UTC)

::The reload behavior could've been chosen either way, and is a matter of preference, not a bug. The preview shows up when you pick "Source"; with "Visual", a separate preview is unnecessary. Visual is the default presumably for new editors; I figure there will be a preference to set the default if one doesn't already exist. An edit summary is usually pointless for replying to a discussion; "Reply" works well enough. Bullet points seem to turn into real bullet points if you type a space after the asterisk, although I suppose writing an asterisk on a new line probably could be interpreted as starting a list. The experience otherwise seems beta-ready to me; I don't see any bugs. Enterprisey (talk!) 02:39, 27 January 2021 (UTC)

::I have been using it for over a month and would agree that it's beta ready. In terms of the edit summaries there is a default edit summary: reply. Slightly less useful than reply link's edit summary but also you can't (that I'm aware of) change reply link's edit summary but you can this discussion tool's. And once you click advanced it stays open so you can always have the edit summary a few tabs away when doing a reply (in source of course). Barkeep49 (talk) 03:20, 27 January 2021 (UTC)

:::Reply-link does have a preference for it, but you have to go to the documentation page to find it. I would agree this isn't optimal, and the normal interface should have some way to set it. Enterprisey (talk!) 03:35, 27 January 2021 (UTC)

::: {{tq|I figure there will be a preference to set the default if one doesn't already exist}} It just remembers what you used last and uses that, afaik. Majavah (talk!) 07:12, 27 January 2021 (UTC)

::::For me it still seems to have issues executing when the comment before starts with a ping template. Since that is a not inconsiderable sum, it means it doesn't work for a lot of messages. Is this just me or a known bug - I had a quick look but wasn't able to find a long list of known bugs without going to phab. Nosebagbear (talk) 10:29, 27 January 2021 (UTC)

Just saw this reported on the Wikimedia general chat Telegram channel: [https://meta.wikimedia.org/w/index.php?title=Wikimedia_Foundation_Board_noticeboard/January_2021_-_Approval_of_Bylaws_amendments_and_upcoming_call_for_feedback_about_the_selection_of_new_trustees&oldid=20991568 Wikimedia Foundation Board noticeboard/January 2021 - Approval of Bylaws amendments and upcoming call for feedback about the selection of new trustees] -- llywrch (talk) 17:38, 21 January 2021 (UTC)

:: Thanks, llywrch for posting this. You beat me to it! I look forward to talking with you all Call for feedback: Community Board seats. Best, JKoerner (WMF) (talk) 13:41, 22 January 2021 (UTC)

:Thanks for posting this. Ensuring community/affiliate majority and for it not to be Board appointed was my top priority and I'm pleased to see that this has happened even if the details of how this will work going forward still need to be worked out. Best, Barkeep49 (talk) 17:57, 21 January 2021 (UTC)

::Yeah, this seems like as close to an ideal outcome as one could have hoped for in my opinion. –MJL ‐Talk‐^☖ 19:21, 21 January 2021 (UTC)

:::{{ping|Barkeep49}} you are more optimistic than I, to me it still reads that the Board is intending on offering a range of different conditions that the Community will have to meet. Anything beyond a standard nomination process and direct vote by individual Community members should have been ruled out (legal notwithstanding). Nosebagbear (talk) 10:35, 22 January 2021 (UTC)

::::I find {{tqq|community-and-affiliate-selected}} to be satisfactory for now. It's possible I'll have concerns when the details are revealed, but this aligns my goals (community/affiliates deciding rather than the board) with the language and so I will indeed take the win. Best, Barkeep49 (talk) 16:29, 22 January 2021 (UTC)

:: I still don't understand the legal problems that prevent direct elections of the board across international boundaries. IEEE manages to do this, & have for decades. I'm sure there are other examples. -- llywrch (talk) 16:10, 22 January 2021 (UTC)

:::{{Ping|Llywrch}} Under Florida law (where the WMF is incorporated), identities of voting members of nonprofit organizations must be publicly disclosed. Changing Board elections to direct legal elections would prevent contributors that prefer to remain anonymous from participating. (I've suggested a workaround try to solve part of the problem with the current situation.) --Yair rand (talk) 10:18, 26 January 2021 (UTC)

:::: Hmm. I don't remember that issue being mentioned back in the beginning; I know the choice was not offered to us volunteers at the time. Maybe anonymity was that important to the community; maybe enough us would have accepted losing it in order to maintain control over things. (Or it could have been incorporated in another state -- the only ties the Foundation currently has with Florida is that is where it is incorporated, which can be changed, if desired.) But as it was explained to me, the problem was because of the Foundation's international character. -- llywrch (talk) 00:20, 27 January 2021 (UTC)

:There is new movement on this including the chance to participate in one of three virtual sessions about this next week. See more at [https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_of_Trustees/Call_for_feedback:_Community_Board_seats meta]. Best, Barkeep49 (talk) 15:41, 28 January 2021 (UTC)

::Please see:

::*meta:Wikimedia Foundation Board of Trustees/Call for feedback: Community Board seats

::*meta:Talk:Wikimedia Foundation Board of Trustees/Call for feedback: Community Board seats#Clarification request #1

::*meta:Talk:Wikimedia Foundation Board of Trustees/Call for feedback: Community Board seats#Clarification request #2

::--Guy Macon (talk) 20:03, 28 January 2021 (UTC)

Apparently I am unable to understand the following document:

[ https://foundation.wikimedia.org/wiki/Bylaws ] Section 3. Selection and Appointment.

(For some reason I cannot create a link that goes directly to that section.)

• How many trustees will be selected by some sort of !vote by individual volunteers?
• How many trustees will be selected by the affiliates?
• How many trustees will be selected by the W?F?

I am trying to figure out if the following is possible under the above rules:

• The majority of the trustees are selected by affiliates
• A minority of the trustees are by the W?F
• The rest of us get zero representation.

After all. if you combine community seats and affiliate seats into one category, it could by 0% community / 100% affiliate, 100% community / 0% affiliate, or anything in between, right?

The "up to" language is also concerning. "Up to 8" could mean 1 or even 0, right?

Finally, does "sourced from candidates vetted through a Community and/or Affiliate nomination process" mean "selected by the W?F, not the affiliates or the community"?

--Guy Macon (talk) 09:32, 29 January 2021 (UTC)

: wmf:Bylaws#Section 3. Selection and Appointment. {{smiley}} — GhostInTheMachine ^{talk to me} 10:31, 29 January 2021 (UTC)

• (IV.3.C.i) says {{tq| As many as eight (8) Trustees will be sourced from candidates vetted through a Community and/or Affiliate nomination process.}} and that process is defined by the Board (IV.3.C.ii).
  So there could be no candidates chosen by the volunteer community or if there are, the Board's approvers (IV.3.C.ii) may reject them all (IV.3.C.iii) and (after an undefined time) appoint anybody else instead (IV.3.C.iii.c → IV.6).
  Also — {{tq|Up to 8}} can, in this case, be 1 but not zero (IV.2.A says 9-16 total – 9=7+JW+1 or 9=7+(no JW)+2). — GhostInTheMachine ^{talk to me} 11:34, 29 January 2021 (UTC)
• The bylaws are vague enough that the Board can do whatever it wants. The only real limitations is that it must hold some sort of community/affiliate based selection process for 1-8 of the seats and consider the results. --RaiderAspect (talk) 13:44, 29 January 2021 (UTC)

Summary: The Foundation has been running a rebranding project, involving organization names and logos etc. Various documentation made it clear that the plan involved renaming Wikimedia Foundation to "Wikipedia Foundation" or something similar. An RFC at Meta received 586 votes and reached over 92% consensus that it was not acceptable for the Foundation to call itself Wikipedia.[https://meta.wikimedia.org/wiki/Requests_for_comment/Should_the_Foundation_call_itself_Wikipedia] The rebranding team then proceeded with a plan and community-survey where every available option was restricted to renaming the Foundation as "Wikipedia" in some form. (Wikipedia Trust or Wikipedia Network or Wikipedia Foundation.) This, and other strong community complaints, lead to a Community open letter on renaming signed by over one thousand editors and affiliates and orgs. The letter asked the Board of Trustees to pause or stop the rebranding project. The Board did pause the process and declared they would establish a committee for "developing and proposing changes to the Movement Brand Project process", after which the process would resume. The Board declared that the committee would consist of:

• 2 seats to be filled by the Affiliate leadership.
• 1 seat filled from the Affiliate Committee.
• 2 seats to be filled by Affiliates, with those Affiliates specifically designated by the Board from the global south / emerging and underrepresented communities.
• 2 seats to represent the general community, with those seats specifically designated for "people who participated in authoring the Community Open Letter on Renaming".

As far as I am aware, there are currently only two known candidates to fill the two seats to represent us. To avoid canvassing one way or the other, I will invite people to view the discussion on Meta to learn more about the candidates. I will merely mention that the vote is currently evenly split to accept both or reject both candidates.

As far as I'm aware there has been approximately zero advertisement of this vote, and the current vote is evenly split with exactly half coming from Affiliates. We are technically past the deadline for voting. If you wish to participate, I suggest you hurry.

Voting is at Meta:Talk:Community open letter on renaming#Nominations from among COLOR authors.

Alsee (talk) 16:22, 2 February 2021 (UTC)

Hello all,

Today the Board of Trustees announced that they have ratified an updated draft of the Universal Code of Conduct (UCoC). The update makes changes to four sections, adding clarifying language and reinforcing concepts in the October 2020 draft. These changes can be seen in the change log.

With this announcement, the project moves into Phase 2. The meta:Universal Code of Conduct page has an updated timeline that includes the major engagements ongoing and over the next few months. There is also an updated Frequently Asked Questions page with information on next steps, the current status of the UCoC, and more.

Please let me know if you have any questions. Xeno (WMF) (talk) 18:00, 2 February 2021 (UTC)

Hi, anybody hanging around willing to take a look at the page? Imo, it might not be a bad idea to have someone like {{U|MarcoSwart}} take a closer look at it. Thank you for your time. Lotje (talk) 15:01, 3 February 2021 (UTC)

Announcement on the mailing list. --Yair rand (talk) 03:00, 5 February 2021 (UTC)

:Dang, that's a bummer. –MJL ‐Talk‐^☖ 04:12, 5 February 2021 (UTC)

Well with luck it will go better than the last planned handover.©Geni (talk) 07:19, 5 February 2021 (UTC)

: I do not see why, the procedure seems to be exactly the same.--Ymblanter (talk) 07:47, 5 February 2021 (UTC)

::Different people. More experience.©Geni (talk) 09:45, 5 February 2021 (UTC)

::: Unfortunately, we had a few showcases recently which demonstrate that the collective learning curve of the WMF is, if not flat, not very steep. They continue making the same mistakes which they made 15, 10, and 5 years ago. And people making them are often different. We will see.--Ymblanter (talk) 09:54, 5 February 2021 (UTC)

The WMF is running a consultation on the nature of the Community trustees - both on the selection method (through a sub-committee vs through direct election), quotas, and more.

There is both a general discussion page and subpages for specific proposals.

Please participate and spread word to other suitable locations as appropriate.

Cheers,

Nosebagbear (talk) 17:11, 5 February 2021 (UTC)

: What's the point? The board clearly doesn't care what we say and nothing we say matters. Jimmy Wales already stabbed us in the back after insisting he wouldn't vote for taking away our vote -- which he did -- and the community has largely stood by and watched this happen. This ending of any semblance of community control of Wikipedia should have been fought with 100 times the passion of FramGate or WMF changing its name and...nothing. CoffeeCrumbs (talk) 02:41, 7 February 2021 (UTC)

Hi all, I want to announce the second office hours for the Call for Feedback: Community Board seats.

The Call for Feedback about Community Board seats selection processes is happening between February 1 and March 14. With the help of a team of community facilitators, we are organizing conversations and gathering feedback. It is not too late to join the conversation! Talk to you all soon! Best, JKoerner (WMF) (talk) 22:52, 16 February 2021 (UTC)

[Copied across from WP:VPM]

:*For ease, the second office hours are on Saturday 20th February at 4 different times. Whatever your views, please attend. Nosebagbear (talk) 10:13, 18 February 2021 (UTC)

There doesn't seem to be an UCOC survey for enwiki, but you can participate in e.g. the Wikidata one, [https://docs.google.com/forms/d/e/1FAIpQLSccW9RnWZgP2YYIkBF72Wa3iGd5U4Ut6AUTdwsqdLRbUD6dLA/viewform here]. Most questions are not Wikidata specific anyway, and a fair number are hardly intelligible. E.g. "In the event consensus will be reached about the establishment of an "enforcement body", either on Wikidata or within the Wikimedia community, to address harassment and threats, how much do you agree with the following statements? ... Larger communities should have the possibility to opt-in the scope of action of such "enforcement body", should there be consensus about it." Do you agree or disagree with this? No idea, I don't know how a community can "opt-in the scope of action"[sic] if the enforcement body is established locally in the first place. Fram (talk) 14:35, 12 February 2021 (UTC)

:I have seen that a survey has been sent to some people on Commons though the questions are different between the two surveys seemingly reflecting that the two "facilitators" are different people. {{u|Xeno (WMF)}} what can you tell us about enwiki? Best, Barkeep49 (talk) 16:07, 12 February 2021 (UTC)

::Thanks for the questions {{u|Fram}} & {{u|Barkeep49}}: some local consultations started earlier as they required more time due to the translation workflows or multilingual nature of those projects (and while I've been following along, the individual facilitators would be better placed to discuss).

::For enwiki, the upcoming consultation planned for March (entitled "Meta-wiki consultation") which I'm designing will involve global discussions as well as discussions that are tailored to individual projects. I hope to ensure that any points where the global policy is impractical in individual community contexts are identified and clearly highlighted to the drafting committee writing the application section.

::Please let me know about any other ongoing local discussions, or if you have any thoughts about the upcoming consultation. Xeno (WMF) (talk) 20:40, 18 February 2021 (UTC)

:::@Xeno (WMF) I feel like I have less of a grasp on what will happen than before i started reading this message. Enwiki editors will be expected to participate in meta conversations if they want a voice? Best, Barkeep49 (talk) 21:11, 18 February 2021 (UTC)

::::{{u|Barkeep49}}: The goal is seek feedback from editors of all communities, so discussions that happen locally will be considered and are linked from meta:Universal Code of Conduct/Discussions#Community discussions. Since the formal consultation will involve many different languages and project types, we're still finalizing the exact process to ensure all the feedback is properly organized and considered. Xeno (WMF) (talk) 21:49, 18 February 2021 (UTC)

:::::Well it seems to me that the goal is to solicit feedback from everyone but especially the Arabic, Bangla, Indonesian, Italian, Korean, Malay, Nepali, Polish, and Yoruba Wikipedias plus Wikimedia Commons and Wikidata. Like the nice part of me wants to be sympathetic to the idea that there are probably some really great ideas being planned behind the scenes that just aren't finalized enough for you to reveal yet and if I'm patient there will be some comparable consultation with enwiki.{{pb}}However, there's another part of me that is less charitable. That part of me is based on past experiences with foundation initiatives. Not with foundation staff, I have worked with a variety of foundation staff and on the whole have found them just absolutely delightful and competent at their jobs. However, initiatives seem to be this other thing at the foundation and so my personal affinity and respect for a number of staff doesn't translate to good results. Perhaps it's the people who I haven't worked with driving those initiatives and overruling the good staff who I do know. That part of me says that I should be alarmed that you won't commit to a discussion with enwiki. That part of me is resigned to the fact that it's only large scale anger that has a prayer of getting foundation attention and has me already beginning to think how we would go about generating that kind of attention, perhaps building on our own ability to work cross wiki without the foundation in the middle. I don't like it when I can't convince myself that the nice part of me is what should win out. Sadly, Barkeep49 (talk) 22:52, 18 February 2021 (UTC)

::::::{{u|Barkeep49}}, I had the impression (I'd have to look for diffs to support that claim) that the UCoC was written to codify the existing consensus on the projects that have robust behavioural policies. It was not supposed to conflict with existing enwp policies. As far as its authors are concerned, if I understand them correctly, nothing will change for English Wikipedia. Unfortunately, they are very quiet. Not one has engaged in the discussion of their work. Vexations (talk) 23:10, 18 February 2021 (UTC)

:::::::{{u|Vexations}}, I mean I've heard Maggie Dennis (noping: {{noping|Mdennis (WMF)}} ) say something similar during office hours. And I don't actually have much to quibble with in the UCoC and certainly don't see anything that brings it into conflict with enwiki policies/guidelines. I would go so far as to say I support the UCoC in principle. However, enforcement is the whole ball game and if it is decided that the UCoC is to be regularly enforced on enwiki that's going to be a problem. And that's what phase two is about: how should the UCoC be enforced. So I would expect that enwiki is consulted so they don't just hear these concerns from me, but from the community writ large. And we're here because Xeno can't or won't say that enwiki will be consulted unlike 9 specific Wikipedias plus the two largest non-wikipedia projects. Instead Xeno seems to have written a response to a nice open ended question asking about what he can tell us about enwiki with an answer that boils down to "I can tell you nothing about enwiki". The answer maybe implies enwiki will be one of the "individual project" discussions are "tailored" to. Or maybe it doesn't imply that at all. And so rather than being patient knowing that our time will come, I'm forced to be a Talmudic scholar deciphering missives from a foundation representative. Best, Barkeep49 (talk) 23:28, 18 February 2021 (UTC)

:::::::{{re|Vexations}} I too have had this impression. Frankly, I am worried that communications from WMF staff on this front have been deceptive, and that enwiki will be more deeply affected by the UCoC and the Global Council than anyone would have reasonably anticipated. KevinL (aka L235 · t · c) 23:50, 18 February 2021 (UTC)

::::::::Sorry {{u|Barkeep49}} if I wasn't clear: input from enwiki will be integral to the consultation, and my goal is to ensure the input of this community (and every community) is given due attention, and that individual users are comfortable expressing their thoughts and opinions. I welcome input on how best to achieve that goal. Xeno (WMF) (talk) 00:09, 19 February 2021 (UTC)

:::::::::"input from enwiki will be integral to the consultation": I sure hope so, but that would be a first in this whole UCOC thing, where the actual UCOC is already finalized and the enforcement rules will be written before the largest communities (en, fr, de) are heard for the first time. I fear this is yet another token consultation which won't change a thing, with feeble excuses like "we are already too far in the process to change that now" or "we hear you" (without actually doing anything). All of this is yet another top-down WMF effort (like the rebranding and so many other things), with the same mistakes being made in all of them. The query I linked will probably used to justify some decisions as well, even though some of the questions are incomprehensible and thus the answers worthless (and some others are very leading in the choices given). Anyway, thanks for answering here. Fram (talk) 09:09, 19 February 2021 (UTC)

:::::::::{{ping|Xeno (WMF)}} I'm a bit confused. Should we be waiting for someone from the WMF to organise a survey or discussion on the UCOC on enwiki? Or should we start one ourselves and then link it at meta? – Joe (talk) 11:11, 19 February 2021 (UTC)

::::::::::{{u|Joe Roe}}: It probably makes sense to hold for the structured conversations, where the discussions will be facilitated and organized into major topic groups. The first round (planned for March) will be asking broad questions about potential application of the UCoC globally and in individual community contexts. There is also a parallel consultation ("Functionary consultations") inviting input from Arbitration Committees, CheckUsers, Oversighters, Stewards, and other functionaries. The second round (planned for mid-2021) will seek community input on the proposals created by a drafting committee using the input gathered in earlier rounds. Xeno (WMF) (talk) 14:51, 19 February 2021 (UTC)

:::::::The statement I was looking for is summarized in [https://meta.wikimedia.org/wiki/Universal_Code_of_Conduct/FAQ#Conflict_with_local_policies the answer to question 13] of the Universal Code of Conduct/FAQ I'm not sure if there ever was a statement that enwp's policies do {{tq|meet or exceed the UCoC expectations}}

:::::::

:::::::Earlier statements from the board do not give the impression that the existing enwp policies are sufficient: [https://discuss-space.wmflabs.org/t/kicking-off-the-conversation-what-should-a-universal-code-of-conduct-look-like/2579] for example, and especially the Board's [https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_noticeboard/May_2020_-_Board_of_Trustees_on_Healthy_Community_Culture,_Inclusivity,_and_Safe_Spaces Statement on Healthy Community Culture, Inclusivity, and Safe Spaces], which states rather bluntly : {{tq|The Board does not believe we have made enough progress toward creating welcoming, inclusive, harassment-free spaces in which people can contribute productively and debate constructively.}} Vexations (talk) 21:17, 20 February 2021 (UTC)

:::Re. "some local consultations started earlier as they required more time ... individual facilitators" and "welcome input on how best to achieve that goal". I read the Commons and 'Data conversations last week, and ran the non-English-language discussions through Google Translate (haven't checked back this week yet). I hope they get down to the nitty gritty in time. I got the impression that the questions being asked so far are very general and bland, like 'how do you feel about the Code?' and 'how do you think you should report conduct problems?'.

:::

:::It's interesting to compare the general tone of the responses across language communities. Bangla seems to be like 'this is really good we need this'. Polish is 'go away why is Foundation imposing this we already have an admin noticeboard and an arbcom and we are a lot more civil than wp:en'. In Arabic several people said they would support a Code if they could have input into its formulation, not realizing that ship had already sailed. (Apologies if I am misinterpreting or misrepresenting those discussions.)

:::

:::I'm glad to see that Xeno (WMF) is involved in this. But I still fear that despite having some good facilitators, management direction will result in the consultations just asking us in vague terms what we want, then doing something else anyway. (Then W?F will claim community support for whatever the hell it is the W?F wanted in the first place, because "consultations were held and they were very thorough and successful". And when we say that we didn't ask for this, W?F will say it was directed by the Board, and the Board will say it was "requested by the community" in the Strategy 2030 process, just like how Shani is saying the community requested rebranding.)

:::

:::What we really need is some concrete proposals on the table that we can hash out. Probably English Wikipedia and some of the other "ornery" Wikipedias (de, ru?) will go into depth regardless of the questions asked. But will we be listened to? Pelagic ( messages ) – (11:30 Sat 20, AEDT) 00:30, 20 February 2021 (UTC)

• {{ping|Barkeep49|Vexations|L235|Xeno}} - it clearly isn't intended to be just a formalisation for those communities with significant conduct policy already in place, because in the UCOC-formation "consultation" there were multiple comments from WMF staff, plus the ongoing surveys' questions, suggesting they want a private conduct submission process (even for just on-wiki conduct issues). That suggests the ability to know one's accuser, accused knowing all the evidence against them (in all but the most egregious cases), standard review of accuser's behaviour, etc are not going to be the case. If there is going to be a later meta discussion, there must also be an earlier en-wiki (and de-wiki, etc etc) discussion. The WMF, to me, seems to be prepping to go "some communities want this, and that outweighs what 75% of the editors want" or "we're too far into the process, we'll take your thoughts into account in the actual execution) Nosebagbear (talk) 15:44, 20 February 2021 (UTC)
• :Listen I'm clearly willing to gripe at the foundation and am skeptical about their intentions. But I think it's a stretch to say {{tqq| they want a private conduct submission process (even for just on-wiki conduct issues). That suggests the ability to know one's accuser, accused knowing all the evidence against them (in all but the most egregious cases), standard review of accuser's behaviour, etc are not going to be the case.}} I think they're throwing out a lot of concepts - see the idea of "volunteers" being paid for this work mentioned in the commons survey - not knowing what will work best. I think they don't have the answers. But I also don't think they're going to have a process that will allow for comments except for answers to questions they ask and I think they're going to move at a speed incompatible with the scope of this task. Barkeep49 (talk) 16:30, 20 February 2021 (UTC)
• :Since you pinged me as a volunteer, I get to reply as one: This is the way =)
• :From the commons/wikidata prompts: "How do we balance privacy and safety of reporters with transparency and accountability of reports?" This is something that our community grapples with also, so it is not unexpected the Foundation is seeking advice on how to balance these needs in a manner acceptable to the communities. Enwiki already has a private conduct submission process (even for just on-wiki conduct issues), so the answer from enwiki users might be: "route it to arbcom-en". Shunting it to community members doesn't necessarily solve the problem, though as the balance still needs to be struck by someone. I've found that the private reporting system can still reduce harm without necessarily throwing transparency and accountability out the window: Private reports received at arbcom-en may result in a dialog with the reporting user to determine their level of comfort for the committee's possible responses, as even taking on-wiki action (or even privately contacting the reported user(s)) to address the reported behaviour can cause additional harm in unintended ways. A private reporting system could allow editors to seek assistance with experiences they are receiving as harassment in a non-public space and receive support from users experienced or trained in harm reduction to assist them with addressing the concern in ways the editor had not previously contemplated. –xeno^talk 18:00, 20 February 2021 (UTC)
• ::@{{u|xeno}}: okay but what does {{u|Xeno (WMF)}} have to say about this? {{(:|P}} –MJL ‐Talk‐^☖ 23:24, 20 February 2021 (UTC)

Per a recent update on the IP Masking project, Legal has apparently decided that IP masking is no longer desirable but mandatory, with consultation now limited to implementation form.

Thus far Legal have not provided reasoning on that, but they are set to give a statement (detail level unknown), likely in the next week.

As this will have a significant effect on anti-vandalism efforts, please provide your ideas, concerns, and comments on the discussion page on how to mitigate any negative consequences and utilise any potential positives. Nosebagbear (talk) 10:19, 19 October 2020 (UTC)

: This link will be useful here--Ymblanter (talk) 11:01, 19 October 2020 (UTC)

::Looks like we need, and will have, an RFC on this. Alsee (talk) 09:38, 23 October 2020 (UTC)

:::I believe that our traditional workflow is as follows:

:::# The W?F proposes something on an obscure meta page. Nobody notices.

:::# The W?F posts it somewhere else, and literally everyone who replies hates it.

:::# The W?F reaffirms their commitment to listening to user feedback.

:::# The W?F announces that they are going to go ahead and do it anyway and you can all go and pound sand.

:::# An RfC is posted. Hundreds of people contribute. The result is overwhelmingly negative.

:::# The W?F goes ahead and does what they were always planning on doing.

:::# The shit hits the fan, admins resign, The Signpost does a feature. Wikipediocracy does a feature. The Register does a feature. The Guardian does a feature. The New York Times does a feature.

:::# The board of directors tells the W?F to knock it off. Nobody gets fired or demoted.

:::# Return to start.

:::I will make popcorn. --Guy Macon (talk) 17:19, 23 October 2020 (UTC)

::::Sometimes they skip step 4 and go straight to step 6, which we then follow with step 5. Extra butter, please. – Jonesey95 (talk) 17:58, 23 October 2020 (UTC)

File:Wikipe-tanCrazy.gif destroying Wikipedia with the Fram ban, IP masking, and the 2020 rebrand instead of making obvious but boring improvements to what we have. —pythoncoder (talk | contribs) 18:52, 24 October 2020 (UTC)]]

::::The W?F has thrown a lot of crap at us before, but basically saying "we want more vandals" is a new low. Popcorn tastes good. —pythoncoder (talk | contribs) 18:52, 24 October 2020 (UTC)

:::* Came on this forum to discuss removal of the community voting on the board members. The scheme should include some Facebook discussion and a mention of Jimbo. ;-) Ain92 (talk) 20:07, 29 November 2020 (UTC)

This might be a good next step. -- RoySmith (talk) 21:30, 1 November 2020 (UTC)

I've said this elsewhere, but didn't gain much traction. Showing IP info to logged-in users isn't a problem. Exposing it to every anon, scraper and mirror is a problem. But W?F want to hide it from all of us. Pelagic ( messages ) – (20:33 Thu 05, AEST) 10:33, 5 November 2020 (UTC)

• There should be some freedom for project communities to decide which flag should include the technical right to see IPs. Some projects may decide to allow it to patrollers, other only for admins (W?F proposal doesn't even allow admins). Ain92 (talk) 20:07, 29 November 2020 (UTC)

::: What is the exact legal issue? Can wikipedia just encrypt the ip address with a different id for each edit? Wakelamp d[@-@]b (talk) 13:16, 14 December 2020 (UTC)

• I think every edit should be randomized, so you never know who made what edit, on talk pages and articles. 100% mystery, even admin actions and Arb discussions. That would fix all our problems and make Wikipedia a great place to be an admin at. Maybe they will bump it up to that. Dennis Brown - 2¢ 23:13, 10 January 2021 (UTC)
• I never thought I would wind up advocating that we suspend IP editing, but that now seems to be the sensible option, at least until the WMF has a solution in place and working reasonably well on a sizeable Wikipedia. ϢereSpielChequers 23:34, 10 January 2021 (UTC)
• What do you mean? Which Wikipedia? Jason Quinn (talk) 15:27, 26 January 2021 (UTC)
• If the WMF comes up with a design for IP masking that one or more of the 300 language versions of Wikipedia agrees to test then I would be interested to see the results. For EN I think we should follow Portuguese. ϢereSpielChequers 23:36, 8 February 2021 (UTC)
• {{u|WereSpielChequers}}, no kidding—I have always viewed IP editing as an integral part of Wikipedia, but this project is only making me think that can't last. I typically am blasé about general WMF/project governance decisions, but this one I have some serious concerns about. Perryprog (talk) 21:58, 14 February 2021 (UTC)

:I say this advisedly. You have got to be fucking kidding?--Fuhghettaboutit (talk) 06:02, 24 February 2021 (UTC)

{{tracked|T226797}}

Recent Firefox and Safari browsers now have "total cookie protection" sandbox cookie storage to prevent cross-site tracking by third party cookies. Unfortunately, this also seems to break the Wikimedia single-sign-on mechanism. See https://hacks.mozilla.org/2021/02/introducing-state-partitioning/ for a description of how it works.

This clearly either needs WMF liason with Mozilla and other browser vendors to whitelist the single sign on mechanism, or to use the [https://privacycg.github.io/storage-access/ Storage Access API] to request it be permitted on a site-by-site basis.

{{u|TheDJ}} has filed a bug phab:T226797 for this behavior on Safari, and I can confirm that Firefox 86.0 now shows the same behavior. Apparently Chrome will do the same on the next release.

This is a blocker for serious cross-wiki editorial work, and needs to be fixed ASAP -- how best can we get the WMF's attention on this? -- The Anome (talk) 10:08, 25 February 2021 (UTC)

:The phab ticket is indeed the right way. I've added a pointer to this discussion to the phab ticket and requested that it be given high priority. -- RoySmith (talk) 14:10, 25 February 2021 (UTC)

{{atop

| status =

| result = Ok then, we'll try this over at AN. Barkeep49 (talk) 02:17, 26 February 2021 (UTC)

}}

Attending the office hours last weekend thanks to {{u|Nosebagbear|Nosebagbear's}} notification, the the WMF emphasized that they are willing to hold guided/moderated discussions about this topic with particular groups/communities. Is this something other editors of English Wikipedia would be interested in having? If so I think we can let the WMF know so a date/time could be found to do it. Best, Barkeep49 (talk) 22:01, 25 February 2021 (UTC)

• I'd certainly be for it, especially since I suspect we could get some good staff attendance for en-wiki's, with an easier anticipation than the full meta ones. I'd also be interested to see whether en-wiki as a whole has any particularly cohesive views different from other communities Nosebagbear (talk) 22:19, 25 February 2021 (UTC)
• {{U|Barkeep49}}: This page has very little visibility, something like only 200 watchers. Might want to signal boost your query. –xeno^talk 22:57, 25 February 2021 (UTC)
• Indeed - VPR or AN would both seem fair Nosebagbear (talk) 23:44, 25 February 2021 (UTC)

{{abot}}

• Also, I hope that this specific issue gets handled here, but the larger point that I think this highlights is that it's incredibly difficult to get phab tickets resolved. I sympathize that there are limited developer resources, but Wikipedia has fallen really far behind most of the rest of the web in the basics, and the focus seems to be on building new (sometimes desired, sometimes not) products rather than patching up the core. Having a wishlist once a year where the community collects together hundreds of urgent problems that have already been reported (in some cases for years) and then a tiny team tackles the top 10 is nowhere near enough. Items 10-50 are essential, too. When a problem like this has been on phabricator for a year, we shouldn't have to come here to beg for it to get attention. I could point to plenty of other tickets in a similar situation. What steps could be taken to get significantly more phab tasks out of the backlog? {{u|Sdkb}} ^talk 18:55, 18 February 2021 (UTC)
• :{{u|Sdkb}}, To be fair to the MWF, {{tq| the focus seems to be on building new (sometimes desired, sometimes not) products rather than patching up the core}} has been true on every project I've ever worked on. New stuff is sexy. It's what everybody wants to work on. Most engineering organizations overtly encourage this attitude by putting their best people on new projects, and by rewarding shipping new stuff with raises and promotions, to a greater extent than doing maintenance. -- RoySmith (talk) 19:08, 18 February 2021 (UTC)
• ::{{u|RoySmith}}, for the foundation, the cause is slightly different. The original idea was that they would work 'on the big things' and that the MediaWiki community can pick up the smaller tasks. This concept really stems from around 2009. Unfortunately since then volunteer development hasn't really increased, while MediaWiki itself has become a lot bigger and more complex. I've indicated multiple times in multiple interviews with WMF that I think it is not wise to have so many smaller problems in existing code, with NO owner, and that it creates quality problems.
• ::Since 2015 there is a core team that thinks about such problems in core, but that team is rather invisible to most of the community (they deal mostly with database, caching, api and authentication issues, keeping things running rly). I have also stated multiple times that we should have at least a 1000 developers.... but this seems to be impossible/unwanted. —TheDJ (talk • contribs) 09:58, 19 February 2021 (UTC)
• :::I agree that the urge to work on shiny new features persists everywhere - maintaining things is often boring and repetitive, with little 'to show' for your work, while developing new features has an obvious impact. However, maintenance is incredibly important lest a project accumulate an unworkable amount of technical debt. I'd be happy to look at contributing a pull request for this myself if I can dust off my rather rusty PHP skills, and figure out just how you actually go about submitting a PR for MediaWiki. ƒirefly ( t · c ) 10:43, 19 February 2021 (UTC)
• ::::{{u|Firefly}}, please see mediawikiwiki:New_Developers —TheDJ (talk • contribs) 10:48, 19 February 2021 (UTC)
• :::::Aha, that looks like what I need. Thanks! ƒirefly ( t · c ) 10:51, 19 February 2021 (UTC)
• ::::::{{u|Firefly}}, and more specifically for MediaWiki: How to become a MediaWiki hacker —TheDJ (talk • contribs) 11:07, 19 February 2021 (UTC)
• :::::::Yeah, found that - thanks! ƒirefly ( t · c ) 11:43, 19 February 2021 (UTC)
• :::For me, the issue I have with contributing to MediaWiki development is: (1) I really dislike Gerrit; (2) code reviews are irritating; (3) it's irritating to get WMF sign off on various things I'd want to work on. WMF don't really respond to tickets half the time (fair enough there's a limited amount of attention to go around). Some projects (like FlaggedRevs) are totally abandoned; I wanted to work on improvements to that codebase but there's nobody that will actually code review changes to it. The idea that volunteers work on all the boring/maintenance/smaller stuff and paid devs get to work on the fun stuff is icky. ProcrastinatingReader (talk) 12:01, 19 February 2021 (UTC)
• ::::{{u|ProcrastinatingReader}}, When you say, "code reviews are irritating", do you mean WMF does them in an irritating way, or are you objecting to the entire concept of code review? -- RoySmith (talk) 16:26, 19 February 2021 (UTC)
• :::::I mean some patches just don't get reviewed quickly, or are in obscure parts of the codebase that few people want to review. There's an [https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/+/608884 Echo patch] I started (but someone else finished/did much of the work on) which allows for Echo notifications to be given for multi-rev reverts. Still awaiting code review. Of course code should be reviewed, just it's not exactly motivating to have to wait months for patches lying around till they get deployed. This isn't uncommon in many orgs, especially large enterprises, I acknowledge. But compare this to, say, editing here and getting consensus on issues in a week or a month max via RfC. ProcrastinatingReader (talk) 16:30, 19 February 2021 (UTC)
• ::: {{tq|Since 2015 there is a core team that thinks about such problems in core}} Your timeline is a little off. Up until 2015 there was a core team. In 2015 it split into several smaller teams, and then three weeks later the "core" part was disbanded by WMF executives. A new core team was re-formed in 2017. Then in 2019 or 2020 the focus slowly started shifting to "new shiny things" again. I haven't kept track since to see to what extent they still pay attention to "core" stuff, but as with the 2015–2017 period I'm sure the devs that are left still try to pay attention to core even if management is focused on shiny things. Anomie⚔ 13:54, 19 February 2021 (UTC)
• :::: The dates when the core team was disbanded then reassembled appear to match when Lila Treitikov was head of WMF. If there is a connection, then it would confirm something about the WMF I've long suspected: no one there understands how to properly integrate the technology side with the educational mission. If a technical person is put in charge, the wants & ideas of that side are prioritized -- often to the detriment of the community of volunteers. If a non-technical person is put in charge, that person often has no grasp of how to manage the technical side & ends up being buffaloed into allowing the technical side do whatever it wants. Unless you are interested in promoting technical solutions all of the problems with Wikipedia & the other projects (e.g. "AI will solve all of our content issues"), it is difficult if not impossible to get heard, let alone allowed to enact ideas. -- llywrch (talk) 22:07, 21 February 2021 (UTC)
• ::::: I don't think technical knowledge or lack thereof in the ED makes much of a difference. Technical managers push technical solutions to be seen as "managing", and non-technical managers do other things like push through codes of conduct and rebrandings for the same reason. A friend of mine has compared the practice of management (in general, not specifically at WMF) to James A. Garfield#Treatment and death. Anomie⚔ 23:12, 21 February 2021 (UTC)
• :::::: The difference I am pointing out is that while Treitikov emphasized to her misfortune the Knowledge Machine, it was merely a different species of the same genre of approaches: emphasizing technology without concern about the people who actually make Wikipedia, et alia, successful. The Knowledge Machine at best was unnecessary; at worst it would replace the self-organizing communities of volunteers -- as many fear Wikidata might. Individuals routinely point out shortcomings in the UI that prevent volunteers from participating, such as missing features in the mobile web editing interface or (perhaps more egregious) failure to support blind users; the PTB respond that such requests are difficult & would require more manpower to solve. Yet there is ample resources to support new features the technical side wants to work on. I would hope competent management would explain clearly their priorities should be what the communities want & need -- not another shiny new feature. -- llywrch (talk) 17:23, 22 February 2021 (UTC)
• :::::::One of the things they never find time to fix (failure to support blind users) is actually illegal under the Americans with Disabilities Act of 1990 and exposes the W?F to potential lawsuits. See National Federation of the Blind v. Target Corp.. --Guy Macon (talk) 10:34, 24 February 2021 (UTC)
• ::::::::IANAL, but according to our article Unruh Civil Rights Act#Disability litigation California disability access plaintiffs are allowed claim treble damages with a minimum of $4000 per access violation plus attorneys fees. As far as I can tell, it matters not where you are incorporated, only that you have a physical presence in California. An HQ in San Fransisco will do nicely. --Guy Macon (talk) 10:56, 24 February 2021 (UTC)
• ::::::::: I've always believed locating the Foundation's HQ in the Bay Area would prove to be an unprofitable expense. -- llywrch (talk) 06:43, 25 February 2021 (UTC)
• ::::::::: It's unlikely that it would directly apply in this case; the Unruh Act focused on commercial entities and is relevant here as the Ninth is one of the circuits which has found that an internet site has to have a digital nexus to be a place of public accommodation under the ADA (which is why Unruh was used). There's currently a circuit split on this question. CoffeeCrumbs (talk) 02:52, 27 February 2021 (UTC)
• :Whenever the WMF next holds trustee elections, I'll be voting for trustees who commit to allocating a lot more of the $100+ million annual budget to software development for maintenance tasks like clearing phab tickets (not just new features, although those are important, too). I hope everyone else does the same. The way we fix this problem is to make sure we have trustees that are spending the money correctly. If we don't do that, we'll never get the phab backlog cleared (or replace MediaWiki with something better). Levivich ^harass/_hound 20:16, 25 February 2021 (UTC)
• :: It is quite possible that the WMF never holds the next trustee elections.--Ymblanter (talk) 20:49, 25 February 2021 (UTC)
• ::: I doubt you are the only one who suspects that will become the new normal. -- llywrch (talk) 07:35, 26 February 2021 (UTC)
• ::::[https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_of_Trustees/Call_for_feedback:_Community_Board_seats/Timeline Their timeline] says they'll pick the election process by April 15, and they're (for now) saying they want to complete that election process by the end of the year. I actually doubt that they'll just abandon this timeline altogether. It would look really bad if they had to pass another resolution this year temporarily re-appointing themselves, as they did last year. I think they'll be keen on voting on something concrete (meaning amending the bylaws with this new election process) before summer, so that their temporary term extensions don't have to be re-extended. The bigger question in my mind is what kind of election process they'll select on April 15, and specifically whether they're going to put all the Board seats up for grabs or reappoint themselves. That's going to be the proof of the pudding in terms of whether their intent is to actually continue with elections, or to retain their seats. Levivich ^harass/_hound 18:31, 26 February 2021 (UTC)
• ::::: On that page, I only see selection, not election.--Ymblanter (talk) 18:50, 26 February 2021 (UTC)

• Very good point and question! I'm quite confident that the solution to the problem of "limited developer resources" does not require a lot of time or a lot of money (the latter of which Levivich seems to suggest).
  
  

:Instead, it's only a matter of will or decision-making.

:Wikipedia is one of the largest websites in the world and has a daily audience of millions and probably something on the order of a twentieth of all trained developers in the world (daily).

:I'm all for spending lots (i.e. most) of Wikipedia's financial resources on improving the software, but that's not what it needs at all. I also wouldn't oppose (spending more money for) financial rewards or financial hiring of developers but don't see any reason why volunteer development wouldn't remain to be a major part of this.

:Implementing this only needs one administrator to spend something on the order of a weekend if at all (or a few days and devs more depending on the specifics of the implementation). Imo this should have been addressed years ago and get addressed first before any particular technical issue. --Prototyperspective (talk) 22:27, 28 February 2021 (UTC)

::You might want to read WP:CANCER to see what the phrase "lots (i.e. most) of Wikipedia's financial resources" means in dollars. I'm just saying. --Guy Macon (talk) 22:36, 28 February 2021 (UTC)

• [https://www.bleepingcomputer.com/news/security/researcher-bitsquats-microsofts-windowscom-to-steal-traffic/ Researcher bitsquats Microsoft's windows.com to steal traffic]

Key quote:

:"Of course, the simplest way to prevent bitsquatting attacks is to try and grab bitflipped variations of your own domain names as much as practically possible before a threat actor does."

:"On the defensive side larger companies are easily able to identify and reserve domains that are likely to be used with phishing, bitsquatting, and IDN homoglyph attacks."

It appears that it would cost the Wikimedia foundation less than $200 per year to grab all of the bitsquatting domains, and maybe another few hundred to get all of the "finger hits the next key over" typo domains. They seem to already be doing some of this. Try going to [ https://en.wikipedoa.org ] and [ https://en.wijipedia.org ]. --Guy Macon (talk) 02:20, 5 March 2021 (UTC)

:Who wrote WP:CANCER again? :) ~ ToBeFree (talk) 12:12, 7 March 2021 (UTC)

::That would be that annoying fellow who thinks the W?F should spend money on fixing bugs, security improvements, keeping the servers running, and building an endowment but should not spend money on giving free vacations to exotic destinations to "the in crowd", building a search engine to try to outgoogle google, or trying and failing to do Arbcom's job. This would be in the "security improvements" category. --Guy Macon (talk) 14:16, 7 March 2021 (UTC)

Please note that in recognition of community requests to provide adequate time for other important movement-wide conversations currently ongoing, the Board of Trustees has published Foundation:Resolution:Update to Universal Code of Conduct Timeline, extending the timeline for the current phase of the UCoC project ("outlining clear enforcement pathways") to December 2021.

A description of the project and updated timeline is available at Meta:Universal Code of Conduct. In a nutshell, the Wikimedia Foundation is consulting communities on the application of the Universal Code of Conduct.

The project is meant to be collaborative and involve community members at many levels including volunteers serving on the drafting committee. A call for applications will be posted soon. The Foundation is seeking input from as many communities as possible about how such a global policy might interface with their project. Later this month, specific details will be posted about the individual on-wiki consultations, which will start in April and run into May 2021.

For ease of reference to local policies, guidelines, and past practice, the project team would like to conduct a consultation locally on EnWiki (similar to a process used in 2019 by the Talk pages project). Parallel discussions will be occurring on other projects, including Meta.

As a facilitator for this process, please feel free to let me know if you have any thoughts. Xeno (WMF) (talk) 19:10, 15 March 2021 (UTC)

:Cross-posted from Wikipedia:Village pump (policy)#Update to Universal Code of Conduct Timeline.

Various WMF teams are going to be holding office hours:

• Wikimedia Research office hours today at 16:00 UTC. (In a few minutes from this posting.)
• m:Wikimedia Enterprise office hours on March 19, two sessions at 13:00 and 22:00 UTC, talking about the project to to build services for large-scale commercial reusers.
• Campaigns team Office hours on March 25, 15:00 UTC, talking about "Evaluating ideal use of prizes or rewards for campaigns"
• Community Resources team office hours, talking about the grants strategy relaunch: sessions for EU+CEE on 18 March 2021 17:00 UTC, and LATAM and North America on 22 March 2021 21:00 UTC. (Sessions for other regions already happened.)
• Events team office hours, March 18, 14:00 UTC. (Edit: Added to list, 03:38, 17 March 2021 (UTC))

In case anyone's interested in any of these things. --Yair rand (talk) 15:59, 16 March 2021 (UTC)

:meta:Wikimedia Enterprise

I was just reading [https://www.wired.com/story/wikipedia-finally-asking-big-tech-to-pay-up/ Wikipedia Is Finally Asking Big Tech to Pay Up] in Wired by Noam Cohen and it appears that the WMF has setup a for profit subsidiary "Wikimedia Enterprise LLC" that hosts a version on AWS. A couple other things of note from the article {{tqq|There will also be a level of customer service typical of business arrangements but unprecedented for the volunteer-directed project: a number for its customers to call, a guarantee of certain speeds for delivering the data, a team of experts assigned to solve specific technical flaws...The Foundation says it doesn’t expect Enterprise ever to become the primary source of funding for the foundation’s roughly $100 million budget.}} Barkeep49 (talk) 19:12, 16 March 2021 (UTC)

:Cohen believes this a smart move ({{tqq|For Wikipedia to reject this steady stream of money, to throw up objections based on principle, would perhaps seem as quixotic and stubborn as those homeowners who turn down a big check from a real estate developer planning a new skyscraper. The building usually goes up anyway, while the house sits in its shadows, a relic of the past. And the owner has missed out on a big payday to boot}}). I wouldn't go nearly that far but I certainly don't have any problems with this. I do have a problem that the Foundation seems increasingly assertive in its actions. It feels like with the Global Council we're headed towards some Constitutional structure in terms of Foundation/community relations which has some advantages but also takes us further from supporting the core function of the project - the thing that builds enough value we can create a for profit subsidiary to work on it despite giving it away, nominally, for free - and more into supporting whatever is new and shiny. I would love if the profits of this revenue stream were dedicated towards community directed development. Maybe then we wouldn't have mobile editors who we cannot communicate with. Best, Barkeep49 (talk) 19:17, 16 March 2021 (UTC)

:: The Wikipedia Enterprise link in the topic above is exactly about Wikimedia Enterprise LLC. and the responsible user, as far as understand, is {{noping|Wittylama}}.--Ymblanter (talk) 19:20, 16 March 2021 (UTC)

::{{u|Barkeep49}} It's what was brought up multiple times in the past including in the strategy meetings. Basically.. the foundation is already spending a ton of money supporting these companies. This is often very disruptive support because it has to go in between planned projects etc. and no one keeps track of it. But its necessary because otherwise those companies use the same entryways as community and plain readers and it would become even more unpredictable and costly, so why not make that an actual professional service that can be predictable and stable. There is also hope that investing in better commercial/professional support will trickle down into services for the community like further professionalisation of toolforge services, better backups and export options, maps etc. So basically, instead of having volunteer and NGO labour pay for the commercial services (and then be thrown a grant every once in a while), flip it around and hope that the enterprises can create more value for the NGO and volunteers. The projects has been in development as an idea for quite a while already previously known as okapi. More information is on meta including on the principals, legal structure etc. —TheDJ (talk • contribs) 20:36, 16 March 2021 (UTC)

::::Hello, and yes, I'm the community liaison for the project (to be clear as LWyatt (WMF) (talk), not my volunteer account Wittylama). The WIRED article is a fair description, but it is by-necessity a simplification for a general audience, and it also doesn't get into the details that are most interesting from a wikimedian's perspective. It (quite naturally) focuses on the issues for big tech etc. So, for anyone wanting to read the documentation on-Wiki (as User:TheDJ so kindly pointed out), there is a new an Essay on Meta which discusses the “why?” and “how?” of this project. See also, the associated FAQ, operating principles, and also the technical documentation on mediawiki.org. There's various 'office hours' advertised on the project's main page (on Meta) if you'd like to join those. Sincerely, LWyatt (WMF) (talk) 20:46, 16 March 2021 (UTC)

:::As I stated above I have no problems with this for the reasons you mention. I've been at an average of 1.5 WMF meetings per month (not counting ArbCom) since October but obviously I've not been at the right ones. I'm glad to hear it's been discussed. Best, Barkeep49 (talk) 20:41, 16 March 2021 (UTC)

:::and to quote the FAQ: "Beyond covering for the costs of the project itself, all the funds generated from Enterprise customers will be used to support the Wikimedia mission. This includes investment in the Wikimedia projects, the community, our movement organizations, and the Wikimedia Endowment." —TheDJ (talk • contribs) 20:44, 16 March 2021 (UTC)

::::That's the part I don't agree with. Basically the profits will do whatever the board decides - no different than now. I would suggest, instead, this would be a fine dedicated revenue stream so that things like our inability to communicate with IPs get fixed (or whatever else the community collectively decides is a priority). Right now that feels very underfunded compared to other areas. Best, Barkeep49 (talk) 20:48, 16 March 2021 (UTC)

:When they have trustee elections, I'll be asking the candidates whether they think we should provide our data to the public for free, and if big data take up all the bandwidth, rate limit them; or, whether we should provide our data to the public for free, and if big data take up all the bandwidth, charge them for it. Personally I think I'm in the former camp. Also I wonder if big data would be as interested in our data if it was licensed CC-BY-NC-SA instead of CC-BY-SA. Levivich ^harass/_hound 04:14, 17 March 2021 (UTC)

{{clear}}left{{clear}}

• [https://meta.wikimedia.org/wiki/Wikimedia_Forum#Wikimedia_Enterprise_timeline Discussion on Wikimedia Forum]
• [https://www.wired.com/story/wikipedia-finally-asking-big-tech-to-pay-up/ Wikipedia Is Finally Asking Big Tech to Pay Up] --Wired
• [https://www.infodocket.com/2021/03/16/report-wikimedia-foundation-is-announcing-the-launch-of-a-commerical-product-wikimedia-enterprise/ Report: Wikimedia Foundation is Announcing the Launch of a Commerical Product, Wikimedia Enterprise] --Library Journal
• [https://www.theverge.com/2021/3/16/22334276/wikimedia-enterprise-api-service-big-tech-knowledge-boxes Wikimedia will launch a paid service for big tech companies] --The Verge
• [https://www.techradar.com/news/big-tech-companies-may-soon-have-to-pay-for-wikipedia-content Big tech companies may soon have to pay for Wikipedia content] --TechRadar
• [https://appleinsider.com/articles/21/03/16/apple-might-soon-pay-for-wikipedia-content Apple might soon pay for Wikipedia content] --Apple Insider
• [https://mashable.com/article/wikipedia-charging-big-tech/ Wikipedia wants to charge Google, Amazon, and Apple for using its content] --Mashable
• [https://www.webpronews.com/wikimedia-enterprise-seeks-to-turn-big-tech-into-paying-customers/ Wikimedia Enterprise Seeks to Turn Big Tech Into Paying Customers] --WebProNews
• [https://techstory.in/wikipedia-will-not-be-free-for-tech-giants-anymore-launches-wikimedia-enterprise/ Wikipedia will not be free for tech-giants anymore, launches Wikimedia Enterprise] --TechStory
• [https://www.techinvestornews.com/Tech-News/Latest-Headlines/wikimedia-enterprise-seeks-to-turn-big-tech-into-paying-customers Wikimedia Enterprise Seeks to Turn Big Tech Into Paying Customers] --Tech Investor News
• [https://meta.wikimedia.org/wiki/Wikimedia_Enterprise Wikimedia Enterprise on Meta Wiki]
• [https://meta.wikimedia.org/wiki/Wikimedia_Enterprise/en Wikimedia Enterprise on Meta Wiki]^{...redirects are so old school. Here at W?F we prefer to have two identical pages that update at different times -- until someone forgets to do the manual update. And BTW, the duplicate page doesn't have a talk page. :(}
• [https://diff.wikimedia.org/2021/03/16/introducing-the-wikimedia-enterprise-api/ Wikimedia Enterprise on Wikimedia Dfff]^{...because the software the W?F makes Wikipedia use isn't good enough for the W?F.}
• [https://meta.wikimedia.org/wiki/Wikimedia_Enterprise/FAQ Wikimedia Enterprise/FAQ]
• [https://meta.wikimedia.org/wiki/Wikimedia_Enterprise/Essay Wikimedia Enterprise/Essay]
• [https://enterprise.wikimedia.com/ Wikimedia Enterprise sign up page]
• [https://www.mediawiki.org/wiki/Wikimedia_Enterprise#Active_Development_(Beta) Wikimedia Enterprise API]
• [https://news.ycombinator.com/item?id=26484080 Hacker News thread]
• [https://www.reddit.com/r/patient_hackernews/comments/m6pht2/introducing_the_wikimedia_enterprise_api/ Reddit thread]

--Guy Macon (talk) 14:03, 17 March 2021 (UTC)

• My perspective
• No meaningful conversation in advance
• Avoidance of requests for conversation, to avoid tough questions
• My overall take: WMF is selling Wikimedia community trust and reputation for cheap with no public evidence of due diligence, forethought, or rationale
• Identified team behind this is tech-oriented; no WMF team members here have training in ethics, diversity, society, humanity, values, community, etc.
• The team itself seems prohibited by WMF higher ups from having conversation, or perhaps they simply have no opinions about what they are doing
• The refrain and explanation from the WMF is that money will come in, but nothing else will change.
• The major protest from the Wikimedia community is that inviting corporation will change culture and invite corporate shenanigans and interference with Wikipedia community processes; WMF denies this
• Other online communities have been monetized to their detriment. For example, OpenStreetMap used to be a more of a volunteer community like Wikipedia, but now at their conferences the majority of attendees are corporate professionals
• When Wikipedia ecosystem data is monetized, Wikipedia becomes a business asset which will invite investment in influencing Wikipedia to become a more favorable asset for organizations relying on the revenue stream
• The number that I have heard as unreliable rumor that WMF expects is US$20 million a year starting within 3 years, but so far as I know, no WMF statement on the estimate
• Wikimedia community must demand 51% of gross revenue of the Wikimedia Enterprise Money should go to grants. This is in addition to other Wikimedia community claims to the funding of the Wikimedia Movement.
• Additionally WMF must be financially transparent as part of the Wikimedia Movement commitment to diversity. The public requires financial reports to the satisfaction of the Wikimedia community, including clear reporting (1) how much Wikimedia money is governed by the WMF versus by community (2) reporting by region: Each America, Europe, Africa, South Asia, etc (3) reporting by target minority focus (Global South, gender, etc)
• With this massive change in income, the only resource sharing that I have heard from the WMF is more opportunities for volunteers to spend hours engaging with their paid staff doing the staff's work, and more participation certificates and unpaid recognition with the stated goal of uplifting minority communities through thanks to volunteer representatives

:This all makes me anxious that the WMF is moving into crazy territory without a pilot or anyone able to articulate what they are doing. The lack of communication when so much is at stake is an indicator of major problem. Blue Rasberry (talk) 18:00, 17 March 2021 (UTC)

::Agreed with many of those points. A concern is by taxing Google et al will stop using Wikipedia data (as much). Wikipedia is so popular because the data is open and free, they drive traffic to our site. And once you start imposing fees it is hard to stop, indeed the pressure is to charge more and more often. It creates not partners but competitors. All sorts of problems arise. -- GreenC 18:40, 17 March 2021 (UTC)

::{{Ping|Bluerasberry}}

::* WMF staff appear to be engaging on the Meta talk page.

::* Pegging a percentage to grants strikes me as a bad idea. I expect the overall Wikimedia resource allocation framework to be taken out of WMF hands in any case, per the strategy, so the funds won't be any more under WMF control than other income. (This contradicts the Enterprise FAQ, which asserts that long-term decisions on spending this income will be up to the Board.)

::* Overall, bringing in a lot of funds from deals with Big Tech organizations sounds like a very risky move, and it does not look like the WMF is adequately managing this risk.

::--Yair rand (talk) 18:44, 17 March 2021 (UTC)

:::It does indeed contradict the Enterprise FAQ. I continue to believe that designating the profits from this endeavor - which I expect to increase in the medium term - to community directed purposes, whether programming or grants, should be done. Of course the board wants to have ultimate discretion but that doesn't mean we can't push back on those ideas. Best, Barkeep49 (talk) 19:04, 17 March 2021 (UTC)

:::::{{ping|Barkeep49|Yair rand}}: With regards to the specific point about WMF Board oversight of revenue (and how it is eventually spent): As you note, the FAQ describes the status quo - which is that the WMF board has ultimate legal discretion over movement funds raised by the Wikimedia Foundation. If, as a result of strategy-implementation discussion, the broader movement governance structure were to change in a way that alters the board's role in oversight of movement resources then Wikimedia Enterprise's governance rules would adapt correspondingly. LWyatt (WMF) (talk) 21:39, 17 March 2021 (UTC)

::::::Thanks for making this clear @LWyatt (WMF). The FAQ is obviously correct as to what is happening now while I am arguing that the status quo should change. Best, Barkeep49 (talk) 21:42, 17 March 2021 (UTC)

:::{{ping|Yair rand}} you are right, pegging any one thing to grants is a bad idea.

:::Wikimedia community must demand 51% of gross revenue of the Wikimedia Foundation

:::The only engagement that I want from WMF staff is their funding Wikimedia communities to organize their own conversation. WMF staff should not be using consultants or their own labor to formulate the values and ethics of a community. The Wikimedia Foundation staff and the Wikimedia community are not the same and have very different values and ethics. Increasingly the Wikimedia Foundation has a conflict of interest against the Wikimedia Movement, and moreso as it continues to invest in compromises with corporate players who are buying their way into Wikimedia policy votes.

:::I can support the Wikimedia Enterprise intent to negotiate with corporations, but I wholly oppose the long planning the WMF designed to exclude Wikimedia community perspective from this and the WMF paying people to argue ethics with Wikimedia community volunteers. Ethics and values do not come from corporate paid labor or strategic revenue plans. The heart of all this is revenue and at best, someone at WMF may in the future make a budget item for ethics or compassion, but that has not till now been a consideration even after making 100s of 1000s of other dollars investment in the planning.

:::The Wikimedia Movement needs its own funding for community ethics because the corporate colonialism of the Wikimedia Foundation is never ending and I cannot see where that organization keeps its brain or thought process. The only soul in the Wikimedia Movement is in the community. The corporate personhood of the Wikimedia Foundation is an inhuman golem or Frankenstein. I feel strongly that the success of the Wikimedia Movement is in the trust and reputation that we have good ethics, and the WMF is greatly compromising that by hiding essential information and investing in countering community discussion while not investing in promotion of discussion. Blue Rasberry (talk) 19:10, 17 March 2021 (UTC)

Every time I see one of these WMF flowcharts, it's missing the step at the beginning called "Ask the Community If It Wants to Do This". Levivich ^harass/_hound 19:13, 17 March 2021 (UTC)

:In fairness, the community appears to view most things the WMF does with skepticism (perhaps often deserved, but still). Personally, if the WMF wants to monetise big tech usage of data & is willing to reinvest the profits into making the project better (eg properly funding a development team that can work through the phab backlogs) I'd say it's a good endeavour. ProcrastinatingReader (talk) 20:38, 17 March 2021 (UTC)

::The problem is that the WMF has a strong track record of spending money on perpetuating itself with wishy-washy jobs for people doing things like "outreach" that never deliver anything rather than proper jobs for people who can improve our infrastructure, such as, for example, people who can improve the abysmal experience of editing from a mobile platform. If they would concentrate on the primary job of giving us good infrastructure rather than on perpetuating the bureaucracy then I'm sure nearly everyone would support this. Phil Bridger (talk) 20:56, 17 March 2021 (UTC)

:For what it's worth Levivich, I did write up a reasonably detailed description in the project FAQ to the question of "Where has this previously been discussed?" - going back more than a decade for the general idea. Most recently, there are two specific section of the Movement Strategy recommendations which talk about an Enterprise API. LWyatt (WMF) (talk) 21:14, 17 March 2021 (UTC)

::Reading the FAQ is what prompted me to write that comment. The FAQ answer says, "Revisiting large-scale data services to help ensure the success of the movement, irrespective of changing discovery methods of Wikimedia content, was discussed as a possible avenue for exploration in 2015 and again on Wikimedia-l in 2016 ... The start of work on the Enterprise API project specifically was raised on Wikimedia-l in mid-2020." A board meeting in 2015, a mailing list thread in 2016 do not count as "previously been discussed". It definitely doesn't count as "asking the community if it wants to do this". I suggest revising the FAQ to a direct and honest answer: "Where has this previously been discussed? It wasn't, except in this one board meeting six years ago and once on the mailing list five years ago." Levivich ^harass/_hound 21:23, 17 March 2021 (UTC)

::::Indeed that’s quite true that conversations on mailing lists several years ago about the general topic of an enterprise API do not constitute a discussion of ‘’this’' project. But the point of mentioning these older discussions is that the issue at the heart of this (an for enterprise-scale needs that brings in revenue) has been floating around the movement for a long time – this is not a “new” idea that grew after the last rain-storm. That includes the fact of User:Brion Vibber (WMF), the first ever(?) employee, being able to be hired because of/for the m:Wikimedia update feed service (now long since defunct).

::::What cements those previous discussions, is that Wikimedia Enterprise is based on two sets of recommendations from the movement strategy process and was based on the output of two different working groups. Those recommendations are part of a 4 year body of work that built by nearly 100 Wikimedians of all backgrounds that was based on the inputs of hundreds of volunteers. Given that this project is a direct result of the recommendations from the strategy process, the biggest questions are I feel mainly about how we ought go about this: There are really bad ways this project could be approached, and then there are ways which are aligned with our movement – and we are most definitely trying approach this project via the latter. Over the past 9 months we've also held a number of roundtable discussions and sought the input of a number of volunteers with specific expertise - to design the "principles" list, and various oversight rules described in the FAQ.

::::The public pages for this project (on Meta, MediaWiki, Phabricator) were started in mid-2020 with what was - naturally - relatively little detail since there wasn’t anything “built” yet. But nonetheless there were threads on mailing lists, phabricator tickets etc. at the time too. Now, at this stage of development, there is actually something to “show’ (both in terms of policy and technology) that is concrete enough for people to give useful, actionable, feedback and commentary upon. Much earlier and it’s all hypothetical, much later and it’s already ‘done’: and in both of those cases it would be rightfully very frustrating to be asked ‘what is your feedback?’ of an either non-existent, or an already-finished, project. We’ve tried to get the ‘goldilocks’ moment in the middle of those two extremes: But it’s never going to be the right moment for everyone simultaneously. LWyatt (WMF) (talk) 22:38, 17 March 2021 (UTC)

:::I agree. The WMF should have started a discussion onwiki (with a notice on Village Pump) specifically about this project. Ideally, there should be consensus, but at the very least they should have consulted us and considered our opinions. In this case, there was no consultation, and public news reporting is the first time that I have even heard of this project. Very disappointing, since the volunteers (not the WMF) generate the vast majority of Wikipedia's content. Tony Tan · talk 21:48, 17 March 2021 (UTC)

::::In the WMF's defense I think the place they should start such discussions is meta. This is not an enwiki related thing so while we can (and are) discussing it here I think the foundation is under no obligation to post something about it for us. Best, Barkeep49 (talk) 21:51, 17 March 2021 (UTC)

:::::Meta is the right place for the centralized discussion, but WMF has an obligation to advertise such discussions on all projects. Levivich ^harass/_hound 21:55, 17 March 2021 (UTC)

::Also while I'm here, some other feedback about the FAQ:

::The FAQ question, "How will the money be spent" is answered by {{tqq|Once we have a more clear picture of timing and profitability, the Board of Trustees can plan for how they want to invest the profits to support the mission. That is likely to be at least a year away.}} So we're going to roll out this new product and we don't have a plan for how to invest the profits to support the mission, and won't make a plan until after we have the money, which begs the question: where are you going to put the money in the meantime?. And the really important part of that question is: the LLC or the non-profit?

::The FAQ question, "How much money will this raise" is answered by {{tqq|Unsurprisingly, this is one of the most important questions from a business-model perspective, and it is also impossible to answer in advance. Significant research has been undertaken to learn what the Enterprise API's potential customers need and want, which has informed the product development and, consequently, the estimates of potential revenue over time...}}

::So we haven't pre-sold it. We're building a product for a customer base of like.. what.. less than 100 potential customers? Less than 10? Less than 5? And we haven't presold it? There is no contract in place? We're estimating revenue based on research?

::Which means no customer is making an up-front payment that is paying for the development of this new product.

::So let me get this straight: We're taking money—millions?—from the non-profit and putting into an LLC, and then using that money to build a product that might be interesting to about five customers, and hoping that when it's done, they'll pay for it. If they do, we don't know how much they'll pay, but when they pay, we'll figure out what to do with that money. That'll be at least a year away. We're doing this based on a mailing list discussion five years ago and a board meeting six years held by a board that has since been replaced evaluating the recommendation of a CEO that has since been replaced. Without any discussion revisiting the topic in the interim.

::And this is part of the reason why I can't wait for the next trustee elections. Levivich ^harass/_hound 21:44, 17 March 2021 (UTC)

:::“So we haven't pre-sold it. We're building a product for a customer base of like.. what.. less than 100 potential customers? Less than 10? Less than 5? And we haven't presold it?” U run a business where you presell software and services u don’t yet have? Goddamn, I gotta get in on that trick... —TheDJ (talk • contribs) 22:25, 17 March 2021 (UTC)

::::Every service I sell is pre-sold. I just finished the control electronics for a firefighting robot, and before I started the work we agreed on exactly what they would get and how much they would pay me. Of course some busineses can't do that (Pepsi, for example) but if you only have 10 potential customers pre-selling is a great way to make sure that they will buy what you make. --Guy Macon (talk) 23:46, 17 March 2021 (UTC)

:::::Some folks apparently are unfamiliar with how custom software is sold. Levivich ^harass/_hound 23:49, 17 March 2021 (UTC)

It's one of the oldest dictums out there - money is power. If you control the purse strings, you can control everything else. Or, to put it another way, a budget document is a values document. I believe that the WMF is creating this in good faith. After all, why pass up the potential for a lot of money from some of the world's richest companies if all it's doing is affecting the data flowing out of Wikipedia, and won't impact what content is added or deleted?

That might be true today. But the WMF is putting itself in a dangerous position. If the revenue stream is as successful as the WMF hopes, at some point, it will make up a substantial portion of the WMF's budget. And then the big companies will be in a position to lean on the WMF for changes, in big ways and small, obvious and subtle. Wikipedia is an idealistic place. It will be destroyed by the rapacious maw of capital if it is not carefully managed. The WMF and the community have kept the wolves at bay for years. But this lets them in at last. One step at a time, $$$ will change what Wikipedia is. This idea is a mistake, and a dangerous one to this project. Ganesha811 (talk) 21:28, 19 March 2021 (UTC)

:This is the best nutshell description of the problem. Beautifully put. Rollo (talk) 12:56, 20 March 2021 (UTC)

NOTE: see Meta:Talk:Wikimedia Enterprise#Letting the wolves in at the door. This exact question was also asked on the Meta talkpage for the project, it was answered there, and the conversation continued there. LWyatt (WMF) (talk) 23:46, 19 March 2021 (UTC)

:The foundation is building an endowment fund, eventually that endowment could produce sufficient income to fund the whole prject. If this new revenue stream were to be directed into expanding the endowment fund, then you reduce the risk of WMF budgets expanding to the point where we have to have this money, and you bring forward the day when the movement is financially independent. ϢereSpielChequers 13:49, 20 March 2021 (UTC)

::As it is currently structured, the W?F can at any time take money out of the endowment and use it to maintain their ever-increasing spending despite a major drop in revenue. This is unlike many endowments, where the principle cannot be spent, and makes the W?F endowment just another bank account with extra paperwork needed to make a withdrawal. We may very well choose to trust the current W?F management, but do we also trust all possible future management teams? Having some of the same people on the W?F board and the endowment board is also troubling. --Guy Macon (talk) 14:20, 20 March 2021 (UTC)

:::WSC is right that they're building an endowment, effectively doing a capital campaign all without acknowledging it and all basically on the back of small donors who don't realize that's what they're contributing to. I support them building an endowment even if I don't love the way they're going about it. Barkeep49 (talk) 15:09, 20 March 2021 (UTC)

Based upon my decades of managing hardware and software projects and as a consultant specializing in rescuing engineering projects that are in trouble, here is my technical analysis based upon first principles with no insider information about the Wikimedia Foundation, Google, Amazon, or Apple:

• Assumption #1: The software that Wikipedia runs on can be run on someone else's' computer.
• Assumption #2: The content on Wikipedia can be mirrored on someone else's' computer.

See...

:Wikipedia:Mirrors and forks,

:Wikipedia:FAQ/Forking,

:[https://www.mediawiki.org/wiki/Download Downloading the Wikimedia software],

:Wikipedia:Republishers,

:[https://www.mediawiki.org/wiki/Manual:Installation_guide Wikimedia Installation Guide]. and

:[https://web.archive.org/web/20090124144655/http://modzer0.cs.uaf.edu/~dev2c/wiki/How_to_mirror_Wikipedia How to mirror Wikipedia]

...to examine the above assumptions. Also keep in mind that you can create a mirror of most things that are available on the internet by crawling the website like any ordinary user.

If the above assumptions are true, then Google, Amazon, and Apple can create and maintain complete and frequently updated copies of Wikipedia on their internal servers.

They could also check Wikipedia (we are on the web, after all) to verify that individual pages on their internal server are up to date, with the choice of what pages to update driven by them displaying that content to their users in some form.

At this point, engineers at Google, Amazon, and Apple could reverse engineer the Enterprise API and create an identical API that pulls data from their internal servers. They might even be able to poach some foundation engineers, at least some of whom would welcome a doubling of salary and a promise of better management.

This would give Google, Amazon, and Apple exactly what they would get from the Enterprise API without paying a dime for it.

Engineers at Google, Amazon, and Apple could then attempt to differentiate themselves from each other by making their internal API better in some way than the Enterprise API.

One obvious improvement would be to not update their copy when a new Wikipedia user makes a change unless the edit survives without being reverted for a day or two. This would give them a feed with less vandalism.

My conclusion is that this proposal has a fatal flaw; the potential customer can easily eliminate the middleman. --Guy Macon (talk) 14:12, 20 March 2021 (UTC)

:I was curious about that too, but the reasoning is explained at :mw:Wikimedia Enterprise. – Joe (talk) 15:22, 20 March 2021 (UTC)

::I must be missing something. You can take that document, replace every mention of "Wikimedia Enterprise API" with "Apple's API to their internal server" and all of the listed advantages remain the same. The only way out I can see is if one of my two starting assumptions isn't true. --Guy Macon (talk) 20:06, 20 March 2021 (UTC)

:The reasoning has a gap: this applies for every software product, ever. The difference is that it costs time and money to develop and maintain these systems, more than it costs to purchase API access, and presumably they’d do a worse job than the people who actually have ran the software for decades. The same reason why FAANG and other tech giants buy API subscriptions for practically every other thing, and pay for software like GitHub Enterprise rather than develop their own GitHub from scratch (and repeat for everything else they own). Simply not worth the cost or effort. ProcrastinatingReader (talk) 16:45, 20 March 2021 (UTC)

::No. It does not "apply for every software product, ever." Ignoring the fact that we are talking about a service, not a software product, it only applies to open source products. You can fork Linux, but you can't fork Windows.

::If, as you claim, Google, Amazon, and Apple will be willing to pay for Wikimedia Enterprise API, why then are they not willing to pay to create it? Why does the W?F have to pay the cost out of donations that were never meant to be used to fund a for-profit venture? Has any potential customer signed a contract agreeing that if the new LLC creates X the customer will pay Y for it? Has Google, Amazon, or Apple given us a definition of what they might be willing to buy in the future, or are the details of the Enterprise API based upon what some foundation engineers are guessing that those customers might want? --Guy Macon (talk) 20:06, 20 March 2021 (UTC)

:::I never said there are people willing to buy it. I don’t know exactly what the WMF is selling. I’m just saying it’s a demonstrable fallacy to make the general “big tech can just write it themselves rather than pay for API access” argument. Big tech frequently use external APIs and services rather than reinvent and maintain the wheel. ProcrastinatingReader (talk) 20:33, 20 March 2021 (UTC)

:::Looking at the mw page, briefly it appears for the most part they’re high availability APIs offering access to the same content. I suspect they’d have more interest if they made APIs that analysed the content and provided that, aka something different, rather than just raw data dumps. But I’ve done zero market research and that’s just a guess. ProcrastinatingReader (talk) 20:38, 20 March 2021 (UTC)

: What makes you think that Google, Apple, and Amazon don't already have their own internal mirrors, whether exact or post-processed in some manner? The trick is in keeping these mirrors up to date as Wikipedia is edited, particularly when all three are competing on having the most complete and up-to-date data for their various assistant programs. To me it looks like this whole Enterprise API thing is basically a way to sell then a better feed so they can update their mirrors more reliably, and possibly reduce their own investment in maintaining exact mirrors, while possibly also reducing their impact on Wikipedia's existing infrastructure that isn't really designed for large-scale real-time mirroring. Plus, if you want to ascribe philanthropic motives to the big players, it's much easier for a publicly traded for-profit company to justify (to their shareholders) spending money on a service than to justify making large donations. Anomie⚔ 23:10, 20 March 2021 (UTC)

:: You have pretty much nailed it on the head @User:Anomie Seddon ^talk 01:08, 21 March 2021 (UTC)

:::Yep - as Anomie said. LWyatt (WMF) (talk) 03:43, 21 March 2021 (UTC)

::::So why haven't these potential customers made a financial commitment? Have we even bothered to ask them if they would be willing to fund this? --Guy Macon (talk) 04:05, 21 March 2021 (UTC)

:::::As I wrote on Meta's forum where you also asked this question: It was stated on the record [https://www.wired.com/story/wikipedia-finally-asking-big-tech-to-pay-up/ in an interview for WIRED] that conversations between the the big tech companies and the project team "are already underway" - which is is a simple way of saying that yes, the 'enterprise' team has been in close contact with those companies: finding out what they currently do and how they do it, what they need and can't do themselves, what they'd like instead, and would they be willing to pay for it... This is not being built in a vacuum. LWyatt (WMF) (talk) 04:51, 21 March 2021 (UTC)

::::::Thanks! Very helpful. --Guy Macon (talk) 05:36, 21 March 2021 (UTC)

:The ability to replace one vendor is not a "fatal flaw", it's the whole point of being in the business of free knowledge. Business models for open-source software is a complicated topic, so naturally the press made a giant mess of the news with its sensationalist headlines. All the various for-profit proprietary software companies have [https://www.cncf.io/announcements/2021/02/24/cloud-native-computing-foundation-welcomes-47-new-members-at-the-start-of-2021/ a sore need to share technology], although [https://aws.amazon.com/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch/ not everyone is happy]. [https://www.gnu.org/philosophy/selling.html Selling free software] may not get you the 40 % margins Microsoft has, so some people get sad they can't become billionaires on the stock exchange, but we don't have that problem. Nemo 06:31, 21 March 2021 (UTC)

Perhaps we should consider this as an opportunity. I call upon the W?F to publish a detailed accounting of every penny and every hour spent on this project and of every penny that comes back to the W?F if it succeeds. There is absolutely no reason to keep this information secret -- no other giant online encyclopedia snapping at our heels and trying to figure out how we do things -- and a detailed accounting would make the project a lot more palatable to the community. --Guy Macon (talk) 04:05, 21 March 2021 (UTC)

:As noted in the FAQ on meta in the financial subsection, overall revenue and expenses, differentiated from those of the Wikimedia Foundation in general, will be published at least annually. More generally, for those interested in financial issues specifically, there are a couple of other related questions that have been asked and answered on the Meta talkpage, here and here. -- LWyatt (WMF) (talk) 04:43, 21 March 2021 (UTC)