@Iniquity I don't know how much experience you have with the history of community discussions in this topic area, but I have quite a bit. I wan't arguing that we shouldn't filter content. I was summarizing the consistent historical outcome of international and major wiki discussions in this topic area. You appear to have paid little attention to what I wrote, you didn't address or even dispute any of it. The history clearly indicates that any work on this Phab task would be a complete waste of time, there is no chance the community would accept it. The community is likely to get rather hostile if they discover the Foundation attempted to BAN some contributors from improving certain articles, just because someone had a negative opinion regarding some of our article content and and slapped it on a censorship list.

There should be a review of all existing configuration options with a default presumption they be included in community configuration, unless there is a clear reason why an Administrator carrying out community consensus cannot or should not be able to directly access that configuration item.

IMPORTANT REMINDER: English Wikipedia has a standing consensus against VE's wikitext mode, and it's highly likely other wikis will come to the same result if it looks like the project is starting up again. The Foundation should have preformed a full evaluation at that point on whether to formally terminate the project, and it would be unwise to work towards rolling it out or activating it without consulting the community.

This effect appears to be browser-zoom dependent and likely browser dependent. When I tested 100% zoom in Chrome the green version had pixel-perfect alignment and the white version had an odd number of pixels landing on the half-pixel-low side of pixel-perfect alignment. When I rechecked at 200% zoom, in case I was missing a small effect, both green and white versions ended up a few pixels low. It essentially matched the sample image in this task except the offset was in the opposite direction.

@Sannita, in case you didn't catch it yet a second proposal has been opened citing the statement from legal.
That statement wouldn't have changed the previous result. Two people wanted to hear from legal, they wouldn't have made a majority, and I believe they were evaluated as supports anyway.

An EnWiki discussion was split on the issue, closing with about 43% support to create a non-free exemption for this. The use case here is borderline, not quite enough to to justify an exemption to our Free-content-mission. Non-free images should remain excluded, at least for now.

I can offer some relevant context and history on this issue.

What is the reason for restricting access to research collected for this task? Is there some security threat related to VE?

Note that there is an explicit consensus against VisualEditor's wikitext mode (NWE) at EnWiki, and I expect other wikis would agree. I would recommend simply closing this task, unless someone wants to open a discussion with the community to see if new&different consensus is possible.

Is there a reason for this task to still be open? Is there some aspect that is not 100% complete?

I'll attempt to summarize the community's general approach and some key concerns that have been raised.

I find a particular problem with " I have an idea that will allow such content to remain on Wikipedia". It incorrectly implies that the content is not ALREADY allowed on Wikipedia, and implies that some sort of solution or permission is required for it to remain on Wikipedia. I believe every major Wikipedia has a NOTCENSORED policy. The Foundation tried pushing this idea in the 2011 Image filter referendum. It was abandoned due to strong opposition. There were serious discussions on German about forking projects away from the Wikimedia Foundation if there were an attempt to impose content filtering, and I know English takes this very seriously as well.

I think the key is to get back to the fundamental bug I was attempting to report. The current patch mangles the rendering when you copy-paste content from an article to Talk for discussion and work. The expected behavior is consistent and accurate rendering of wikitext when content is copy-pasted. Moving the horizontal line had weird unexpected side effects, like the double-line effect when you have an H2 after an H1, but that should not distract from the underlying issue.

In T230653#7600021, @Izno wrote:

...it would aid vanishing attempts if two things were done with this task...

• Use the user's numeric ID or equivalent, not their user name.
• Don't put the full signature in the output text.

Akk, please do not deploy that patch.

Note that the Commons discussion(link fixed per RoySmith) received UNANIMOUSLY negative community reception, with the only positive comments coming from a WMF staff member trying to defend the project.

The Foundation really shouldn't be assigning intern/outreach tasks that impact the community, when there is a known-or-likely risk of the project receiving hostility or rejection from the community.
Note that the Commons discussion received UNANIMOUSLY negative community reception, with the only positive comments coming from a WMF staff member trying to defend the project.

The community is not likely to accept what is proposed here.

The very first point I made was that the Bad-image-list has absolutely nothing to do with images being offensive. I'll <snip> the largely duplicate explanation here. The Bad-image-list contains almost precisely zero-point-zero percent of "offensive" images.

I see various rationales above essentially wanting to force or prohibit certain results. The community explicitly wanted to keep Wikitext pages, and asked for improvements making it quicker and easier to do what we already do. I think that concept resolves many questions about how these talk-tools should work.

