Misplaced Pages

This is an old revision of this page, as edited by Whatamidoing (WMF) (talk | contribs) at 00:25, 2 June 2019. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Old discussions: June 2013 to May 2014, June 2014 to May 2015, June 2015 to May 2016, June 2016 to May 2017

Citation tool in wikitext editor?

Hi What! I've just been given access to paywalled journal articles, thanks to the people at Wiki Ed Foundation and the University of New Hampshire, so I'm resurrecting the review of Parkinson's disease - basically, integrating the reviewers' suggestions along with appropriate supporting sources. It's been a while since I've done any serious editing and I'm very pleased to see this citation tool now embedded in the visual editor. Do you know if it's possible to use the citation tool in the wikitext editor? A JS fix or something? --Anthonyhcole (talk · contribs · email) 03:35, 23 June 2017 (UTC)

Hi Anthonyhcole, it's great to see your name again.

If memory serves, User:Salix alba had a script to do just that, but I'm not sure what the current maintenance status of that script is. Otherwise, you could enable the beta feature for VisualEditor's new built-in wikitext mode, which would give you the citoid service for creating new citations (but not for changing existing ones). Whatamidoing (WMF) (talk) 03:43, 23 June 2017 (UTC)

Thanks. I'll do the latter (enable the beta feature for VisualEditor's new built-in wikitext mode), since I'm mostly adding new references. How do I do that? --Anthonyhcole (talk · contribs · email) 03:46, 23 June 2017 (UTC)

Go to Special:Preferences#mw-prefsection-betafeatures and find the item for "New wikitext mode". It'll probably take just a bit longer to load the page – about four or five seconds in Safari on my Mac just now, but YMMV – but citoid's probably worth it. Note that paste behavior is a little different: if you paste in something with formatted text, it tries to figure out whether you wanted the formatting to be converted to wikitext. Whatamidoing (WMF) (talk) 04:04, 23 June 2017 (UTC)

If you are interested in my script its is at User:Salix alba/Citoid. It gives a side bar menu item which pops up a box where you can input a url and get a generated citation out. It is currently working, but is dependant on the citoid api which occasionally changes. I try to fix it a soon as I know of problems. --Salix alba (talk): 05:29, 23 June 2017 (UTC)

Thank you both, What and Salix alba. I'll play with both options but I've just realised how much faster VE is these days, so will probably do everything in VE from now on.

Turn off counter in edit window?

You are involved in this, this per this? How do we turn off the counter in the edit window? It is a bug not a feature - text is obscured as I reach the right side of the window. Fine to make this an option but this should not be the default. How do we make that happen? Jytdog (talk) 22:37, 19 July 2017 (UTC)

Jytdog, there is quite a bit of discussion on WP:VPT that you may wish to review. --Izno (talk) 23:49, 19 July 2017 (UTC)

I commented over there before coming here. Jytdog (talk) 23:50, 19 July 2017 (UTC)

Hi Jytdog,

That change is on my list. Even if it weren't, you can always ask me, and I'll try to figure out who can help.

They've got a bug in the edit-counter. Please take a look at phab:T169982. If it looks like your problem, then a fix is on the way (maybe one week from now, given the way the deployment schedules work?). In the meantime, when you can't see what you're typing, try the "up" arrow key followed by the "down" arrow key. For me, that's the fastest way to get the edit summary box to properly reset the location of the cursor. If you have a Windows keyboard, then the "End" key might have the same desirable effect. Whatamidoing (WMF) (talk) 07:16, 20 July 2017 (UTC)

Thanks for replying. Will you please tell me where this idea about a counter was discussed before this was launched? Jytdog (talk) 10:39, 20 July 2017 (UTC)

@Jytdog: It was requested in March 2012 and implemented in VisualEditor since at least August 2012. phab:search/query/3gEB6yNOumYU/#R has some other related tasks. --Izno (talk) 11:42, 20 July 2017 (UTC)

So the decision to implement this in the Wikitext editor was that short phab thread phab:T36984? Is that correct? Jytdog (talk) 11:56, 20 July 2017 (UTC)

What to implement in the software is ultimately the devs' decision. Their decisions tend to get made through multiple channels (most commonly, Phab tasks for recording facts/technical details, and IRC and e-mail lists for discussions). But if you want to think about that Phab task as the central point, then you could equally well frame it as "The decision to implement this was because an admin from the English Misplaced Pages requested it, so the devs just did what the editors asked for". You could also say "This idea was a widely used, volunteer-created gadget at some wikis, which has now been merged into MediaWiki core". This isn't something that the devs dreamed up some day; it's an idea that came from the communities, for the purpose of solving daily problems facing experienced editors.

Having said that, I freely grant that the feature isn't as useful for editors like you and me, since you and I are mostly monolingual English people, and the unaccented "English" alphabet happens to be stored as one byte per character. Other characters require four bytes to store, so a short edit summary in some languages can exceed the space in the database for edit summaries.

The devs have promised to fix the scrolling annoyance. Once that's done, I expect that the main value for people like you and I will be making it slightly more obvious to new editors that they really can type a long explanation in the edit summary, and possibly reminding the rest of us why there's almost no room to add information to the default line when we undo an edit by an IPv6 editor. If it takes very long to fix it, then they might temporarily hide it (which might please a few people here, but which is guaranteed to displease some editors at some other wikis). Whatamidoing (WMF) (talk) 16:10, 20 July 2017 (UTC)

Thanks for answering. Jytdog (talk) 18:25, 20 July 2017 (UTC)

Contacting the WMF Legal department

I am contacting you because you are listed as a Community Liaison.

I am putting together a proposal at User:Guy Macon/Proposals/CAPTCHA (part of a series of proposals at User:Guy Macon/Proposals).

In my opinion, the next logical step is to inform someone at the WMF legal department. My problem is that there does not appear to be any noticeboard associated with the WMF legal department and every member of the WMF legal department appears to have a user talk page that cannot be edited.

I am unwilling to use email or post to a mailing list because I want everything involved with my proposals to be open and accessible through the history of the page where the discussion occurred. Can you suggest a way that I can contact legal regarding this matter? -Guy Macon (talk) 17:37, 19 August 2017 (UTC)

Asked and answered. Whatamidoing (WMF) (talk) 00:46, 21 August 2017 (UTC)

Updated thoughts on VisualEditor

You had asked me to reconsider my original stance on VisualEditor. Sorry for not getting back to you sooner; my spouse developed Stevens–Johnson syndrome (but eventually made a full recovery) and I fell off the face of Misplaced Pages.

Anyway, since coming back I have been using VisualEditor much of the time.

I still worry about its making subtler vandalism less likely to be noticed in a timely manner, though I would expect there are some statistics available about that by now. I also still think that "Edit | Edit source" is confusing and that those options would be better represented as "Edit (VisualEditor) | Edit (wikitext)" or similar. It's hard enough getting new editors to understand WP's sourcing requirements without the wikitext editing option looking like it has something to do with that.

I have also noticed, since I'm now using the VisualEditor some of the time, that some things can't presently be done with it, such as fixing a broken citation tag (VE just sticks nowiki tags around the broken tag if you try fixing it with VE, compounding the problem — example diff), and specifying a ref name for a reference to be reused; the latter isn't much of an issue in shorter articles, but in a longer one (e.g. Howard Sims) the simple numbered ref names VE implements would make editing the article difficult for someone who wanted to edit in wikitext mode.

