Sun, Sep 17
First, a huge thank you for working on showing moves in diff! YEAY!
Sun, Aug 27
Some of the comments above suggested treating article pages and talk pages differently. That's a mistake. A generic page should be presumed to contain both article content and discussions. Copying arbitrary article content to any page is a fundamental part of our work.
Aug 9 2017
To put it more succinctly, I want a "mode" where the next&previous links are tied to the user rather than tied to the page. I just can't think of a good place or method in the interface to request that mode.
Aug 5 2017
solves that issue. I'm unsure, but a little extra code may be needed to catch cut/paste via right click.
Aug 3 2017
Aug 1 2017
Why is this described as a Visual Editor task? Visual Editor is a minor secondary editor, only used for a small percentage of edits. If auto save is implemented, it's certainly reasonable to also implement it in the secondary editor as well (VE).
Jul 24 2017
It would be rare for someone to deliberately search for bad-faith likely-good edits, so this is not a major issue. Perhaps just display a message that the search may be slow.
Jun 29 2017
I was a little sloppy, preview shows moving gray stripes instead of a blue loading bar. It's the same problem though. Previews appear to be cached, so if you aren't actually editing then repeat previews "only" takes ~8 seconds (~4 seconds to switch ~4 seconds to switch back). However if you're actually working, each keypress kills the cache. A preview takes ~30-35 seconds to load, plus ~4 to switch back. So ten previews is over 6 minutes. Usually I just use one preview before saving, which is still an appalling and unusable performance. But yeah, sometimes we easily hit ten or more previews while working. Having preview on the same screen as the wikitext matters a lot.
Jun 28 2017
Based on the video , it looks like the blue box was't fully covering the link. Hypothesis: If rendering of the blue box is delayed or the location is offset, the underlying link is exposed and clickable?
Jun 25 2017
I did a little experimentation. It appears this bug is being triggered by T153315. Instead of doing a normal copy-paste, the NewEditor defaults to trying to convert HTML into wikitext. When it sees the italics it triggers HTML->Wikitext conversion. Then nowikis get spammed into your wikitext.
With the current editor it doesn't matter how long the article is. Everything is on one long screen. I simply highlight some unique text and use the browser search on it. Pressing F3 then jumps back and forth between article text and the matching wikitext.
Jun 22 2017
Jun 9 2017
Halibutt I'd welcome better data, but so far no one has been offering any. The community has abundant collective real-world experience, and I believe most people will find the available data to be sufficiently clear despite the imperfections.
Jun 3 2017
@Deskana thank you for closing this. Prior to seeing you had closed this, I had also come to the conclusion that continued individual-debate here had become an unproductive time sink for everyone involved.
I listed the settings I used. I made a good faith effort to filter out confounding factors and maximize the VE percentage. Any other factors would only shift the results by a few points. The results are clear enough that fussing over a few percent won't alter the conclusions.
May 26 2017
Adding report by JAn Dudík:
United States 75 sec.
List of planets 140 sec.
I just collected data using the Recent Changes page, set to display the last 5000 edits. Bot edits and logged actions filtered out.
May 22 2017
Thank you for clearing up why some of the testing gave random results. However that is not directly related to this issue.
May 21 2017
Research:VisualEditor's_effect_on_newly_registered_editors/May_2015_study. Results: No change in how many new users made a first edit. No change in new user retention. No change in total contributions. Visual Editing was typically over 6.7 times slower, people were more likely to abandon edits without attempting to save, and attempted saves were less likely to be successful.
May 13 2017
@Kipod, I strongly disagree.
May 9 2017
This popup is a useless "click-to-continue" annoyance when it has only one option.
Apr 15 2017
Apr 4 2017
- Burying PREVIEW in a menu behind the SAVE button leaves new users lost and scared when they actively avoid touching the dangerous SAVE button.
- Burying the most used button in the editor is disruptive for experienced editors.
The most used button in the entire editor, and second most important button in the entire editor, absolutely warrants direct placement next to the SAVE button.
Mar 28 2017
The discussion was unanimous when I posted it. Now one person has disagreed.
Mar 27 2017
@Halibutt : While the comments were posted "last year", they are not over a year old. They were 3 months old when I opened this Phab, and now 4 months old. Your oppose and the new responses, it looks like 6-1. Would you like to open a more formal consensus-process to get a more formal result?
Mar 25 2017
Mar 21 2017
I updated the task description to reflect the closure of the RFC on this issue. Also, my understanding is that blocker tasks inherit the priority of the parent task.
I updated the task description to reflect the closure of the RFC on this issue. Also, my understanding is that blocker tasks inherit the priority of the parent task.
Mar 18 2017
Mar 17 2017
Note that the Minor Planets page has been split. Anyone wanting to test that load time should use the link in Samwalton9's post above.
Mar 16 2017
@Jdforrester-WMF, it's been almost three weeks since I opened this bug. Can I get an answer on this?
You said VE wouldn't be imposed as the SingleEditTab default without asking the community. You said it was a bug that SingleEditTab was deployed with a VE default. EnWiki was fixed to wikitext default, per discussion with the community. And now PolishWiki has a unanimous consensus asking for SingleEditTab to have a wikitext default.
Mar 13 2017
@jayvdb's suggestion looks like the best concepts here. I'd suggest a tweak:
Mar 11 2017
I'll add another voice to the chorus saying that CTRL-V needs to be a plain text paste. The formatted paste behavior is disruptive.
Mar 9 2017
Mar 8 2017
I don't think it's a good idea to start singling out arbitrary section titles. Any empty section is almost never a desired permanent state. However it's not that unusual for sections to be empty while an article is being built, or when it's awaiting content, or when there is a debate in progress on what should/shouldn't be there.
I know next to squat about databases, so I apologize if this is incredibly dumb or obvious. Would it help to: Create the new comment table as write-only, fill it at leisure, and switch all reads&writes to the new table after it fully mirrors the existing data? Then increase the comment limit and clean up the old unused data at leisure.
That at least avoids the need to check both places during reads.
Mar 7 2017
The task is a four letter edit.
Can someone please provide some sort of a response here?
Feb 26 2017
Feb 25 2017
Feb 21 2017
Feb 16 2017
@Jdlrobson: I definitely didn't assume any bad faith here, and I didn't mean to "blame" anyone in particular. Consider this my attempt to stir concepts into the idea sessions :)
Why edit in the page when you can edit outside it?
Feb 14 2017
I'm going to re-open this. Based on a Google Translate view, it looks like there wasn't really any opportunity for them to comment on enablement of Hovercards. All I saw were comments indicating they couldn't comment on it because (at that time) testing of Hovercards was disabled.
@Aklapper I expanded the task in the description, and I see that this still hasn't been triaged.
Jan 31 2017
Summary of load times reported at the RFC:
Alsee: United States 30 seconds. List of Planets 127 seconds.
Daß Wölf: List of planets 114 seconds. Village pump proposals 21 seconds.
Yodin: United States 35 seconds. List of planets 122 seconds.
Fram: Leuchtenberg Gallery 15 seconds. Exposition des primitifs flamands à Bruges 50 seconds.
Whatamidoing: United States 9 seconds. <--- One anomalous report
Jan 30 2017
Jan 28 2017
Holy crap. Wikidata should not be linking to our draft space at all. They definitely should not appear on other language wikis, as public links to a supposed English Language version of the article.
Jan 26 2017
Rather than "assumptions", I'd rather call it a concern. Ensuring a good initial publication is a lot better than (possibly) trying to rewrite history after publication.
I'll illustrate the problem:
Jan 25 2017
@Trizek-WMF thanx for the reply, although I think I failed to properly identify my concern. I fear that you may be unaware of a potential incoming trainwreck.
Jan 23 2017
The RFC on Meta has closed with a clear consensus to remove Flow. Note that this was not an RFC to reduce active Flow pages to zero, this was an RFC for the extension be uninstalled as was done on Enwiki. (T148611)
Four months ago I commented here: The analysis needs to clearly note that invitation and participation were heavily biased towards Flow enthusiasts. (Invitations were selectively posted on the user_talk pages of the small minority who converted their user_talk to Flow.) This should be particularly noted in relation to the question comparing wikitext to Flow.
Jan 9 2017
@Aklapper if you can get the this new editor load time to be comparable to current editor load times, then sure. That will get this Phab listing closed, and terminate the entire discussion here.
Jan 8 2017
The issue was first raised by me 14 weeks ago half way down this thread on Talk:Wikimedia_Product. That was before any project page or documentation even existed yet. "Whatamidoing, can you please please please go to the head of the New Wikitext Editor project and tell them that a new "Wikitext editor" that doesn't have genuine wikitext support is a deal breaker? It has the same Parasoid-based fake wikitext that Flow has. I suspect there would be a consensus against even having it in Beta-features until that "bug" is fixed. I've already saved a screenshot showing the New Editor botching the preview in nine different ways at once, and it's not hard to show lots more. A new wikitext editor that can't give accurate previews is a non-starter."
To avoid a split discussion, see my Technical Collaboration Guideline comment at T154843#2926550.
P.S. I forgot to mention the Technical Collaboration Guideline. As an individual, I am proposing this as an Actionable Blocker. I would be more than happy to see the WMF close this as cantfix/wontfix, so long as it will be reopened as a blocker if/when the community formally resubmits it as a consensus blocker issue.
What I mean is that the community wasn't quibbling about the exact quantity of work. If you could wave a magic wand and reduce the labor by 90%, it wouldn't have made a difference. People who opposed it still would have opposed it.
Jan 7 2017
@Aklapper I just had it happen again. I was able to get a screenshot this time:
I believe I have avoided a "blame" tone in my list below, but I welcome any attempt to improve tone or clarity.
- Pre-development input: This is an old lesson. Early community input has previously been identified as a key factor in the success or failure of a project. For some reason it is still hard to put this lesson into practice. The Gather project was effectively invisible to the community, up to the point it was announced for deployment. Community input during the concept and design phase could have identified significant issues in advance. The idea could have been re-thought, or cheaply canceled.
- Moderation tools: The community has fairly high expectations that any user-generated content is tracked in contribution history, that all of the usual functionality be available for cleaning it up, and that cleanup actions be logged for accountability. Integrating any new non-wikipage user content into our existing systems is a significant undertaking. It should not be done lightly. The community may (uncomfortably) accept bugs or limitations in theses systems in a limited beta-test. However a project team must be prepared to either roll back the product, or to take responsibility for implementing full tracking&moderation functionality if content is left live for an extended period. This issue was addressed by Risker's checklist for content-creation extensions and T126952: Integrate Risker's checklist for content-creation extensions to the WMF product development process.
- Was the maintenance burden underestimated? (Suggested in comment by @JEumerus.) I think it is important to note that this was NOT a significant focus in community discussions. Yes, there would be a lot to review, and yes AFD style keep/delete debates would be ugly, but the critical community concerns were not the what the WMF expected.
- Nature of the content and nature of the work: The content goes against many community policies, and against the very reason that we volunteer. Editors volunteer their unpaid labor to generate publicly-owned content, as a public service to the world. Even user space pages are considered community owned, they are (loosely) expected to serve our global-good mission. Gather content is viewed as essentially "privately owned" social-network style random junk. Any labor greater than zero is like being an unpaid employee policing Facebook content. The community isn't a free labor force to police John Doe's personal junk, for John Doe's personal benefit. The work might seem similar, but community sees a significant difference.
- Terminating a project must be explicitly in-scope for discussion: This issue lead to communication-breakdown and collaboration-breakdown on multiple levels. There were multiple requests from the community to the WMF for a collaborative process to resolve the issue. These requests were made to the liaison, to the project manager, and even to the executive director. All of those requests received evasive non-responses. (Is there some internal WMF policy or culture against responding to those requests?) Multiple requests were made for the WMF acknowledge that ending the project was in-scope for discussion. All of those requests received evasive non-responses. (Is there some internal WMF policy or culture against responding to those requests?) This issue eroded community trust that the WMF was willing or able to participate in good-faith collaborative resolution. It's hard to discuss fixing a project when the WMF can't acknowledge that ending the project might end up being the most appropriate outcome.
- "Community doesn't like/want a product" needs to be considered valid and important feedback. If the community reasons are unclear or confusing, the actionable-response is to investigate and engage. The WMF shouldn't have missed the huge red flag when the Administrator's Noticeboard announcement turned into outright revolt. The community may have communicated its position poorly. The community tends to cite policy-jargon in its reasons. And in this case the community discussion took an odd turn... the community didn't want to engage in an uphill battle arguing against the project. The community basically said "You can keep your project but you'll have to pay staff to do 100% of the labor". This was basically a sarcastic position. The community did not expect the WMF to pay staff to police the content. The WMF was expected to realize that the project was non-viable without community&admin support. In any case, the WMF should have taken the situation seriously.
- Avoid telling the community not to run an RFC. A number of editors wanted to pursue collaborative-resolution with the WMF. Morale for a collaborative process broke down for a number of reasons. Telling the community not to run an RFC is a sore point. This was a "last straw" that caused the final crumble in morale. At that point the community started the RFC, rather than wait for the WMF to announce its internal decision on Gather.
Jan 4 2017
Jan 2 2017
If the broken ANRFC toolbox is a WontFix, can you please update the 2017 wikitext editor page to remove the claim that deploying New Wikitext Editor won't break anything? We'll give users as good an experience as we can, without breaking anything.
Dec 31 2016
Not just redlinks. External links need to show as external links, and a page that links to itself needs to be a black (non-)link. Same as the normal wikitext editor preview.
Dec 30 2016
When I log out it is still remembering not to give me any popup, even when I clear cookies.
Dec 27 2016
Dec 16 2016
Nov 15 2016
Nov 12 2016
@WhatamIdoing it's not clear at all.
@Qgil this is either "Open" or "Declined". The purpose here was to get some sort of clarity. We definitely do not have that here. I for one have absolutely no clue what would happen if one or more communities were to again alter the the default status of the Media Viewer.
Nov 3 2016
Oct 30 2016
T148611 is uninstalling the Flow extension on EnWiki.
Is it really a good idea to add an interface element and one-off code for this micro-feature? It seems like this functionality would be trivially inherent if a workflow system is created.
Flow is to be uninstalled on EnWiki T148611, can we just roll the two tasks into one?