In T306246#8108510, @Ahecht wrote:

There is no requirement that search results or popups contain images

P.S. This is currently listed as a "bug report". It is clearly not a bug report - this is a feature request for a hotly controversial feature.

Firstly: The Bad-image-list is an anti-vandalism tool. If vandal(s) are spamming images of bunny rabbits, the Bad-image-list will contain images of bunny rabbits. Obviously you should not be sabotaging the search functionality of anyone searching for bunny rabbits. This image list also contains effectively zero-percent of our potentially offensive images. If vandals stop trying to use some particular image, that image gets removed from the list. Any vague resemblance with an "offensive image list" is an incidental mirage. Trying to use this as a content censor would be is a clear misuse of this tool. This Phab task should be immediately closed on that grounds alone.

In T91683#7485861, @Jdlrobson wrote:

I think we should keep this simple - either the user defines the page image explicitly or the user marks page images not to use, rather than adding support for both. Using both adds some unnecessary complexity.

@DannyS712 I would like to confirm the anticipated potential of this approach / this platform. Assuming this project gets continued grant funding and/or continued work by staff developers, do you see this realistically on a path towards the userstory described in my last post? Essentially upgrading the current watchlist to work globaly?

While this is not a Use Case I have personally done (yet), an editor may well have need to watch a single page across 200 wikis. If malicious individuals are attacking someone famous, it may be necessary to watch that one biography page in each Wikipedia language plus related pages on other projects. Some people also maintain versions of specific template(s) that have been copied across many wikis. There are various kinds of useful work that can be done independently of the local language.

Not done. While I am impressed with userscript-hacks trying to work around missing functionality, it is still trying to work around our lack of a global watchlist. I am unclear on whether the current project can/will be developed into a global watchlist, or whether we need to reclaim the "globalwatchlist" name/urls for an actual global watchlist project? I'm not a fan of userstories but I'll try to put it in that form:

In T268407#6674513, @Esanders wrote:

Not quite, the tool distinguishes between inline and block tags (and also comment nodes and meta tags). Trailing inline content will be considered within the reply boundary, and so replies will be inserted after it.

@ppelberg I spent a while working out what the code is doing, and I'm pretty sure it fails the task. Quote: Never insert a reply in the middle of a line. It appears to be searching for tags and then inserting the reply, disregarding the fact that it may still be in the middle of a wikitext line when it finds that tag.

@ppelberg Yes, that's the one. I fixed the link in the task description.

The current mainspace search count of about 2,250,000 matches up well with the category count when you include non-article mainspace pages, primarily disambiguation.

@Aklapper the word "you" was intended as a collective noun for the Foundation. If you maintain that raising concern with the Foundation's design and testing workflow is somehow "personal" I would be concerned with your definitions.

@ppelberg when I edit an article and toggle back and forth between wikitext and visual editors, it does not corrupt the wikitext.

Content-specific whitelist

• Reply links would only be appended to comments at a new level of indentation

I don't understand this one, but if it it's saying what I think it's saying then it does not sound correct. The indentation level of a comment shouldn't affect whether it has a reply link.

In T248457#6003779, @Mike_Peel wrote:

I really hope this never happens

There was repeated consensus on this, and if you recall you participated in one. The Foundation handled things badly, but committed to terminating wikidata descriptions when we reached 2 million local descriptions. I expect the result would be Bad all around if the Foundation were to renege.

Why is the information not posted for public access? Maybe this is a silly suggestion, but doesn't the Foundation have a global scale wiki farm for public access content hosting?

@matmarex first note that I'm not actually taking any position here on how the product should work in this case. I'm talking about how we reason about the design. Discussion Tools is a parallel option for posting and editing comments. Any rationale for how Discussion Tools will work should be based on what makes sense for the product given that attempted constraints do not actually hold.

I don't know whether any projects use NEWSECTIONLINK on nontalk pages, although EnWiki gets a low but steady occurrence of them in article space due to VisualEditor and the potentially unclear purpose of it. I just removed NEWSECTIONLINK from 35 articles.

I think you need to run this by legal. This appears to violate the copyright attribution requirements. Logged-out users submitted their contribution under an attribution license, with a reasonable expectation that their IP would serve as their attribution identity.

There should be two magic words. One to enable Discussion Tool, and one to disable Discussion Tool. The magic words would each override the namespace.

I can't test the behavior due to the parsoid 404, so I'll reclose this for now. But there were definitely problems when I tested it some time ago.

The heading isn't intended to be part of the list.