On the other hand, I like the automatic web citation option in VE, even though I often have to go in and edit the reference after adding it to correct the author (first/last), source date, website and/or work fields.

So I guess I'm coming around, but I'd like to hear your response to the concerns I still have. —GrammarFascist _contribs 03:57, 25 August 2017 (UTC)

Do we know what percentage of editors use VisualEditor?

The basic problem is that the developers, despite giving lip service to Agile Development, never created a set of requirements and never engaged with the customers who were to use the system. If they had, obvious problems like using "edit source" as a label in a context where "source" has a completely different meaning would have been identified and fixed.

I say "don't settle". Either the WMF development team publishes a full set of requirements or we keep rejecting the low-quality software they keep throwing over the wall. --Guy Macon (talk) 11:44, 25 August 2017 (UTC)

Guy, when I read Agile software development, I see it say things like "requirements and solutions evolve through the collaborative effort" and "Requirements cannot be fully collected at the beginning of the software development cycle". Doesn't that sound like Agile is the opposite of creating "a full set of requirements"?

As for use, I believe that, as of a couple of months ago, about 30% of all editors use VisualEditor for some edits. This number varies significantly across wikis (e.g., much less at Wikidata and Wikisource) and language (e.g., higher at Portuguese and Catalan Wikipedias). Whatamidoing (WMF) (talk) 17:32, 25 August 2017 (UTC)

Agile means not creating a full set of requirements before you start, as was used in the Waterfall model. It does not mean never interacting with the stakeholders at all, never publishing any requirements no matter how far along the project is, and doing whatever the hell you want to do, throwing it over the wall, and then using superprotect when the surprised users reject it. Here are a couple of reasonably good pages about how agile requirements are supposed to work:

• http://agilemodeling.com/essays/agileRequirementsBestPractices.htm
• http://agilemodeling.com/essays/agileRequirements.htm
• http://agilemodeling.com/essays/requirementsChallenges.htm

If the WMF did what is sescribed in the above pages, I would be happy. --Guy Macon (talk) 22:26, 25 August 2017 (UTC)

Sure, if "never interacting with the stakeholders at all" had any basis in reality, then I'd be concerned, too. Given that the WMF hired four new staff members in 2013 to do nothing except interact with said stakeholders for VisualEditor, and re-assigned several others to that task, and given that there are dozens of pages on multiple wikis that document that interaction (not to mention hundreds of announcements just on this wiki to request that interaction), and given that the WMF performed in-person user testing with experienced editors at Wikimania, and given the the WMF held IRC meetings to discuss it for months and is still holding open bug triage meetings that anyone can join, and given that it did many other things to promote and receive interaction with editors, I doubt that any serious case could be made for a claim that the WMF "never interact with the stakeholders at all" over VisualEditor.

If you are thinking primarily of Media Viewer, then you might be unaware that the WMF not only discussed it repeatedly on multiple wikis, but also flew in editors from multiple countries to spend a couple of days looking at options and telling the product manager what they wanted changed. It's true that, in hindsight, some people think that the early feedback was a source of problems (e.g., the volunteers in those meetings generally wanted extra features added, and they got what they asked for), but I don't think that anyone could honestly call holding face-to-face discussions between stakeholders and the product manager "never interacting with the stakeholders at all". Whatamidoing (WMF) (talk) 01:43, 26 August 2017 (UTC)

All that work must have resulted in a finished set of requirements by now. Got a link? Maybe an unfinished set of requirements that the community can comment on? --Guy Macon (talk) 15:08, 26 August 2017 (UTC)

Welcome back, GrammarFascist! I'm so glad to hear that your spouse has made a full recovery. SJS is a horrible disease.

I really appreciate you getting back to me. Here are my first thoughts:

• VisualEditor can't make vandalism less likely to be noticed: The diffs are the same, and the RecentChanges patrollers are still using the old-fashioned diffs (although an additional review mode is coming that will be particularly useful for certain edits – compare this traditional diff against the new mode). As for the worry that if it's "too" easy to edit, then vandals will edit more often, that seems to be unfounded. I believe that the most recent work on that was about two years ago now (when they were still having significant problems with excessive nowiki tags), and it found no difference in the reversion rates between new editors using VisualEditor and new editors who weren't. This indicates that new editors are no more likely to vandalize (or make otherwise unwanted edits) with VisualEditor than without it.
• You're right that some kinds of broken wikitext can't be fixed in the visual mode. You can switch to a wikitext editor to do that (right side of the toolbar, look for the pencil icon; there's a very similar icon to switch back). In 2013, we could specify custom ref names, but that feature was removed (I don't know why). Since you've reminded me of it, I think I'll go ask about it again. It's something I'd like to see, even if most people don't use it. The team has also talked about making up a ref name based on the automatic citoid output for the refs (maybe pulling the first word from whatever the first two bits of data are in the citation template – you might get "Smith Bob", which is okay, but you might also get "www.nytimes.com 18" – but still, I think it'd be better than ":0", which is what it uses now).
• "Edit source" has been translated as "Edit wikitext" at some (non-English) wikis. I don't think that is necessarily any clearer to new editors (who don't know what "wikitext" is), but I've nothing against it. User testing (in English) has not indicated that the labels are a significant source of confusion for brand-new editors. This might be due to new editors not really knowing about the sourcing policies (or that the wiki jargon calls them "sources" instead of using more familiar, less academic terms such as "books" or "articles"), or it might be due to new editors understanding that the word source in English means many different things, so they try out both editing environments and figure out which one they prefer. Upon your first edit (try it in an incognito/private window), you get a dialog box that offers the opportunity to switch, which has the effect of reminding people that other options exist.

Also: Have you tried out table editing yet? A few experienced editors have told me that it's the only thing that they always switch to the visual mode for. You can play in my sandbox if you want – it has almost every kind of markup, including tables, lists, and music, and you can mess around in it without worrying about messing up a real article. Whatamidoing (WMF) (talk) 18:16, 25 August 2017 (UTC)

A bit of background: I have managed several successful software projects that used Agile methodology at Mattel, Parker Hannifin, Boeing, and as a contractor for the US Navy and US Air Force. So I am not speaking from total ignorance.

In this context (adding a major new feature to an existing system) one of the first things that agile methodology is supposed to have happen is that someone has an idea about how to invoke the new feature and presents that invocation method in a form that everyone can read and comment on. In this case, I would expect something along the lines of

"The visual editor will be invoked by selecting one of two tabs on the edit page. These tabs will be labled "Edit" and "Edit source" on the English Misplaced Pages, with translations TBD."

or perhaps

"The visual editor will be invoked by a checkbox on the preference page. The checkbox will be labeled "Turn on VisualEditor" on the English Misplaced Pages, with translations TBD."

I would expect this to be published somewhere where the community could comment, and finally I would expect that a decision would be made and the method of invocation would be put into the list of requirements. Of course this particular requirement may change based upon something that happens later, but the key is to have a place that we can point to and say "this was discussed and decided. Here is where that happened".

Repeat the process as more things are decided, and eventually you have a set of requirements. Again agile does not mean no requirements. Agile is (among other things) a better way of arriving at the requirements.

So, where was the method of invocation publicly discussed? Where was it decided? And where is the single place where this and all similar decisions were recorded? --Guy Macon (talk) 16:54, 26 August 2017 (UTC)

I hope that you don't seriously expect all Agile-based dev teams to follow DoDAF or any similarly bureaucratic process. The US Department of Defense may demand a single, formal, centralized, detailed list of all requirements, but Agile does not inherently have any such rule.

If you want to know where the current (i.e., not original) design of the edit button is documented and discussed, then you are looking for mw:VisualEditor/Single edit tab. Whatamidoing (WMF) (talk) 21:37, 28 August 2017 (UTC)

Updated thoughts on VisualEditor, take 2

(Guy Macon, since you aren't addressing me at all, but merely using the section heading I created to voice your own concerns with VE, would you please either confine your remarks to the above section or — preferably — create your own section heading under which to air your concerns? I respect your right to have a dialogue with Whatamidoing, but having your conversation with her interspersed with mine is making it difficult for me to follow my own dialogue with her. Thanks in advance.)

@Whatamidoing:

• I'll take you at your word that the WMF "found no difference in the reversion rates between new editors using VisualEditor and new editors who weren't", though I do note that really clever vandals would have gone unnoticed and thus unreverted.
• I would very much like to see either the ability to set custom ref names in VE, a contextual name automatically generated (even if imperfect, this would as you say be better than ":0"), or both.
• I seem to remember encountering newer users at the Teahouse who thought "Edit source" was for doing references, though that would have been a couple of years ago.
• Yes, actually, I have tried out table editing, though only to correct formatting errors introduced by an other editor or editors (diff). I found it mostly user-friendly and intuitive, though the preview made it look like there was still a missing vertical line on one cell, hence my edit summary. I'm sure I will find occasion to use VE to edit tables more in the future.
• Thanks again for soliciting my opinion. —GrammarFascist _contribs 23:04, 26 August 2017 (UTC)

I have the impression that most vandals aren't very clever, but since this test was announced in advance, I'm pretty sure that it's an accurate result. There were several editors who seemed to be carefully watching edits that week to make sure that things were properly reviewed.

Thanks for the tip about confusion at the Teahouse. I couldn't find an example of that in a quick search, but with 650+ archives, that doesn't really mean very much.  ;-) I trust your memory.

There was a plan to have a single edit tab, but it's been stalled for a long while, and I don't know what will happen to it. It's running here and at a few dozen wikis, but we're not switching existing two-tab wikis to "SET" any longer. In the current design of SET, you get one button for editing, and it does whatever you like best (you choose before your first edit or change your personal 'default' in Special:Preferences). But I believe that it still uses "Edit source" when using the older wikitext editors on the editing page for an article (but not when reading an article or on talk pages), so it wouldn't solve your problem, and switching the original two-tab design to this single tab design created confusion among editors, who thought that they had "lost" the other editing environment (since only one button was visible). It needs more work. Whatamidoing (WMF) (talk) 21:20, 28 August 2017 (UTC)

It's true that most vandals aren't very clever — fortunately for us!

I have no doubt that switching everyone from two-tab to single-tab would cause confusion and consternation; the font for wikitext editing was recently switched to monospace, overriding whatever people had set as their personal default, and I know some veteran editors had a hard time figuring out what had happened and how to fix it. So I don't think switching from two-tab to single-tab is a good idea, unless you want to have lots of frustrated, angry editors. Maybe if there was a global message accompanying the change so that people would know what to do to get their old settings back. Would the SET design as it stands still allow for switching editing mode while editing? I have found that option quite useful.

Relatedly, are there plans to enable VE on talk pages? I know it's an unfriendly learning curve for new editors when we're throwing "and you have to use a colon when responding, except when you use 2, 3, 4 or more" at them at the same time as we're throwing links to multiple policy and/or guideline pages at them; being able to just say "and please indent your reply" would help make helping new editors somewhat less overwhelming for them. —GrammarFascist _contribs 13:22, 29 August 2017 (UTC)

There is a global message for the one-or-two tabs thing (screenshot at File:VisualEditor single edit tab preference dialog.png), and it didn't help. Or perhaps it'd be more accurate to say that it didn't help enough, because a one-time message is easily forgotten – even assuming that you understood what it was asking, and I'm not entirely that every single editor would have understood.