@matmarex I think you should reconsider how you're conceptualizing the product. We're not building a discussion system, we're building a convenience-tool for wikipages. Consider your points here:

• We must ensure there is a signature (because reason)
• Maybe investigate if we actually can prevent the user from removing the signature(s)

@Demian I don't understand your objection about being "less dramatic". What I said was mild, accurate, and factual. For what it's worth I'll try to clarify. When I set a Mediawiki timezone preference I found it was absolutely disruptive to my ability to work. I had to turn it off as soon as I encountered the problem. We copy-paste or type timestamps on a semi-regular basis, and it's a problem when they don't match the entries in history or other logs. Anyone who sets a timezone is going to have to manually convert any timestamp posted by anyone else before they can compare it it in history or logs, and they need to preform a manual conversion before they posting any timestamp. If they don't, other editors will complain about them posting invalid timestamps.

Could someone investigate what percentage of active editors have a custom value set for MediaWiki timezone preference? I could be mistaken, but I expect it would be very low. I found it painfully disruptive when I tried using it.

@iamjessklein not a big deal, but I noticed the link in your example is broken. An http-type link is an external link. External links use single-brackets and a space instead of a pipe. Like this: [https://en.wikipedia.org/wiki/Template:Cite_sign Template:Cite_sign]

Expecting a balanced page, with a closing div or heredoc close is incompatible with what is probably the primary use case. If someone uses the new-section button, or casually adds a new content or a new section at the bottom, the closing div will no longer be at the bottom. Not only will that mess up the rendering of the page, but the closing-div may get automatically archived. Archiving would again result in a page with an unclosed div.

This seems like a poor idea. If you cut the editable range short, they can't append after the signature. We don't usually do that for quick spelling/grammar/link fixes, but major or late changes will often get an appended second signature and possibly a note of what major change was made. Also any attempt to identify the start of the signature will be a guess, and guesses which are wrong will produce very odd behavior for the affected users.

@iamjessklein someone who clicks the standard EDIT button should never enter any flowchart for the DiscussionTool.

The tags would likely be shorter if we had a name for the tool (and for the project). The lack of such a name is becoming increasingly inconvenient.

@matmarex what's the rationale for the current approach? I can see several reasons for start and end indent to differ, but I can't think of any case where a differing end indent would be giving the correct signal.

The task description says VE had a lower success rate than WTE, because it took longer to load, causing users to abandon their edit before even starting. While that is surely true in some cases, I expect it is a minority. Possibly a rather small minority. The overwhelming majority of edit-clicks are people with no intention of editing. They are either misclicks or curiosity clicks. The fact that VE is slow to load merely gives those users a chance to cancel the page load.

In T241391#5833557, @Jc86035 wrote:

it will no longer be necessary to insert block content without indentation if multiline comments/list items are implemented.

@matmarex it looks like the code for where to place the reply is running into trouble because it's trying to follow HTML/parser structure instead of the comment structure. People don't view the structure the way a formal parser does. You need to step away from the usual parsing expectations and focus on what humans are keyed-into.

When the page already contains a comment with multiple signatures (within a single paragraph or list item), there will be only one "Reply" button added, at the end of the line.

Agreed. Paragraphs should be treated as indivisible in every case I can think of, and if I really do want to split a paragraph I would expect to use the full edit button.

I agree with matmarex, a line/paragraph should be treated as an indivisible block.

The current practice of preforming merges silently is a problem, and I would say this particular talk-case case increases the priority on T76997 Edit conflict automatic resolution can silently produce unexpected results. If I edit-conflict at same spot in a discussion I want to either approve the proposed merge, or at minimum be shown the other person's content after the auto-merge. It's possible for this sort of merge to badly distort the apparent context and meaning of a comment.

@Esanders it looks like this task is specific to mobile-VE. Did or does the same issue exist in desktop VE? And if so has it been fixed there too?

I don't think I have ever before seen the software dump a message like this into an article, outside of preview or the reflist-block. It is seriously horrid behavior. Remember, almost everyone looking at the page is a reader, and our primary job is to present the page for that reader.

1. Localized times will confuse and disrupt communication. We routinely use the timestamp when referring to a comment or edit. If you localize times the time value becomes randomized garbage for everyone trying to read it.
2. Displaying localized time would require deeply screwing around with how wikipages work.

In T235923#5761825, @ppelberg wrote:

Updating the task description to include the ideas @MMiller_WMF + @Whatamidoing-WMF raised during today's staff meeting:

• How might the replying text input more clearly communicate to experienced contributors how the workflow behaves (e.g. How and when does the reply workflow prepend indentation syntax to "your" comment?)
  • This relates to to a point @Alsee raised in T235923#5680589 in response to: "What – if anything – should be pre-populated in the reply box?"

This was one of the top results of the Talk Page Consultation. I think(?) the team put section watchlisting on the to-do list.

@ppelberg Eeeek! This Phab task is backwards.

Yikes! What happened to this article is horrid. Don't throw error messages in the middle of an article.
Even worse, for German readers the article is spammed with foreign language garbage text.

There are various use cases for multiple signatures, as well as for disabling the final auto-signature. One example:

@Aklapper if I noticed that the Foundation had left its servers set with the default password, or even worse put gasoline in the fire extinguishers, it is constructive contribution to alert the Foundation of that failure and the very real and very grave consequences of failing to constructively address the issue. Even if my reports are not warmly received and even if they are not immediately successful.

To the extent that [[Wikimedia Product Guidance]] constitutes a "reply", it is a profanity-laced one.

@ppelberg please reopen this task. All we've resolved is that there is no concern about bad faith. We haven't resolved that the issue of non-contributors are being included in the Contributors metric. It's a very low bar to expect ONE edit demonstrating someone is here to work on the project. Heck, if we set the threshhold at a single reverted edit it would at least demonstrate an attempt to contribute.

I don't have any objection per-se to watching the suggested guardrail metrics, however I don't think they will be particularly useful.

Neil is correct. Defining contributor to mean 'article space contribution' has nothing to do with bad faith. Vandals generally don't bother with talk pages. The primary source of disruption is good-faith people arguing. Non-editors are more likely to create, expand, and persist in disruptive arguing.

There are a number of reasons why an edit init might not reach edit ready. However I cannot think of ANY scenario where it would be appropriate to penalize the quick-loading wikitext editor with an edit fail while discarding the data for a VE edit fail. Calculating edit completion rate using ready misleadingly inflates the success percentages for VE.

I suggest closing this task. The community will likely react negatively if you try to point guided tour to the secondary editor.

I'd suggest converting reply-links into non-links, and add strikethrough to indicate they are inactive. (Even better, check the history date and don't show reply-links at all if it's before reply-links were deployed.)

I think many of these questions answer themselves when you keep in mind that we're not building a new discussion system, we just want to help the the user more quickly and more easily insert the exact same blob of wikitext they currently do.

I edited the wikipage item for "Junior Contributors" to add a criteria of "at least one article page edit". You may want to revise this to "at least one article page edit that has not been reverted".

In T235592#5646728, @matmarex wrote:

Depending on the design, the interface might make this information directly visible....

We've been thinking of making this visible by "indenting" the reply textbox on the page

I still like showing the indent string and sig string for several reasons:
(1) Indenting the box would consume X characters of whitespace at the beginning of every line, whereas showing the indent-characters only consumes X characters on the first line of the reply box. This is particularly significant for mobile. (2) Experienced users will be instantly comfortable seeing exactly how the new interface works. (2) The new interface becomes an actively helpful on-ramp. New users will passively absorb how the underlying page works, especially if the shown characters have a tip appear on mouseover. If the new user sticks around they will sometimes need to use the edit button to directly edit the page for various reasons. (3) Making indent characters visible and click-to-edit allows people to replace the indents with an {{od}} outdent or otherwise alter the indentation for various reasons, without having having to leave the new interface. The community likes the power, flexibility, and control they have on talk pages. We should't hardcode-lock the indentation string if we don't have to.

Having the signature characters moving with your cursor as your type sounds annoying.

Agreed. Instead I picture it attached to the bottom-right corner of the text entry box.
While I expect it would be rare to want to delete or change the sig portion, if the indent-characters are click-to-edit then this part should work the same.

[posting in places that aren't a reply]

Ideally we'd add some cue that you can reply to those places, and ideally it would also describe the expected way to indent (imagine a template like {{replywith|#}} that generates some invisible marker), and then the user won't have to know what to do beforehand. I don't think we've thought this through yet (I certainly haven't).

I'm picturing a reply link after each signature, plus a link at the bottom of every section. I think the section-link should say something like "Add comment" or "Add new comment" instead of "Reply". It would add a zero-indent post. The user can supply the * or # if appropriate. Note: For the zero indent case the software will need to prepend a blank line unless one of the following is true: (1) There's already a blank line or section heading directly above (2) the user starts their reply with one of :*# (3) any other known-safe case I missed.