Yes, you can still switch back and forth under SET. The English Misplaced Pages is one of the handful of wikis that is running SET (albeit mostly for new accounts), so what we've got here is the SET design. It's possible that some day, switching back and forth will require using VisualEditor's wikitext mode (currently offered as a Beta Feature) – it seems to depend some upon the team's understanding of the user experience research, and some upon technical issues (such as performance). I suppose I'm pointing this possibility out to be clear that I'm not promising that this will always be the case for all users forever (nor am I promising that it won't be), but at this point in time, switching is possible between all WMF supported browsers in spaces where visual editing is supported.

(Side note: Given the number of people who complained when the second editing tabs was introduced in 2013, you might think that experienced editors would be pleased to see the system go back to just one. But with few exceptions, that was not the case. I think that many experienced editors are similar to me, in that I pick and choose the editing environment based on what I'm going to do. Adding a missing /ref tag? Wikitext. Major copyediting effort? Visual mode. And I want to go straight to the better editing environment for that particular task, and not open "my usual" and then have to switch to the one for the task at hand.)

There are no plans to enable visual editing on talk pages. Leaving aside general concepts such as whether the user experience is tuned to the kind of things that happen on talk pages (answer: it isn't, but will editors care?) and how it would cope with broken or partial wikitext syntax such as one finds at VPT (answer: poorly), and focusing purely on the immediately practical issues, it's not really a good choice right now. The visual mode has no idea how to "indent" (it still doesn't support definition lists, which is what that : markup is supposed to be used for), so it would just make a mess of talk pages in its current state.

I once suggested trying VisualEditor's new wikitext mode to a new editor, and s/he seemed to prefer that. The wikitext mode is available on talk pages. It shows plain old wikitext, but it's the same toolbar as the visual mode, and that seemed to be helpful.

BTW, the font change in the older wikitext editors only affected Apple users who hadn't changed their personal default font. I've seen few comments about the change, and the thanks and confusion seem to be equally balanced. Whatamidoing (WMF) (talk) 18:00, 29 August 2017 (UTC)

Re: the change that only affected Apple users, see this exchange at the Teahouse; I don't have time to address the rest right now. (I always figure for every one person asking a question at the Teahouse, there are probably dozens who don't know / didn't think to ask there.) —GrammarFascist _contribs 20:47, 29 August 2017 (UTC)

Thanks for that link.

I think your assumption is reasonable. Whatamidoing (WMF) (talk) 01:55, 30 August 2017 (UTC)

VisualEditor available to IP users?

Hello again. "Misplaced Pages:VisualEditor/Feedback/header" says, "VisualEditor is not currently available to unregistered users here at the English Misplaced Pages, or to users of Internet Explorer 9 anywhere." However, while logged out, I was able to switch from source editor to VisualEditor. Can the "to unregistered users here at the English Misplaced Pages" be removed? --George Ho (talk) 06:41, 9 November 2017 (UTC)

Thanks for the note. I've updated the page. Whatamidoing (WMF) (talk) 18:23, 9 November 2017 (UTC)

Seasons' Greetings

...to you and yours, from the Great White North! FWiW Bzuk (talk) 18:00, 23 December 2017 (UTC)

Severe disruption

I'm assuming the WMF and devs are aware of the severe disruption we've been undergoing for the past couple weeks which has necessitated multiple EC-protections of the ANI board? Admins and edit-filters can't seem to do anything. I know it's a longshot but can anything be done on the server side? --NeilN 04:15, 5 January 2018 (UTC)

Originally posted in error at the technical Village Pump - copying it here

NewYorkActuary, I'm interested in this. Feel free to undo a of my few edits in my sandbox and then leave a note on my talk page about what you did. Let's see if we can figure out how to reproduce this reliably. Whatamidoing (WMF) (talk) 20:19, 22 January 2018 (UTC)

@Whatamidoing (WMF): Thanks for following up on this. I've made two edits to that page. The first was a simple "undo". The second was an "undo" combined with some editing, both done within the basic (standard?) edit window and both done before clicking "Save". Becuase I don't have the VisualEditor installed, I was unable to demonstrate what would happen if I clicked "Undo", but then switched to VisualEditor before saving. NewYorkActuary (talk) 20:48, 22 January 2018 (UTC)

P.S. I just went back to your page to check that both of my edits did have "Tag: Undo" attached to them. But I also saw that you have VisualEditor installed. So how about undoing the most recent edit on one of my pages (this one), but switching to VisualEditor mid-process? We'll see if I get a notification of that edit. NewYorkActuary (talk) 21:03, 22 January 2018 (UTC)

I got two "undo" notifications, so it's "so far, so good". I'm off to revert you in /draft15 now, and I'll ping you when I'm done. Whatamidoing (WMF) (talk) 22:46, 22 January 2018 (UTC)

Okay, I found a different bug. Reverting you didn't actually revert you, although it carefully saved the edit summary. I'm going to go file that bug, and then I'll try again. Could you please let me know if you got the Echo notification about the (failed) reversion? Whatamidoing (WMF) (talk) 22:50, 22 January 2018 (UTC)

With a little more testing, I think that the process for triggering the missing-notification bug and still undoing the edit needs to look like this:

1. Undo an edit (and end up in one of the older wikitext editors – see mw:Editor if you want to know which one you're using).
2. Make any change in the wikitext editor.
3. Switch to the visual editor (optionally, make more changes).
4. Save the page.

If you skip step #2 (as I did), then it doesn't actually revert the change. I don't think that skipping step #2 should actually have any effect on whether you get notified, however; I'm thinking that it will just fail to revert and fail to notify you (which is not necessarily a bad end result for the reverted person, who will not be notified of a non-event, but it is unexpected and broken from the POV of the editor who is trying to revert someone else's changes). Whatamidoing (WMF) (talk) 23:13, 22 January 2018 (UTC)

No, I didn't get that notification. The only one I got was for your mention of me in your 22:50 posting here. NewYorkActuary (talk) 23:40, 22 January 2018 (UTC)

Thanks!

One of the devs has already commented on the task, so it feels like we're making progress today (although I don't think he'll be the one who gets assigned to fix it). Thanks for posting your note at VPT when you noticed something odd. Whatamidoing (WMF) (talk) 23:49, 22 January 2018 (UTC)

Thank you, thank you, thank you!

Re https://phabricator.wikimedia.org/T156228: That jumping zombie cursor in VE has been the bane of my life. I finally found the Phabricator page about it and was glad to discover that it had an easy fix (turning off the Translate gadget). Thank you for your patience and persistence in running this bug to ground. I'm sure it wasn't easy to reproduce.

You're welcome, Gould363. I'm glad that you found it. It's always satisfying to figure out a crazy problem like that one. Whatamidoing (WMF) (talk) 06:36, 12 February 2018 (UTC)

Pending Changes process - still using "Save changes" not "Publish changes"

Hi. As you know, in recent weeks I have been working through to remove all mention of "Save changes" in text and images across our help pages following the wiki-wide decision by WMF to alter the big blue button title from Save changes to Publish changes. I'm indebted to MB and Noyster for drawing my attention to a small issue remaining within the Pending Changes process which needs addressing. In essence, at one stage in the process, the Publish changes button suddenly reverts to its old name of Save changes. For any admin, or person with Pending changes permissions, here's how to reveal the issue:

1. At Special:PendingChanges select an article to review;
2. Rather than normally just hitting either 'Accept revision' or 'Reject changes', choose instead to 'Edit source' to insert an edit of your own. (At this point the blue button at the bottom of the page is labelled 'Submit changes', which is fair enough.
3. Here at the bottom, please now check the tiny tickbox to "Accept this version" (it's adjacent to the 'This is a minor edit' and 'Watch this page' tickboxes)
4. On checking the tickbox, the "Submit" button changes its name to "Save Changes" when it should really now be "Publish changes", as used everywhere else.

I realise experienced editors will have no difficulty with this, and maybe even feel a warm glow that in one small corner of en.wiki common sense still prevails. LOL! However, this doesn't accord with practice elsewhere so does need to be corrected. Rather than report it the Pending Changes talk page, I thought you might be in a better position to identify who should address this matter directly. I'm happy to re-post there if you prefer. Regards from the UK, Nick Moyes (talk) 11:09, 27 February 2018 (UTC)

Oooh, that's a fun little bug. Thank you for sharing it with me.

PendingChanges doesn't use the same "label". Normal editors see MediaWiki:Publishpage; under PendingChanges, I believe that they see MediaWiki:Revreview-submitedit (that's what you see pre-ticking the tiny tickbox; it just happens to be the same wording in both labels). When you tick the box, it switches to MediaWiki:savearticle. I'll have to talk to folks about whether this is a pleasant case of common sense prevailing (i.e., because the original editor is actually the publisher of the content, especially if you didn't change anything after opening it), or something that needs to be fixed (i.e., because you probably opened that page to change something, and I don't know if it's possible to detect whether or not you made changes of your own). Whatamidoing (WMF) (talk) 20:23, 27 February 2018 (UTC)

I think the text is in MediaWiki:Revreview-check-flag-p page. It currently says

Accept this version (includes $1 pending changes)

I can change it. But I'm not sure what to. If it no the right one you can find out which one it is by enabling a gadget in your preferences.--Salix alba (talk): 21:05, 27 February 2018 (UTC)

No, we're not talking about the "accept this version" text", but the wording that's actually displayed within the blue Submit/Publish button itself. (love the botanical username, by the way) Regards, Nick Moyes (talk) 09:51, 28 February 2018 (UTC)

Hello, Salix alba. I don't think that you need to do anything in particular about this right now. I've filed the bug report, and the devs will be able to fix anything centrally (assuming that a fix is needed). Whatamidoing (WMF) (talk) 18:48, 28 February 2018 (UTC)

Still missing lower tools in my account

Hello again. I'm still missing the lower tools in my account, and you said it's OOUI-related or something like that at a Village Pump discussion. I'll upload a screenshot for specifics if you are still confused and wish me to do so. --George Ho (talk) 19:31, 19 April 2018 (UTC)

Unforutnately, I don't know how to fix this for you. Whatamidoing (WMF) (talk) 21:49, 19 April 2018 (UTC)

No need. I realized that I must have disabled "mw:Extension:CharInsert" accidentally. Therefore, I re-enabled it. --George Ho (talk) 16:45, 1 May 2018 (UTC)

security emails and Phab

Thank you for your (archived) suggestion at Misplaced Pages:Village pump (technical)/Archive 165#if login doubtful or fails, send email at that moment, not later. With that in mind, I've now proposed it. I assume you're free to comment. Nick Levinson (talk) 23:30, 16 June 2018 (UTC)

I have NOT...

tagged "Watch" on your page nor on the "Deletion log" page, yet they appeare in my Watchlist. Further, I cannot delete them from same. What is going on here??? Shir-El too 10:15, 7 November 2018 (UTC)

Do you have the redirect User talk:WhatamIdoing (WMF) on your watchlist? Try this link. Whatamidoing (WMF) (talk) 17:22, 7 November 2018 (UTC)

No, not until you asked. There is still something weird going on with 'Deletion log' only now it's supposedly linked to something on User talk:DuncanHill. Is somebody playing hob with the programing? Shir-El too 18:05, 7 November 2018 (UTC)

You might take your question to WP:VPT. Perhaps you have a broken gadget or user script. Whatamidoing (WMF) (talk) 18:42, 7 November 2018 (UTC):

When were single-click link buttons removed?

I am asking you because something tells me that the current link button (with popup) in the editing toolbar was started along with the Visual Editor. So for consistency it was also used in the wikitext editor toolbar. You know what they say about consistency?

After being involved in this thread:

• Misplaced Pages:Village pump (technical)#Separate buttons for single and double bracket links in the editing toolbar

I realized that I must have long ago enabled the old toolbar in Misplaced Pages preferences. Because the use of the old link buttons is so much faster for me than the link button with popup on the new toolbar. See the thread for the full explanation.

The first 4 buttons in the old toolbars are the ones people use all the time:

- there are various versions of the old toolbar. But the first 4 buttons are the same:

• Bold. Italics. Internal link ]. External link .

Shoutwiki does not have the Visual Editor at all. See the old toolbar in use. Click the edit button on this sandbox page for a wiki on Shoutwiki: http://cannabis.shoutwiki.com/Sandbox

Current editors may have no clue that single-click link buttons are much faster. Why would they?

I suggest you initiate some discussion in the rarified air at WMF, and in the developer caves, about putting those single-click link buttons in the Advanced menu for now (in the current default wikitext editor). That way editors have access to them. I can leave the advanced menu open.

I enabled the 2017 wikitext editor today (beta feature in preferences). It is a disaster concerning speed. All 4 of the most common commands are 2-click. Bold and italics is buried in a menu. So I have to click on the menu, and then bold or italic. This doubles the total number of clicks I do in a day, a week, a year.

I don't even see a signature button. I looked in a lot of menus. I had to add it manually. I also don't see a preview button. It is buried too. Everything I use the most is buried and takes at least 2 clicks.

A customizable quick-launch toolbar holding around 5 commands would solve my speed problems. Kind of like the quick-launch taskbar in Windows. --Timeshifter (talk) 13:46, 18 November 2018 (UTC)

Answer to the question you asked: November 6, 2018.

I understand that this changes your workflow, which sucks.

As I understand it, the 2006 experience was:

1. Select word.
2. Click internal link.
3. Brackets 'typed' for you. Done!

Well, "done", if your only goal was to link that word to an article (or redirect) with that exact title. You're kind of screwed if you need the label to differ from the link, because there's no way to tell the editing toolbar that you want to have ] in the article. You have to know how to do that (and many editors don't, especially new ones).

So when they wrote the 2010 toolbar (after getting a lot of complaints about this problem), the experience became:

1. Select word.
2. Click the link button.
3. Change the label (if you want), and then press Return (or take your hands off the keyboard again to go click the button with your mouse).
4. Everything done for you. Done!

So for most of your work, this adds one extra key press (or one extra click), but people can figure out how to make the label different from the link target. It's a tradeoff, but it's the tradeoff that this community asked for back in the day. The key difference, therefore, isn't really "one button vs two"; it's "dumb" button (only adds brackets, and can't even figure out which set of brackets to add) vs "smart" button (formats the whole thing for you, including figuring out whether you're making an internal or external link).

I'm guessing from your comments that you're either not a very fast typist, or that you're not working from a US/English keyboard. Because for me, I never use the buttons for common functions at all. I can type the square brackets in less than half the time that is needed for a mouse-and-toolbar approach. It's the same in the visual editor: Why would I click on anything, when I could just use the Misplaced Pages:VisualEditor/Keyboard shortcuts? ⌘ Command+b works for bold on my Mac just about everywhere, including in the visual editor (and its 2017 wikitext mode, which is what you enabled). I don't think that's unusual among high-volume editors.

As for customization, the 2010 wikitext editor is customizable (as are pretty much all of the major editing tools, actually). mw:Extension:WikiEditor/Toolbar customization#Add a button to an existing toolbar group has an example of a button called "smile" that would type :) for you. Presumably it could be made to type square brackets instead of an emoji. Custom buttons can be placed in whichever group (e.g., "Advanced") you wanted. I don't know if you can remove the buttons that you don't want, but if you wanted to add one (or five), then you could do that.

(In VisualEditor's 2017 wikitext mode, the signature button is almost at the end of the Insert menu. But again, at this wiki, almost all the experienced editors normally type it. I've asked about that one in particular in the past. It varies by language , but at the English Misplaced Pages, relatively few experienced editors use the button.) Whatamidoing (WMF) (talk) 07:15, 19 November 2018 (UTC)

2017 wikitext editor has some good points. But speed (for me) is not one of them.

I am a middle of the road typist. But I don't add bold, italics, or links as I type. I don't often know what I want to be bold, italics, or linked as I type.

So I come back and add them. So the text is already there, and I am just "decorating" it. :)

I go back and type in the labels and URLs for the links that need them. Then I pop on the brackets with one click of the toolbar button.

The 2010 link button with popup box just slows me down. Much faster to come back and type/paste in the label or URL directly into the wikitext window versus type/paste in the label or URL into the popup box.

I don't remember ever using the 2010 editor (or more likely I forgot, since I may have tried it long ago, and didn't like it) until Nov. 6, 2018 when the 2006 toolbar disappeared and there was no toolbar. I decorated my text by keyboard for a couple days, and gave up due to how slow it was.

Then I looked in preferences, village pump, etc. to find out what was going on.

I started editing on Misplaced Pages in October 2005. And Wikia in Feb 2007. Shoutwiki around 2013 on a regular basis.

Many experienced editors on Wikia, Shoutwiki, etc. use the wikitext editor with the 2006 (or similar) toolbar. The source editing on both of them does not have the 2010 editor toolbar. It does not exist as a source editing preference on either site. You can see the Shoutwiki wikitext toolbar by clicking the edit button in the sandbox linked below.

http://cannabis.shoutwiki.com/Sandbox

http://cannabis.shoutwiki.com/Special:Preferences#mw-prefsection-editing

Wikia buries the source editor for anonymous editors in a menu (the 3-line menu). Click the edit button, and then the 3-line button, to see "source editor" in the dropdown menu. No toolbar at all for source editing by anonymous editors.

https://cannabis.wikia.com/Sandbox

But Wikia gives registered editors the option to add the source editing toolbar:

https://cannabis.wikia.com/Special:Preferences#mw-prefsection-editing

Registered editors also have the option in preferences to make source editing the default editing when the edit button is clicked. That is what I and many others have done. In that case "visual editor" is in the dropdown menu next to the edit button. Log in to see that. Set your preferences.

I guess it comes down to whether you are a mouse person or a keyboard person. I am both. I like FPS games using my keyboard and mouse. :)

I can't imagine using my keyboard (arrow keys) to navigate back to the middle of a paragraph to add a link. The mouse is much faster. So I move mouse, select text, add link brackets. THEN, if necessary, I type in a link label or URL. Why would I want to type it into a box? Makes no sense for experienced editors. And from what you tell me, you don't use that popup link box either. You type. The link box is training wheels for new editors.

The simple solution is a short strip of one-click buttons at the beginning or end of the toolbar. Another preference to remove the beginner link button would be nice, but not essential. It just takes up space. --Timeshifter (talk) 11:34, 19 November 2018 (UTC)

I just love this kind of conversation. :-)

The 2017WTE's speed is good enough for me. I type in it just like I did in any of the others. My one relevant complaint about the visual editor is that I can type faster than it can open the boxes. At some point (as a volunteer), I've used them all. The 2006WTE was default when I started editing, but I don't think I used its buttons much. They just didn't do much. WP:WikEd was painfully slow, so I gave up on that one pretty quickly. Switching to the 2010WTE – well, that was when Vector rolled out, and one of the scripts I used broke, so I switched back and forth to MonoBook several times. I'd guess that it took me a couple of weeks to get used to the new toolbar. It could do a lot more, but first you had to find things. It's citation button never worked reliably for me. I'm much happier with the visual editor's citoid tool. (I often use the mouse to click that button, although I know the keyboard shortcut. The shortcut was added much later, and I think I never got out of the habit.)

Our writing approach is the opposite. I almost always know where I want the links to be; in fact, I sometimes write a sentence more for the purpose of adding the link than for just having the sentence. I'm definitely a keyboard person, so even if I need to add a link later, I normally use keyboard navigation (⌘ Command+→ to skip to the end of the line, ⌥ Option+→ to skip to the end of the word, etc.), and it's pretty quick at reaching the words that I missed. I was more dedicated to that when I used a mouse, but even though the trackpad on my laptop is right next to my thumbs, I still don't use it much on wiki.

Have you tried the CSS code for shortening your editing window, to make the one-click buttons that are underneath the editing box easier to reach? Whatamidoing (WMF) (talk) 20:12, 19 November 2018 (UTC)

(unindent). The 2010 editing toolbar moves off the screen. Going back and forth from the top to the bottom of the window is not a viable solution for frequently used markup buttons. It's not just a problem with the window size. The menus at the bottom do not stay open. Stray mouse clicks while scrolling from top to bottom remove previous selections. It's just all-around unwieldy.

The 2017 editing toolbar though solves all those problems because it is always visible at the top of the editing window. So the editing window takes up the full screen and beyond.

(unindent). I renamed the toolbars by year so they are easier to find and share:

• 2006:
• 2010:
• 2017:

As concerns my desire for one-click markup buttons, the toolbars get progressively worse. So, in effect, wikitext editing as many people know it is disappearing, and becoming slow like the visual editor. Editors are making billions of unnecessary extra clicks over the years. That lessens the number of edits that could have been made in the same time period.

I currently like the visual editor only for tables. --Timeshifter (talk) 01:45, 20 November 2018 (UTC)

2017WTE. Keep its top toolbar. Add Commons edit tools on bottom toolbar

I started a subheading because I think this solves all my problems a lot more simply, and nothing new has to be created.

The 2017 wikitext editor (2017WTE) makes using a bottom toolbar much more feasible. The editing window fills the whole screen. There is only one scroll bar.

The 2017WTE top toolbar is fixed in place. Scrolling does not move it. 2017 top toolbar:

An edit tools bottom toolbar could be fixed in place too:

All of those edit tools buttons are single-click (no popup instructions). Just like the old 2006 wikitext top toolbar.

A single-click preview button could be added to it. --Timeshifter (talk) 16:22, 20 November 2018 (UTC)

What would you think about having the "EditTools" (or, more precisely, its contents) at the top of the 2017WTE window, right under the toolbar? phab:T154113 lets int-admins stick arbitrary wikitext into the "Often used" (first) section of the special character inserter. It takes up a bit of vertical space (equivalent to seven lines of text on my screen), but you can leave it open, so it's one click per article to open the menu, and then just a matter of re-training your muscle memory to look for that button at the top of the screen instead of at the bottom. Whatamidoing (WMF) (talk) 16:45, 20 November 2018 (UTC)

I am trying to avoid clicking menus at all, or taking up a lot of the editing window. 7 lines is too much to leave open all the time.

I definitely want to leave open the edit tools all the time. Actually, it is the first line of the edit tools that I want visible onscreen all the time. So maybe if the special character dropdown could be set to show only one line by default, or by preference.

I don't want to have to open the edit tools dropdown every time I open an editing window. I want it opened by default somehow.

I forgot something in my previous message. I want separate bold and italic buttons as in the 2010 wikitext editor.

And I would like to combine the best aspects of these 2 edit tools menus:

I prefer and ] from the first toolbar.

I want <code><nowiki> from the 2nd toolbar. I used it here, but had to retrieve it from the Commons editing window.

And I want a signature button with 2 dashes in front. --~~~~ --Timeshifter (talk) 18:45, 20 November 2018 (UTC)

Show preview. Show changes. One-click buttons needed in 2017 editor

What I miss most in the 2017 wikitext editor (WTE) are the separate one-click buttons for Show preview, Show changes, and Publish. They are in the 2010 wikitext editor:

I use "show preview" more than any other command in the wikitext editor. The lack of one-click access to a preview in the 2017 WTE slows me down more than anything else in the 2017 WTE.

In contrast the 2010 WTE has all 3 buttons, the wikitext editing window, and a preview. All on one page. So I can scan back and forth between the preview and wikitext. To see errors more easily. 2010 WTE is what I am using now to post this message.

I can type in some wikitext, hit preview, and see if it works for me right away. Over and over and over. --Timeshifter (talk) 20:43, 22 November 2018 (UTC)

2017 WTE might have a "show preview" button that opens up the preview in a different tab.

Wikia, in their "classic editor", opens up the preview as an overlay. When not logged in to Wikia go to a sandbox page and click on "classic editor" from the menu next to the edit button.

http://community.wikia.com/Community_Central:Sandbox

https://cannabis.wikia.com/Sandbox

That overlay could be a tab within the same page. That way one could click back and forth between the wikitext editor and the preview. Versus scrolling up and down as in the 2006 and 2010 editors.

That scrolling would be difficult in the 2017 editor since the toolbars are fixed. So tabs would be better. It would be fast too. Everything would be one click. --Timeshifter (talk) 21:20, 23 November 2018 (UTC)

There's some talk about adding a second preview button (maybe in a menu), but I've found that it's worth learning the keyboard shortcut for preview. They're the same ones that work in the 2010 wikitext editor. Whatamidoing (WMF) (talk) 19:10, 27 November 2018 (UTC)

The 2017 WTE has the preview button in a kind of menu now. The popup box from clicking the publish button. I am not a keyboard shortcut type of person. And most people aren't. --Timeshifter (talk) 04:14, 28 November 2018 (UTC)

2017 WTE. It comes down to adding a one-click button strip

How to install 2006 toolbar via preferences: Misplaced Pages:Legacy toolbar.

Now that the 2006 toolbar is back as a gadget on English Misplaced Pages I see that all of my above problems would be solved by putting a one-click button strip on the top or bottom of the 2017 edit window. It would have to stay visible all the time. Not in a menu.

The Show preview, Show changes, and Publish buttons would need to be on that strip too. Or they could be in the sidebar. Visible all the time that the 2017 editing window is open.

The sidebar might also be the place to put the publishing verbiage: "By publishing changes, you agree to the Terms of Use, and you irrevocably agree to release your contribution under the CC BY-SA 3.0 License and the GFDL. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license." It could be in a menu.

That publishing info and related buttons (preview, show changes, publish) would take over the visible sidebar anytime the 2017 editing window is open. So the sidebar would also be one-click buttons visible all the time. -- Timeshifter (talk) 22:14, 28 November 2018 (UTC)

It's possible to add any button you want to the 2017WTE's toolbar. mw:VisualEditor/Gadgets/Add a tool has the directions. Whatamidoing (WMF) (talk) 21:01, 6 December 2018 (UTC)

I have no idea what it does, or how it does it. And as an individual solution, it is not what I am trying to do.

My main motivation in all these discussions is maintaining, and possibly increasing, the total number of monthly edits on English Misplaced Pages. That requires enabling tools at a mass level.

I know from long experience that a "hot button" toolbar (one click to add wikitext directly to the editing window) helps many people do more edits in the wikitext editors. Not all people, but many people.

I did not realize that people had been deprived of such a toolbar for so many years. Unless they started editing a long time ago, and knew how to enable the 2006 toolbar in gadget preferences.

Enabling the hot button toolbar should be in the editing section of preferences. Many more people would then use it, versus accidentally finding it in gadgets preferences. It should be enabled by default. Once people use it many more would keep it enabled.

Every language of Misplaced Pages would have easy access to their particular hot button toolbar. MediaWiki would not provide the toolbar. Mediawiki would just provide the checkbox in the editing section of preferences. That would make the job of core Mediawiki developers much easier.

The hot button toolbar should be at the very top of the editing window. Above the standard toolbar that has menus. That way the 2 toolbars do not interfere with each other. Menus would not push down the hot button toolbar. Both toolbars should be visible at all times.

The hot button toolbar would disappear of course in the visual editor. -- Timeshifter (talk) 03:17, 7 December 2018 (UTC)

Is total number of edits the best metric?

The Wikimedia Foundation tracked the number of active editors as a key metric for years. I believe that the Editing team still reports those (annually? quarterly?), but the organization's focus has changed. The number of active editors dropped when the bots started reverting vandalism. There were editors who made a lot of edits, but their edits weren't really contributing to the sum of human knowledge. They were just pressing buttons that (as it turned out) a bot could push almost as well (and much faster). So there were fewer editors (and over time, fewer edits, as near-instant reversion seemed to discourage vandals), but I don't think anyone would say that this actually indicated a problem. Whatamidoing (WMF) (talk) 04:25, 8 December 2018 (UTC)

(unindent) The info and chart below has been on my user page for years. In case you want to find it quick.

Here is a good summary chart below. It says the maximum number of active editors (5 or more article edits in the last month) peaked at around 53,000 in March 2007.

See also: commons:Category:English Misplaced Pages active editor statistics for more stats and charts. I wonder if there are timeline graphs of the number of editors making 1, 2, 3, and 4, edits per month.

Then we can do the math of the cumulative edits per month by each group. It may turn out the editors who are most important are the ones doing only a few edits per month. That is another reason that any slowness of editing with the Visual Editor and the wikitext editor needs to be addressed.

The bot effects on the total number of edits and the total number of active editors would show up fairly rapidly. After that stabilizes then we are once again able to use the number of active editors, and the total number of monthly edits, as a good tool to measure whether Misplaced Pages is being improved at the same rate, or is losing steam, or is accelerating.

So every improvement in efficiency of clicks increases the amount of time available for meaningful improvements of Misplaced Pages. It adds up when it involves millions of clicks per day. So the bots help a lot in freeing up the time of editors.

I like this timeline chart of the number of monthly edits over the life of Misplaced Pages:

• https://stats.wikimedia.org/v2/#/all-projects/contributing/edits/normal%7Cbar%7CAll%7C~total

Over a million edits per day. That means millions of clicks per day. Since a single edit involves multiple mouse clicks.

I had not seen that chart before. It is encouraging. Overall the number of edits has been increasing. There have been some large dips though at times. I bet the bots were responsible for some of those dips. They eliminated the work of many good editors. So the number of edits went down as they discouraged poor edits and vandalism. But the good editors soon came back to do other things.

Wikidata bots increased the number of edits too. The date is circled on the chart. -- Timeshifter (talk) 08:02, 10 December 2018 (UTC)

Well, I doubt that anyone would say that editors like us are not important, but edits from less experienced, good-faith people might be more valuable on average. For one thing, they tend to add content; for another, they tend to trigger edits by people like us. When a newbie adds something, a neglected page might turn up in the watchlist of an experienced editor for the first time in a long while, and some experienced editors try to build on those edits, rather than just tagging, reverting, and warning.

But again: is the number of actions the right metric? Is it better to make 10 small edits instead of one large one? I've forgotten the exact numbers, but WP:AWB users make something like a quarter-million edits per month. That would be about for 5% of all edits. Almost none of those actually add content. If you get "more edits" by doubling the number of AWB edits, would you call that success? Whatamidoing (WMF) (talk) 19:28, 10 December 2018 (UTC)

(unindent). I don't know what WP:AWB does. Even after I skimmed the page. But like bots, anything that speeds up somebody's editing frees up their time to do more editing. Some people do a larger percentage of large edits versus small edits.

But yes, the total number of edits really matters. It is an easy metric. I know of none better. This chart can be broken down in various ways:

• https://stats.wikimedia.org/v2/#/all-projects/contributing/edits/normal%7Cbar%7CAll%7C~total
• It is linked on this page:
• https://stats.wikimedia.org/v2/#/all-projects

The chart can be broken down into edits by bots versus edits by users. And content and non-content edits. And English Misplaced Pages only. See options in sidebar. The default is all languages of all Wikimedia projects. -- Timeshifter (talk) 14:39, 12 December 2018 (UTC)

AWB is a script that does automated and semi-automated edits to pages, such as fixing the simplest typos or moving ref tags before or after the punctuation (after the punctuation here, before the punctuation at wikis where that's the preferred style). The most common way to run it is to make a separate edit for every visible fix. This maximizes the number of edits, but the amount of content remains the same.

Your chosen metric says that using five AWB edits to make five tiny edits is better than using one edit to make the same five changes. Are you sure about that?

(I realize it's the only metric you know of. But that doesn't mean that the metric measures anything that matters.) Whatamidoing (WMF) (talk) 16:30, 13 December 2018 (UTC)

The whole point of this thread from the very beginning, which you still don't seem to grasp, is that every click saved, and every increase in efficiency, means that more gets done in less time by the editors.

You seem to be implying that your way of editing is somehow better than other ways. You seem to be saying that a person who does smaller edits is not editing as well as someone who does larger edits.

No, that is just diversity in editing styles. That diversity has always existed.

So that means (in my opinion) that when there is an increase in the total amount of edits in a month then that means Misplaced Pages is being improved at a faster rate. The ratio of live editors who prefer smaller to larger edits may remain the same much of the time.

I could go into vast detail as to when and why I do smaller and larger edits, but it is not relevant to my point about the net result. It is simple statistics.

I have repeated several times that bots that free up the time of editors who were doing the same thing improves the content of Misplaced Pages too. By freeing up editor time to do those content tasks. You do not acknowledge this. It is annoying. It is typical of many WMF staff, and the groupthink that exists at times. -- Timeshifter (talk) 01:07, 15 December 2018 (UTC)

But it doesn't work that way – not in the real world. Freeing up my time doesn't mean that I'll use it for expanding articles. People who do "backstage" work like gnoming or patrolling or policy writing would not suddenly morph into article creators if their self-assigned area of work was done. They might use the extra leisure time to play video games instead.

As for the rest, people who use the visual editor tend to make larger edits. Your metric says that their edits are systematically worth less than people who use any of the wikitext editors, or people who do little more than tag articles with Twinkle. The ratio has changed (especially outside of the English Misplaced Pages). Your metric also assumes that stopping edit wars makes things worse, and that using Twinkle to add a dozen tags to every page makes it better. It's not the worst metric, but it is subject to all kinds of confounding factors. It's probably sound for short-term measurements, but over the span of years, it's pretty weak.

Instead of assuming that more edits = more improvement, have you considered metrics like the size of Misplaced Pages (assumes that bigger = better), or actual quality measures, such as citation density and 1.0-type assessments (which can be largely automated now)? Whatamidoing (WMF) (talk) 05:06, 16 December 2018 (UTC)

(unindent). The more metrics the better. I agree that I was/am making some assumptions. But they are based on long observation ever since I began editing Misplaced Pages in 2005. I created many of the first Misplaced Pages/Wikimedia statistics categories on the Commons. Many others have now filled them in with stuff in many languages.

So to avoid assumptions I looked in the last couple days for some hard separation between edits by people versus bots. Because I think we can agree that most content editing is done by people. Some content editing a bot can do is to fill in some references (usually with human oversight). Also, bots can translate articles from other languages so they can be put on English Misplaced Pages. The bots make many mistakes in doing both.

But that "content" editing by bots is a small number of edits when compared to the real content editing done by live editors. Live editors still have to find the references that bots may clean up. And live editors have to fix the translation errors, and check the references used on translated pages.

So, I uploaded this timeline chart below, and I find it to be a strong metric of the increase in the quality and size of content on Misplaced Pages.

And just as importantly, the status of the live editors as a whole as to whether they are able to maintain this huge Misplaced Pages pool of verified knowledge. If the number of edits goes down, then that means there is less oversight of the ever-increasing number of Misplaced Pages articles. Watchlists are what keep Misplaced Pages from going to hell from neglect, vandalism, and old info.

So anything we can do to make editing more efficient in the Visual Editor, and in the Wikitext editor, makes a difference. -- Timeshifter (talk) 13:29, 19 December 2018 (UTC)

Why do you believe that faster is better?

What if "fast" means I do my thing and move on, but "almost fast" means that I have a minute to look around and see a second change that I want to make? What if "fast" is distracting, but "fast enough" makes me feel relaxed and happy while I'm editing?

What if "efficient" means that I make a thousand trivial edits, but "moderate" means that I notice problems beyond a typo?

Software design can nudge people towards certain activities. If you had to choose between a system that efficiently fixed a typo, or a "slower" system that encouraged brilliant prose, which would you choose? Whatamidoing (WMF) (talk) 17:18, 19 December 2018 (UTC)

Wow. Now I understand why the developers and the WMF could make such a clueless decision as to make the Visual Editor launch a whole page rather than just a section. Because somehow making people wait up to half a minute for the Visual Editor to load an article will somehow help people create brilliant prose.

Or the creative prose inspired by making people dig through menus to do simple things in the 2010 and 2017 wikitext editors. I guess I am going to be meditating on great prose while looking at menus instead of doing more editing of the prose.

Or that while I am watching a Visual Editor page load I will map out all my text, links, and bolding. And then remember this bit of prose and formatting. No, that is not how it works. The whole point of a WYSIWYG editor is to see what you are creating while you are creating it.

So let's slow people down some more. That is what the 2017 WTE does compared to the 2010 and 2006 wikitext editors. Each iteration buries more simple one-click tasks in menus.

Hey, why not let the wikitext editor only open whole articles instead of sections?

I have many user subpages I use for editing different tables. When the Visual Editor included more table editing functions I started using it to edit some aspects of table editing. It is far more efficient at some aspects of table editing. I have updated Help:Table with what I have learned.

According to your logic I should go back to using my older, slower, methods of editing tables. In order to create great table prose. I reject your premise that quality output comes by doing things more slowly. -- Timeshifter (talk) 10:19, 20 December 2018 (UTC)

Seems like a strawman there at the end, and several false assumptions on your part to boot elsewhere. Not being able to edit a section in VE is a technical hurdle and there is work being done to enable that. There is also work being done to make VE more efficient. Some of your premises should be rejected out of hand; why WAID has entertained them is beyond me. For example, The more metrics the better is simple garbage. Selecting and analyzing the correct metrics is a profession all by itself and starts getting into questions of what happens when you attempt to optimize one thing--does it cause expense at the others? --Izno (talk) 15:31, 20 December 2018 (UTC)

Reply

Thank you for msging. Being an active contributor I must give you feed back shortly. Pinakpani (talk) 05:03, 27 November 2018 (UTC)

Thank you! Whatamidoing (WMF) (talk) 19:06, 27 November 2018 (UTC)

Heather Thomson USA former RHONY

When you look up Heather Thomson former Real Housewives star, designer, inventor, consultant- Her image comes up with someone else’s BIO. - A New Zealand runners Bio shows up but the image is of Heather Thomson From housewives??? How can we get the image changed??????? Please help!! Memfit@gmail.com HeatherThomson (talk) 11:43, 1 June 2019 (UTC)

User:HeatherThomson, I believe that the instructions you are looking for are located at Misplaced Pages:Contact us/Article subjects. As your account has been blocked for a possible impersonation attempt, the e-mail option might be the most feasible for you. Whatamidoing (WMF) (talk) 00:25, 2 June 2019 (UTC)