Wikipedia:Village pump (proposals)/Archive 187

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

There is a clear consensus to go forward with the proposal of giving the growth team features to 100% of new accounts and a smaller portion of them receiving the mentorship feature. As this consensus is clear I am closing this now as per Wikipedia:Requests_for_comment#Duration. Barkeep49 (talk) 16:54, 2 March 2022 (UTC)

---

Should the Growth features be given to 100% of new accounts, making them the default onboarding experience for English Wikipedia newcomers? -- MMiller (WMF) (talk) 22:38, 16 February 2022 (UTC)

Introduction (Growth features)

Hi everyone – I'm Marshall Miller, the product manager for the Growth team at WMF. I last posted here in September 2021 with an RfC about giving the Growth features to 25% of new accounts, which was an increase from trialling the features with 2% of new accounts in June 2021. That RfC passed, and the resulting data indicated that the features continue to help newcomers make valuable edits with low revert rates, as well as help them connect with experienced users to get questions answered. After discussing this trial period, community members who have been following closely have agreed that the next step would be this RfC to give the Growth features to all newcomers, making it the default onboarding experience on English Wikipedia. Thank you to the many community members who have participated in discussions about the features and helped put together this proposal!

Specifically, the proposal is to give the Growth features to 100% of new accounts going forward, with a smaller portion of them receiving the mentorship feature.

The reason that the mentorship portion of the features goes to a smaller portion is because of mentorship capacity. About 60 mentors are signed up now. Going forward, as we improve the mentorship tools and more mentors sign up, we'll continue to work with community members on whether to increase or decrease how many new accounts receive mentorship.

I tried to keep this RfC brief -- please see the sections below for additional details!

Background (Growth features)

Over the past four years, the Growth team has been developing a set of features meant to improve the experience for new editors. The goal of our work is to help newcomers make successful first edits, instead of them leaving from frustration or confusion. The Growth features are now on all Wikipedias, without substantial concerns from communities, and have been shown in multiple experiments to increase the engagement of newcomers.

The Growth features include the following:

• Newcomer homepage: a special page with useful actions that newcomers are encouraged to visit immediately after account creation, which they can access by clicking their username at the top of the browser window.
• Suggested edits: a feed of articles that have maintenance templates such as {{Advert}} and {{Underlinked}}. Newcomers can choose topics of interest to filter the feed, like "Fashion", "History", or "Physics".

  

• Mentorship: newcomers are assigned a mentor from a list of experienced volunteers. A pop-up form helps them submit a question to their mentor's talk page using a simple interface. Whereas Adopt-a-user is meant to be an enduring connection for a newcomer, "mentorship" in the Growth features is meant for quick questions.
• Help panel: when the newcomer is editing an article, the help panel is like a collapsible mini-homepage, providing relevant help links and the ability to ask mentor questions.

Results (Growth features)

Since September 2021, 25% of new accounts on English Wikipedia have received the Growth features by default, with 5% of them receiving the "mentorship" portion of the feature (because we did not want to overwhelm the limited numbers of mentors who signed up on this page.) In looking at the data from these past months, we see similar patterns as with the original 2% test (see a data analysis focused on January 2022 here):

• Over 15,000 suggested edits have been completed by about 3,500 newcomers, with a revert rate of 13%. That's substantially lower than the 28% revert rate of newcomer edits in general. You can see these diffs by filtering to the "newcomer task" edit tag in Recent Changes.
• About 1,300 mentor questions have been asked by about 1,000 newcomers. While many of these questions are insubstantial, mentors report receiving a good amount of good faith and valuable questions that they can answer. You can see these diffs by filtering to the "mentorship module question" and "mentorship panel question" edit tags in Recent Changes.

Broader implications (Growth features)

If the Growth features become the default onboarding experience for all new accounts, it might be important for the community to think about updating the various other welcome templates, documentation, tutorials, and help content to incorporate the Growth features. For instance, a tutorial that currently says, "Find some simple edits to get started!" might be updated to, "To get started, visit your homepage by clicking on your username, where you will find some simple edits to do." I don't think that updates like these should block deployment, but could be something to discuss and adapt in an ongoing way.

There are many more details and background to this work, which can be discovered in the project page and talk page. Thank you all for weighing in. I'm looking forward to hearing everyone's opinions and answering any questions.

Discussion (Growth features)

• Weak Support with the tiniest possible reservation that I'd prefer "100% of newly autoconfirmed accounts, upon autoconfirmation" (if so stipulated, my support would be unreserved). Thank you.--
  John Cline (talk
  ) 00:03, 17 February 2022 (UTC)

Would that not rather defeat the whole point if, for four days, a new account user could neither seek the help they might need, nor be guided to make simple suggestions of edits to make via this feature? The RfC already states the evidence has shows that 50% fewer new user edits get reverted from those who have the Homepage enabled than who do not have it, so waiting to be autoconfirmed would be a lost opportunity for newcomers to engage constructively from day one. Nick Moyes (talk) 00:57, 17 February 2022 (UTC)

• Strong support This is a well-thought out tested and proven feature, so anything that guides and helps a new user from the first moment they create their account is to be welcomed. (The Homepage can always be ignored or disabled in Special:Preferences if it's not wanted, too.) Nick Moyes (talk) 01:06, 17 February 2022 (UTC)
• Support the continued rollout of these useful features. {{u|Sdkb}} ^talk 01:10, 17 February 2022 (UTC)
• Support New editors who are not looking to vandalize or cause trouble have a daunting learning path. This can help address that. Schazjmd (talk) 01:15, 17 February 2022 (UTC)
• Support. Looks like your team has been doing terrific work, MMiller (WMF), please pass it on. Best, KevinL (aka L235 · t · c) 01:22, 17 February 2022 (UTC)
• Support we need to help keep new editors since the implementation of Help:Introduction all over that has cause us to lose thousands of new editors. The more the help intro is linked the worst it gets...... hope this works and retains more editors.Moxy-
• Support MMiller and team have been doing a good job here. I would be against limiting it to AC. Nosebagbear (talk) 01:58, 17 February 2022 (UTC)
• Support Yes, I support it.
  talk
  ) 09:42, 17 February 2022 (UTC)
• Support, however I think some things should be improved, for example I got a suggested edit for Luxor Evolved that said it was an easy edit that just required copy-editing. However when going to the actual article the issue is much larger than simply just a copy edit, so improvements need to be made to the rating of suggested edits that factor in the amount of tags on the article to determine the difficulty. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 17:56, 17 February 2022 (UTC)

  Hello @Blaze Wolf -- thanks for thinking critically about the features. Yes, I agree that the way we're suggesting edits right now is rather blunt. Like you discovered, a given maintenance template may not really convey the full extent of the article's needs. In the guidance we give during the edit, we try to tell the newcomer that they don't need to fix the whole article, and even just one small change is valuable. But I agree that a newcomer could easily be intimidated by a weak article.

  Another issue exists in the other direction: sometimes an article will have a maintenance template on it, but the problem has already been fixed without the template being removed. In those cases, the newcomer is confused because they don't see anything to change. We've thought a little about whether to encourage the newcomer to remove the template, or to encourage other more experienced users to review the edit and remove the template.

  As an effort to address both these issues, the Growth team has been working on our newest initiative: structured tasks. The idea is that we could use algorithms to identify articles that have clear issues and then point those specific issues out to the newcomer so they know just what to do for their first edits. We've built two of these suggested edits so far: "add a link" (being tested on 10 Wikipedias) and "add an image" (being tested on 4 Wikipedias). These are going well so far, and I plan to discuss them more on this wiki once they're a little farther along. I would appreciate your thoughts on the talk pages for those projects! MMiller (WMF) (talk) 19:16, 17 February 2022 (UTC)

  @MMiller (WMF): Hello Miller! Glad to see that these issues are indeed being addressed. I will certainly check out those projects and provide any feedback I may have on them. I remember one time I was just looking at the newcomers tasks for an edit to make and saw a copy-edit task that was easy, but when I looked at the article, the issue extended far beyond just copy-editing. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 19:29, 17 February 2022 (UTC)

• Strong Support. These new features really make things much more friendlier and has proved to have benefits. While mentorship features need some additional kinks to be worked out, they will still work perfectly fine at a small fraction. Panini!^🥪 18:00, 17 February 2022 (UTC)
• Support. Firstly, nice work on this one so far. What are the other implications of enabling for 100pc? There are a few templates that you mention that need to be updated. Are there any other pre-works that need to be thought through prior to enabling for 100pc? I see the mentor assignment feature as well. What is our mentor to mentee ratio? Would we be able to keep up with the 4x demand? Also, what are our measures of success? It seems like the revert rate is one measure. Are we adding any metrics around editor sustainability. i.e. how many of these new editors stay on versus dropping-off. Ktin (talk) 18:06, 17 February 2022 (UTC)

  Hello @Ktin -- thank you for looking over the proposal. Regarding the other implications of enabling for 100%, I think we need the eyes of many community members on it so that we can think of everything. As an example, the left navigation menu on desktop has a "Learn to edit" link, which leads to Help:Introduction (I know @Sdkb has been heavily involved in that content), and we would want to think about whether that link should continue to be there, to say what it says, and to lead where it leads. Another aspect is for in-person/virtual events. Edit-a-thons frequently start with, "Okay, everyone create an account!" After this change, all those new account holders will be prompted to go to their homepage to edit, and event organizers will need to be aware of that prompt and decide how they want to address it.

  Good questions regarding mentorship! We've talked about the scalability of mentorship this a lot on this page, but I did not include a lot of detail on it in the RfC so that it remained more focused. Right now, mentorship is only being given to 5% of new accounts because of the limited number of mentors. During the month of January, there were about 50 mentors and they each got about 5 questions per month, which is the load that people seem to feel comfortable with. To scale that up to 100% of newcomers, there would need to be 1,000 mentors, which might require more complex management systems from the community. So we decided that in taking the Growth features to 100% of newcomers, we would increase the share getting mentorship to 10%, and continue to increase (or decrease) as needed while more mentors are recruited and the features improve. Does that make sense?

  Regarding measures of success, there are several things our team looks at. First is the edit count and revert rate, which helps us see whether newcomers are using the features and whether they seem to be making a positive or negative impact on the wikis. But more importantly, we look at "activation" and "retention". "Activation" refers to whether the features cause newcomers to make a first edit when they otherwise would not have. In multiple contexts, the Growth features have been shown to increase this number -- in our most recent experiment on several other Wikipedias, using the experimental "add a link" feature, it increased the chance that a newcomer would make an unreverted first article edit by 17%. And these experiments indicate that "retention" (which you referred to as "editor sustainability") is increased by a similar amount. We're continuing to analyze experiments like these to understand the impact of the features. And finally, a really important measure of success is community reception: do these features fit in with how communities work or are they disruptive? So far, this has gone very well: the features are on all other Wikipedias and none have requested that they be removed. Please let me know if you have any thoughts or ideas! MMiller (WMF) (talk) 19:26, 17 February 2022 (UTC)

  We're on standby to update the

  tutorial series however is needed when this rolls out. The useful links page will need an added line, and we may want to suggest that users try out the suggested edits feature at the start rather than just toiling in a sandbox. Overall, I see separate roles for the tutorial series and Growth features: the Growth features help out newcomers as they're trying to do something, and hopefully do so well enough that there's no need for them to consult a manual. The tutorial, meanwhile, serves as a newcomer-friendly manual for the times when our interface still fails at making a task easy enough to do without aid, plus as a way for particularly eager newcomers willing to devote half an hour or so to learning the ropes to jumpstart their journey. Different people like to learn in different ways—some through experimenting, some through asking questions, and some through reading—and it's good we cater to each. Over time, I hope the amount of things we'll have to cover in the tutorial will shrink as the interface improves. For instance, the upcoming rollout of the Reply Tool will allow us to simplify the talk pages modules. {{u|Sdkb}} ^talk

  19:46, 17 February 2022 (UTC)

• Support. And some questions for you MMiller (WMF) ;) It is very interesting to see the type of edits. Do you have any generalization or write up on the types of edits, and are there any enhancements based on the observations? Looking at the first couple dozen (not a useful sample) I noticed some changes of UK to non-UK spelling, adding an Oxford comma... exactly the kinds of things someone might revert (I didn't check if the page was UK spelling indicated or not) in a way that would turn off a new user... other thoughts on how to guide to a great start? And thanks for the work... Chris vLS (talk) 21:30, 17 February 2022 (UTC)

  Hi @Chrisvls -- thanks for checking out some of the suggested edits! I just want to make sure -- hopefully you did some constructive and valuable edits in the sample you looked at, right? What did you notice about those?

  One of the biggest challenges we've faced in the Growth team's work is this tension: On the one hand, it's important for newcomers to quickly make a valuable edit so that their "wow, I just edited Wikipedia" lightbulb lights up. If they can't make an edit quickly, many of them leave in confusion or frustration. But on the other hand, editing Wikipedia can be so subtle and tricky that they need to learn guidelines and rules before they can do it -- and requiring them to learn before doing turns a lot of people away. The approach we've taken in the past has been to make help materials available from the editing experience via the help panel, but we don't require newcomers to consume it before editing.

  But the approach we're trying now is bolder, which is to guide newcomers step by step through doing a very specific edit. This is the "structured tasks" idea that I mentioned to Blaze in a comment above. We think that if we hold newcomers' hands through their first edits, they'll develop an understanding and respect of our rules and policies. We don't know yet if that hypothesis is being borne out -- we do now that people are doing a lot of these edits and that they're helping people edit who would not have otherwise. We're still trying to figure out if those edits lead to other edits and to learning. Definitely interested in your thoughts on this approach! MMiller (WMF) (talk) 02:53, 18 February 2022 (UTC)

•  Support ― Qwerfjkltalk 21:46, 17 February 2022 (UTC)
• Strong support continued rollout of these wonderful features.
  talk
  ) 21:50, 17 February 2022 (UTC)
• Support: A suggestion:
  Maybe add some other tasks? For example, some maintenance tasks, like anti vandalism. Additionally, I think a link to the task center could be added to the "get help with editing" menu. Finally, could an easy way to turn off the homepage be added? – AssumeGoodWraith (talk | contribs
  ) 04:56, 18 February 2022 (UTC)

  And perhaps a link to the teahouse. – AssumeGoodWraith (talk | contribs) 09:19, 18 February 2022 (UTC)

  One can turn on and off Growth features at the bottom of Special:Preferences#mw-prefsection-personal. And as mentioned above, new tasks are being added to the selection. Sungodtemple (talk) 13:59, 18 February 2022 (UTC)

  Thanks, @Sungodtemple, that's right. @AssumeGoodWraith -- I agree, though, that there is not a clear way to turn off the homepage from the homepage. Which is the part that might cause one to want it turned off? I am thinking it's the part where clicking your username takes you to your homepage instead of to your userpage -- is that right? Because without that aspect, it's just a tab that appears (and is easily ignored) when you are on your userpage or user talk page.

  Regarding the idea of adding different inks to the "get help with editing" menu, this is actually something that we've enabled communities to configure for themselves! Administrators can alter those links from Special:EditGrowthConfig in the "Help Panel Links" section at the bottom. The idea is that communities would discuss which links should go in there, and then make the change, which would affect all users. MMiller (WMF) (talk) 17:02, 18 February 2022 (UTC)

• Support: well-tested, provably effective and few to no drawbacks. We have a much-too-steep learning curve for newcomers and desperately need more volunteers. — Bilorv (talk) 12:09, 18 February 2022 (UTC)
• Support Helpful feature, results look pretty good so far. DanCherek (talk) 12:15, 18 February 2022 (UTC)
• Support increase, certainly an effective feature to help newcomers. As a mentor I would not mind getting more questions from mentees. Pahunkat (talk) 12:30, 18 February 2022 (UTC)
• Support As an event coordinator, I find it confusing when new editors' interfaces behave differently, depending on their experience, preferences and other choices. So, it would be best to get everyone on the same page. As for mentors, it might be better to have these assigned when requested so that the limited pool is not confused and burdened by accounts that are not really serious. The home page might have a button to request a mentor. Andrew🐉(talk) 13:14, 18 February 2022 (UTC)

  Hi @Andrew Davidson -- it's valuable to hear the perspective of an event coordinator. Regarding mentors, you're mentioning an idea that we discussed in this section about how to lower the burden: we're already building a way for users to opt-out of mentorship in case they don't want to have a mentor, or don't like their mentor. What if we defaulted all newcomers to being "opted-out" of mentorship, and required them to click a button to opt-in and "get a mentor"? Here's a mockup of what that might look like. You can see in the conversation that people were divided on whether it would be harmful or helpful to increase the barrier to entry for mentorship. What do you think? MMiller (WMF) (talk) 17:06, 18 February 2022 (UTC)

  The events I support typically have lots of new women editors.  They are usually quite cautious and may scare easily.  It therefore seems best to give them visible control over the mentor feature so that they don't feel that they are being rushed into a subordinate relationship with a stranger against their wishes.  The opt-in button therefore seems appropriate to give a feeling of control and security.   Andrew🐉(talk) 18:40, 18 February 2022 (UTC)

  Seconding this - I think randomly being assigned a mentor can easily be confusing/alarming ("who is this person talking to me?! did I do something wrong?") or feel like an imposition ("I just wanted to make an account idly and now I feel pressured to edit because this mentor is watching me"). But you don't want new people to miss out on this, either, so an extremely obvious DO YOU WANT A MENTOR? CLICK HERE! DO YOU WANT TO LEARN MORE ABOUT MENTORSHIP? CLICK HERE! button on the homepage would be a good idea. -- asilvering (talk) 06:41, 23 February 2022 (UTC)

  This is a good idea, however I feel that it might also cause some harm if the newcomer doesn't actually know what it might do or some other things. That said, this will definitely fix the issue of users signing up for accounts, and then never making a single edit with them. This clogs up the mentor dashboard with a lot of users who won't make a single edit. I feel a better solution might be if a user registers for an account, they're assigned a mentor. IF they don't make any edits after a certain amount of time they might get a notification that says something like, "Having trouble editing? Ask your mentor and they might be able to help you!" and then if they continue to not make any edits whatsoever or ask any questions, then they will automatically be unassigned a mentor and have to click the button again to assign themself a mentor (could possibly be the same one they had previously if that info could be stored somewhere or a new random one). ― Blaze Wolf^Talk_{Blaze Wolf#6545} 18:59, 18 February 2022 (UTC)

• Strong support I've seen firsthand that this really is a great asset to the encyclopedia, and it's probably the click we've needed after a bit of stagnation recently with regard to integrating new users (especially with a huge burst in new users due to the pandemic). I wish this was a feature when I was starting out! Curbon7 (talk) 09:03, 20 February 2022 (UTC)
• Support: I was a guinea pig for the dashboard, and while I don't think it's perfect, it's certainly far better than nothing. It would have been cool to get a mentor too; from the perspective of a newbie editor, this looks like a great feature. Thanks to the growth team for your work on these features! (And for being friendly when I showed up with questions and comments.) -- asilvering (talk) 06:34, 23 February 2022 (UTC)

  @Asilvering: your mentor is Elli; see in Special:Homepage (you may need to enable newcomer homepage in Special:Preferences). — xaosflux ^Talk 01:53, 25 February 2022 (UTC)

  @xaosflux Er, are you sure? There is nothing about that on my newcomer homepage, I never asked for a mentor (indeed, I learned that mentors were even a thing at all by having googled to find the growth team talk page to leave the comments I mentioned in my vote), and I have no idea how you came to this conclusion. -- asilvering (talk) 02:17, 25 February 2022 (UTC)

  @Asilvering that's the the database reports, if you go to Special:Homepage, does it say anything in the top right? Noone "asks" for a mentor, they get auto-assigned. — xaosflux ^Talk 10:11, 25 February 2022 (UTC)

  @xaosflux No, it does not. The modules on that page are "suggested edits", "your impact", and "get help with editing". Where are you finding this database report? -- asilvering (talk) 17:45, 25 February 2022 (UTC)

  @Asilvering Hmmm, maybe one of the growth team people can share more. You can query mentors with {{#mentor:Asilvering}}, which is "Elli" for you. — xaosflux ^Talk 18:16, 25 February 2022 (UTC)

  If you go down to the bottom of Special:Preferences#mw-prefsection-personal is "display newcomer homepage" enabled for you? — xaosflux ^Talk 18:18, 25 February 2022 (UTC)

  @xaosflux Can you please answer my question about where you are finding this database report? I've described what my newcomer homepage looks like, obviously I have it enabled. -- asilvering (talk) 18:31, 25 February 2022 (UTC)

  @Asilvering literally by invoking that #mentor parser function I quoted above, the "Elli" test up there is not text, it is the live output of that parser function. I believe you, but didn't know if you could go to homepage if following the link, while also not having it enabled in preferences. There are several "opt out" tasks open, but I didn't think any of them were live. So, I don't know why you can't see your mentor there. Think there was a typo above, I was trying to say "that's what the database reports", not that there was a 'database report' to read. — xaosflux ^Talk 18:37, 25 February 2022 (UTC)

  @xaosflux Hm, testing this on you out of curiosity: Xaosflux -- asilvering (talk) 18:42, 25 February 2022 (UTC)

  @xaosflux Ok so it's not just randomly picking a mentor for funsies... weird. Well... it would have been neat to know I had one, I guess! But as I've said above I would definitely prefer for it to be an opt-in thing with a very obvious opt-in option. -- asilvering (talk) 18:45, 25 February 2022 (UTC)

  I'm a horrible example, as I claimed myself. I did claim Fluxbot ({{#mentor:Fluxbot}}:Xaosflux) as an example though. — xaosflux ^Talk 18:46, 25 February 2022 (UTC)

  (And I think ITSTHURSDAY broke sameuser:sameuser mentor relationships from working in other ways) — xaosflux ^Talk 18:46, 25 February 2022 (UTC)

  @Asilvering @Xaosflux, regarding mentor/mentees relations, you can check who are someone's mentees by using the API: https://en.wikipedia.org/w/api.php?action=query&list=growthmentormentee&gemmmentor=Xaosflux&format=xml. Trizek (WMF) (talk) 16:42, 28 February 2022 (UTC)

  @Trizek (WMF) That's not terribly helpful for new users who have been mysteriously assigned a mentor but not told anything about it... -- asilvering (talk) 17:42, 28 February 2022 (UTC)

  @Trizek (WMF) please see Wikipedia talk:Growth Team features#Missing mentor? for some follow up on this. — xaosflux ^Talk 17:45, 28 February 2022 (UTC)

  @Asilvering @Xaosflux, I was multi-tabbing and I apparently posted half of my reply. Sorry. :/ Here is the missing (and most interesting) part: "as only 5% of newcomers get the mentorship module, it may have impacted some people who turn it on manually (even if it is unlilely to happen). I will ask the team about it." I'll keep you posted at Wikipedia talk:Growth Team features#Missing mentor?. Trizek (WMF) (talk) 17:55, 28 February 2022 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Can We add

I don't think so since it's not an image and the template is being considered for deletion. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 15:16, 28 February 2022 (UTC)

•  Comment: This IP range (bn:Special:Contributions/103.230.104.0/22) is blocked in Bengali Wikipedia due to long term abuse (personal attack + sock of User:Lazy-restless). —Yahya (talk • contribs.) 21:42, 2 March 2022 (UTC)

  @Yahya: Ah interesting. Not sure if there's much we can do here on enWiki since they haven't made any edits since this one and to my knowledge we can't use CU to connect IPs to accounts. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 23:22, 2 March 2022 (UTC)

Propose to limit or cluster citations from the same author, university department or research center.

Pages having different papers on the same research topic from the same author should be clustered or limited. RS consisting of the same conclusion or narrow variences of it from the same author should be treated as a single reference.

Why? Inflating the RS count prevent good faith discussion on changing an article. A conclusion repeated in three papers from three years is one conclusion that should not block changing a page based on one new RS. — Preceding unsigned comment added by 2600:1700:D591:5F10:9998:5F2A:1AD7:F946 (talk) 01:16, 3 March 2022 (UTC)

It is not a good idea to artificially limit citations that support wikitext claims just because they are from the same author or work. Assuming this is not about single-source (or almost-single-source) articles, but such can be tagged now. It is incumbent on editors to provide additional supporting sources if they exist, but this is not an obligation. It is also incumbent on editors to add contrary wikitext claims and the citations to support them.

The second paragraph is better. Authors may have an area of expertise and associated conclusions they reinforce in work after work. The final real-world source in all citations is the author, so one may see multiple such citations as coming from a single source. But this again is not a citation issue. Citations exist to support wikitext claims. That's all. What you propose falls under NPOV and balance which are wikitext, not citation issues. 71.247.146.98 (talk) 13:54, 3 March 2022 (UTC)

Hi everyone, as you may remember there were two discussions in the past [5][6] about portal links on the main page which were inconclusive, mainly because of deficiencies in the proposals. To move this discussion forward, I thought that a workshop about how an adequate proposal should be drafted and formatted could be useful. I have created User:JBchrch/Portal links on the Main Page: RfC Workshop for this purpose. Anyone with an interest in this topic is more than welcome to contribute and comment. JBchrch talk 23:29, 12 March 2022 (UTC)

Numerous pages about individual books have quotes from the book’s dust jacket. These are biased and unreliable due to cross promotion of the commentator being a fellow author usually for the same publisher.

These promotional commentary should be removed from wikipedia.

Music pages, Devo Satisfaction song, should have these promotional comments removed also. Mick Jagger states thst Devo cover of the Rolling Stones Satisfaction is the best cover of that song. He would of course promote the cover since half of the sales of the cover go to the original artist, Mick Jagger.

Films such as Kirk Douglas quote praising his-son’s Falling Down film should be removed for the same reason.

Lastly, removing quotes from book introductions should be done since the introduction writer is paid to praise the book’s content. For anthologies, the introductory paragraph for a story is also promotional.

Suggest a Wikipedia tag for this self or cross promotional to be WP:CrossPromotional as distinct from outright advertising. — Preceding unsigned comment added by 2600:1700:D591:5F10:9998:5F2A:1AD7:F946 (talk) 00:44, 3 March 2022 (UTC)

Although such quotes should not be used to support notability, not everything quoted from a book etc. jacket is promotional. Sometimes people involved in the book production are only credited on the cover. Music works credit personnel, and include tracklists. Even the promotional info (publisher annotations, liner notes etc.) may contain citable information if they are the explicit subject of wikitext. 71.247.146.98 (talk) 13:12, 3 March 2022 (UTC)

I agree with 71.247.146.98 on this one, I think it's really up to user discretion to decide whether a quote from a dust jacket is worth quoting or not. Maybe this could get some sort of tag or be added to something like WP:CrossPromotional like you said, but it shouldn't be outright banned in my opinion. Tolozen (talk) 06:19, 8 March 2022 (UTC)

There needs a way to can mark a reference as stale needing an updated one.

Pages frequently have twenty year or older references in the first few paragraphs outdated omitting recent definitions of the page topic.

In the sciences and history pages this excludes recent research defining the topic by blocking new research from inclusion in the page top section.

It advantages the second generation of scholarly research to balance the first generation researchers work. For example, the first biography of a living president, one from just after death and onrpe from twenty years later when policy has run its course. — Preceding unsigned comment added by 2600:1700:D591:5F10:9998:5F2A:1AD7:F946 (talk) 01:01, 3 March 2022 (UTC)

You may have it backwards. If there is new material information about an article, the article can be edited and new citations should be added to support the edits. If this information necessitates the removal of older text, and that may depend on the way the article is structured, then the citations supporting the no-longer valid text should be removed. Sources are not "stale". The wikitext depending on them may be. 71.247.146.98 (talk) 13:02, 3 March 2022 (UTC)

If things have radically changed such that the old information is now incorrect then in many (probably most) cases there should be a history section that documents this and those old sources can be used to support that. If the old sources are not incorrect then why do you want to remove them? Thryduulf (talk) 16:41, 3 March 2022 (UTC)

• There is a template that says "This article needs to be updated" that heads the article
  Diabetic diet. If you think the references in an article are out-dated, you could make a request to have this template heading the article. YTKJ (talk
  ) 22:31, 8 March 2022 (UTC)

Note: This might not technically be a proposal, but I hope you'll excuse me posting here; I'm doing so in an attempt to make sure lots of people are aware of this upcoming change.

---

Hi y'all – the Editing Team is planning to offer the Reply Tool as an opt out feature to all people – logged in and out – at en.wiki this upcoming *Monday, 7 February 2022*.

The "Deployment Rationale" below is what's leading us to think now is a good time to move forward with this deployment. If this idea brings any concerns/questions to mind, we would value you sharing those thoughts so we can talk about them.

And for people curious about the work the Editing Team will continue doing to improve the Reply Tool, please see this update.

Note the 7 February deployment only pertains to the Reply Tool, NOT the New Discussion Tool (setting name: enable quick topic adding) or Topic Subscriptions (setting name: Enable topic subscription).

PPelberg (WMF) (talk) 22:12, 1 February 2022 (UTC)

EDIT: to clarify, this deployment only impacts people (logged in and out) using talk pages on the desktop site. Said another way: this deployment would have NO IMPACT on people (logged in and out) using talk pages on the mobile site. PPelberg (WMF) (talk) 04:30, 3 February 2022 (UTC)

Deployment Rationale

The Editing Team has the impression that now is a good time to offer the Reply Tool as a default at en.wiki based on the following:

• People do not seem to have any significant concerns about the Reply Tool being offered more broadly.^[1]
• The Reply Tool is reliable. Over the past 30 days, 99.9% of the 14,000+ comments 800+ people posted with the tool at en.wiki did not impact any other parts of the talk pages it was used on.^[2]
• Many people have confidence in the Reply Tool. At en.wiki, 2,800+ people have used the Reply Tool to post at least one comment since the tool was offered as a beta feature on 16 March 2021.^[3] And of these 2,800+ people, 25% have used the Reply Tool to post 10 or more comments.
• While there is additional functionality that could A) increase the range of comments people can use the Reply Tool to publish (e.g. votes^[4] and unindented comments within existing discussions^[5]) and B) expand how expressive the tool enables people to be (e.g. stronger template support^[6] and signature customization^[7]), we do not currently understand the implementation of these additional capabilities as needing to prevent people who are new from benefiting from being able to post comments more intuitively and for the comments they post being signed and indented in ways experienced volunteers expect and value.

PPelberg (WMF) (talk) 22:13, 1 February 2022 (UTC)

• @PPelberg (WMF): just to be clear, this going to be only the "Reply tool", not the entire suite of "Discussion tools" from beta preferences? — xaosflux ^Talk 02:07, 2 February 2022 (UTC)

  I'm glad you asked to clarify, @Xaosflux.

  Yes, the deployment planned for Monday, 7 February 2022 only pertains to the Reply Tool, NOT the New Discussion Tool (setting name: enable quick topic adding) or Topic Subscriptions (setting name: Enable topic subscription).

  I've updated the original post to make the above explicit. Please let me know if you notice any other ambiguities. PPelberg (WMF) (talk) 02:33, 2 February 2022 (UTC)

  I'm not seeing the discussion from the first citation; could you link to a specific section there?

  Overall, deployment sounds good to me. This will help make a lot of editors' lives easier! {{u|Sdkb}} ^talk 08:27, 2 February 2022 (UTC)

  Oops. Good spot, @Sdkb. Here is a link to the discussion I meant to reference in the "Deployment Rationale": Wikipedia:Village pump (miscellaneous)/Archive 68#Radical changes. PPelberg (WMF) (talk) 19:43, 2 February 2022 (UTC)

• Generally, I think this is the right direction to head—ever since Enterprisey developed his version of a "reply link" tool way back when, I have long been excited at the prospect of deploying this in a widespread format to help new editor engagement. With that being said, I would be mindful that this would be a relatively significant new feature in the editing interface, and some past rollouts of similarly significant new features have led to tension between the WMF and the English Wikipedia community (see e.g. Wikipedia:VisualEditor/RFC and Wikipedia:Arbitration/Requests/Case/Media Viewer RfC). I don't think the Reply tool is quite as invasive as VisualEditor and Media Viewer were, but because of those dark memories, I would be inclined to more broadly advertise to experienced editors that this change is going to occur—specifically, I'm thinking in MediaWiki:Watchlist-messages. Maybe this is overkill, but the English Wikipedia community can sometimes be really passionate against these software changes, particularly when they have the appearance of being performed without their consultation or consent. I've been using the Reply tool for a while now, and it is quite good—I just hope others see it the same way. Mz7 (talk) 09:43, 2 February 2022 (UTC)

  Thanks for the shoutout! I agree with everything you said. I guess it may seem like a silly step (and I think it sort of is). But we should definitely hold an RfC of some sort if we've learned from the history of this sort of thing. It doesn't even have to be that long (a week?) or laborious.

  PPelberg (WMF) and the team, thank you so much for all your hard work on this! I've been waiting for this day for a long, long time. Would it be possible to get links to some of those "suspicious" edits (I'm assuming that's what "sus" means in that table)? I really appreciate the inclusion of the table in the first place. Enterprisey (talk!) 10:34, 2 February 2022 (UTC)

  @Enterprisey, click the date for the column you want. Every suspicious edit is on the day's page. The most recent was this removal of a stray HTML tag, two days ago. Whatamidoing (WMF) (talk) 17:27, 2 February 2022 (UTC)

  Thanks @Enterprisey, it was helpful to pick your brain in the early stages of the project! ESanders (WMF) (talk) 17:39, 2 February 2022 (UTC)

  +1 to what @ESanders (WMF) shared above: thank you @Enterprisey for inspiring the Editing Team and passing on knowledge that's helped make the Reply Tool something many people use and value. PPelberg (WMF) (talk) 00:41, 3 February 2022 (UTC)

• @PPelberg (WMF): we may at least post a note somewhere like our watchlist header when it goes live to help head off any "what's this" confusion posts. That being said, probably should have 2 targets ready: (a) the location any issues should be reported; (b) a description/help page of the new feature (which should include the opt-out directions). mw:Talk pages project/Replying isn't really a good landing page for either of those - it is more of a project tracking page. Are there better targets ready somewhere? — xaosflux ^Talk 11:14, 2 February 2022 (UTC)

  @Xaosflux, there's mw:Help:DiscussionTools, which could be copied here. (Everything in Help: namespace at mw.org is public domain/CC-0, so you don't even have to worry about licensing attribution.) It might make more sense to put the section about the Reply tool in Help:Talk pages than to create another extension-specific page.

  The exact link for opting out is Special:Preferences#mw-prefsection-editing-discussion, and you could run that in the watchlist notice itself. In practice, I expect editors here to report problems to Wikipedia:Village pump (technical) no matter what we tell them, but mw:Talk:Talk pages project/Replying (i.e., its talk page) is a good "official" option.

  That said... it's already default-on for about half the editors in the movement. Across hundreds of wikis, I've seen about five requests for information on how to disable it and almost no bug reports. There have been some feature requests (e.g., support for voting-style discussions) and questions (e.g., why doesn't it recognize this editor's non-standard signature, or work on this page with a colored background?). Someone even wrote a quick user script (check the VPM archives; I copied it here) to change "[reply]" into the emoji or word of your choice. This experience suggests that we probably won't get that many questions, especially after the first day or two. Whatamidoing (WMF) (talk) 17:22, 2 February 2022 (UTC)

  @Whatamidoing (WMF): thanks for the note, I don't think we need to advertise the opt-out controls in any banners, just wanted to have somewhere to point editors, and have that page include the opt-out directions (not to the page mw:Talk pages project/Replying itself). — xaosflux ^Talk 18:12, 2 February 2022 (UTC)

  You could put it in the local Wikipedia:Talk pages project. Whatamidoing (WMF) (talk) 22:54, 2 February 2022 (UTC)

@Whatamidoing (WMF): -- just so I know (because I hate change) how do I opt out? -- Rockstone^{Send me a message!} 08:10, 3 February 2022 (UTC)

@Rockstone35, you'll just go to Special:Preferences#mw-prefsection-editing-discussion and turn it off. Whatamidoing (WMF) (talk) 21:56, 3 February 2022 (UTC)

• I'm thinking a watchlist notice would be good on launch day, something like:

{{Display/watchlist
 |until= 10 DaysFromNowMonth 2022
 |cookie=n
 |text=The [[Wikipedia:Talk_pages_project#Reply_tool|'''Reply tool''']] from the talk pages project has been enabled for all editors.  Should you have any issues or feedback, please [[Wikipedia talk:Talk pages project|let us know]].
}}

• Any feedback on this wording is welcome! — xaosflux ^Talk 01:12, 3 February 2022 (UTC)

  Making the reply tool opt-out is a big step for beginner friendliness. Wording should be this imo (with relevant links):
  "The talk page reply tool has been enabled for all editors. If you spot any issues or have any feedback for the Talk Pages project team, let us know at our talk page" ✨ Ed talk! ✨ 03:43, 3 February 2022 (UTC)

• @PPelberg (WMF): Does "all people" include mobile editors (logged-in and logged out)? Suffusion of Yellow (talk) 04:08, 3 February 2022 (UTC)

  @Suffusion of Yellow good question. The deployment currently planned for this upcoming Monday will only impact people – logged in and out – who are accessing the desktop site.

  I'm going to update the original post I made to clarify this. PPelberg (WMF) (talk) 04:26, 3 February 2022 (UTC)

  Out of interest — why not mobile? — GhostInTheMachine ^{talk to me} 20:49, 3 February 2022 (UTC)

  @PPelberg (WMF): Any idea how long it will take to bring this to mobile? The current mobile talk interface is fundamentally broken and no one seems interested in fixing it. Suffusion of Yellow (talk) 23:31, 3 February 2022 (UTC)

  hi @Suffusion of Yellow – the mw:Editing Team is planning to offer both the Reply and New Discussion Tools on mobile at an initial set of wikis within the next month or so (you can track progress on this work by following along with phab:T282638).

  I appreciate the level of expertise you've developed around mobile talk pages. If at any point you become motivated, I'd value hearing what – if any – questions/ideas you have about the broader set of mobile talk page challenges we are planning to address. PPelberg (WMF) (talk) 02:35, 4 February 2022 (UTC)

  @GhostInTheMachine good question. This deployment does not include the Reply Tool being made available on mobile because we are still refining the user experience for it. We will have a prototype ready to share soon, would you be interested in trying it out and sharing what you think about it?

  Also, in case you're interested in the broader set of changes we have planned to improve mobile talk pages, I recommend reading mw:Talk pages project/Mobile. If/when any other questions emerge about mobile, please do ping me! PPelberg (WMF) (talk) 02:22, 4 February 2022 (UTC)

• A tad short-notice for general awareness of rollout, but I've been using it on meta to get used to it, and it's significantly improved from even 3 months ago - especially in its tolerance to the most common thing I did to break it, which was adding ping templates as the first thing in the message. I think the first week will be a bit of a mess, but the general gain will be significant. Nosebagbear (talk) 09:50, 3 February 2022 (UTC)

  @Nosebagbear, I believe this is at least the fourth announcement so far; see Wikipedia:Village pump (miscellaneous)/Archive 68#Radical changes andWikipedia:Village pump (technical)/Archive 192#Tech News: 2021-38. I think the first conversation was last February (before Ops said no, which forced a multi-month delay), and there have been minor mentions off and on, such as at the end of this massive thread about topic subscriptions. As you can tell, though, even multiple discussions don't reach everyone. Whatamidoing (WMF) (talk) 22:17, 3 February 2022 (UTC)

• As someone who is not at all tech savvy… please explain what this is and what it is attempting to accomplish - using non-tech language. Don’t assume people know what you are talking about. Blueboar (talk) 00:24, 4 February 2022 (UTC)

  It adds a little reply link after talk page talk page posts that you can click on to reply to that particular message. It opens a small editing window below the message you're replying to, so you can reply without loading a new page. ScottishFinnishRadish (talk) 00:34, 4 February 2022 (UTC)

  @Blueboar below is a screenshot of the Reply Tool in case a visual is helpful

  

  . You can also find more details about the tool by visiting this help page. PPelberg (WMF) (talk) 02:18, 4 February 2022 (UTC)

Alright y'all: it's been a couple of days since this discussion started and we thought it would be helpful to articulate the information that has surfaced in the discussion thus far. This way, we can collectively decide what happens next with this deployment with a shared set of ideas in our minds.

New Information

1. People are supportive: Everyone who has commented in the discussion thus far is supportive of the Reply Tool being offered as an opt-out feature, for all users (logged in + out), on desktop
2. Awareness is important: A significant number of volunteers who have commented in the discussion agree (and so do we!) that it would be wise to make as many people aware of this change as possible, ideally ahead of time. ^{[1] [2] [3] [4] [5]}
3. Announcement needs some more thought: There does not yet seem to be an agreement about what the most effective way(s) are of making people aware about the Reply Tool being made available as an opt-out feature on desktop.

*Please comment if you do NOT think aspects of the above are accurate. It's very possible I missed and/or misunderstood something someone said!

Next steps

With the "New Information" above in mind, I'm going to ping a few other folks who have been involved in testing and providing feedback about the Reply Tool^[6][7] to hear what they have to say...

@DannyS712, @Doug Weller, @JohnFromPinckney, @Klein Muçi, @Levivich, @Nick Moyes, @Pelagic, @ProcrastinatingReader, @Thryduulf, @Qwerfjkl: in this discussion we are talking about making the Reply Tool available as an opt-out feature for logged in and logged out users on desktop next week.

As people who are experienced using the Reply Tool at en.wiki^[7], we wonder: what do you think might be effective ways for making the wider en.wiki community aware of this Reply Tool deployment? PPelberg (WMF) (talk) 03:06, 4 February 2022 (UTC)

A question and a couple of comments before as head into the weekend...

Question

@Ed6767, @Enterprisey, @GhostInTheMachine, @Mz7, @Xaosflux: as people who have said this deployment would benefit from many people being made aware of it ahead of time, how do you think this announcement or announcements ought to be made? Would an RfC be valuable? Would a MediaWiki:Watchlist message be effective? Might making more posts on pages experienced volunteers are likely to visit (e.g. a couple relevant noticeboards, Village pump (technical) as @Whatamidoing (WMF) has done) be the best approach? Some combination of these options?

Comments

A couple of thoughts about what the mw:Editing Team is thinking...

• We agree with you in thinking that it's worthwhile to make as many people aware of the change before it happens as possible.
• We think the deployment date ought to depend on people having enough awareness that it's happening. Said another way: we are committed to revising the deployment date to leave more time for making people aware, if that ends up being necessary.

Next step

At around 16:00 UTC this Monday, 7 February, I'll check back in with you all so we can decide whether we move forward with the deployment on Monday or push it back a few days to execute the plan y'all might've come up with over the weekend.

Please ping me if anything urgent comes up; I plan to check back in on this discussion at least once over the weekend. PPelberg (WMF) (talk) 01:44, 5 February 2022 (UTC)

My only advice is “think in terms of next month rather than next week”. We here at enWP do not like surprises, and we tend to knee jerk reject things when surprised. So go very slowly with the role out. Announce the crap out of it - in as many different forums and formats as you can think of. Give people time to get used to the idea before you go live with it. Blueboar (talk) 02:53, 5 February 2022 (UTC)

It has been published in the administrator newsletter which means that a large proportion of active admins, and a number of non-admin editors have seen the announcement through that newsletter. Dreamy Jazz ^{talk to me | my contributions} 23:56, 5 February 2022 (UTC)

@Blueboar, @Dreamy Jazz, and @Pelagic: we appreciate you thinking through the question I posed about how best to make people aware of the planned deployment of the Reply Tool.

Considering it is still not clear to me, and other members of the Editing Team, whether y'all (all of the volunteers who have participated in this discussion to date) think an RfC for this kind of change is necessary, in the immediate-term, we are delaying today's (7 February) planned deployment of the Reply Tool.

Next step(s)

You can expect to see another comment from me before 5:00 AM UTC (8 Feb) with a proposed next step or steps.

Of course, if any new thoughts/questions emerge between now and then, we would value you sharing them.

cc @Ed6767, @Enterprisey, @GhostInTheMachine, @Johnuniq, @Dreamy Jazz, @Blaze Wolf. PPelberg (WMF) (talk) 20:46, 7 February 2022 (UTC)

Alright y'all, people in this discussion seem to agree:

1) Some volunteers are bound to be surprised by this change, no matter how many announcements are made

2) "1)" notwithstanding, it's preferable the Reply Tool deployment be delayed until more announcements are posted

Next steps

With the above in mind, what do you think of doing the following?

• @
  CENT
  ?
• @Xaosflux: are you able to finish the work required to ensure the Reply Tool opt-out deployment is included in the watchlist banner?

And then we can all come back together to talk about the deployment timing once we see what people say in response to the announcements Enterprisey and Xaosflux will have posted. PPelberg (WMF) (talk) 01:37, 8 February 2022 (UTC)

@PPelberg (WMF): the WL notice is ready to go whenever this is ready to launch, just change the answered=yes to "no" at MediaWiki_talk:Watchlist-messages#Reply_tool_coming to enqueue it for processing. — xaosflux ^Talk 02:00, 8 February 2022 (UTC)

@Xaosflux ah, I see – thank you for sharing the link to the draft message. Although, what do you think about running the Watchlist message before the actual deployment?

...I ask the above thinking that people in this thread seemed to have agreed that making people aware of the deployment ahead of time is likely to be more impactful than waiting until after it's already happened. This way, people have an opportunity to raise any concerns. PPelberg (WMF) (talk) 20:22, 8 February 2022 (UTC)

@PPelberg (WMF): we certainly could do either or both, we generally only put something with a ready to go "call to action" in the watchlist, in that example it would be a "here is what this new thing is, tell us here of any issues". As far as a "before" goes, what is the call to action - if this is going to be a "proposal" that requires community consensus - then it seems big enough to advertise on WLN, a RFC section should be opened below that people can go to to participate in such a discussion. Has this evolved from a "the server owners are doing this thing" to a "should we do this thing" discussion? — xaosflux ^Talk 22:17, 8 February 2022 (UTC)

...we certainly could do either or both...

@Xaosflux: making announcements before and after the deployment sounds like a great idea to me.

Has this evolved from a "the server owners are doing this thing" to a "should we do this thing" discussion?

This discussion has made three points clear to me [i]:

• All of the volunteers who have commented in this discussion thus far agree deploying the Reply Tool as an opt-out feature is a good idea
• Many of the volunteers who have commented in this discussion agree there is value in announcing this deployment widely ahead of time
• There does not seem to be a clear consensus among the volunteers who have commented in this discussion whether a formal RFC is necessary

Combining the three points above with the fact that we are not yet aware of any objections to the Reply Tool deployment plan, I see the objectives of the "pre-deployment" Watchlist announcement as being to ensure experienced volunteers are aware of: A) An upcoming change to the experience they have using talk pages on desktop and B) Where they can go to voice any question/concerns about said planned change.

So maybe the messages end up looking like this...

Before: "The talk page reply tool will soon be enabled for all desktop editors. Should you have any questions or concerns about this deployment, please join the discussion at Village pump (proposals)."

After: "The talk page reply tool has been enabled for all desktop editors. Should you have any issues or feedback for the Talk Pages project team, please join the discussion at the project talk page." [ii]

...what do you think?

---

i. Please comment if you see anything missing from, and/or inaccurate within, the three points I articulated above!

ii. This is the same message you've already written. PPelberg (WMF) (talk) 02:49, 9 February 2022 (UTC)

This is a good message, and I would be happy to have this added to the watchlist. Dreamy Jazz ^{talk to me | my contributions} 20:47, 10 February 2022 (UTC)

@PPelberg (WMF): seems fine, once a launch date is determined maybe we activate the WLNotice a week ahead of time, let it run for a week after - and include the launch date in the message. Is there a new target launch date? Banner blindness is a thing, so don't want to summon editors to a discussion where no decisions are going to be made. If this is going to be a traditional process, then sure we do one early. Traditionally we'd open a RFC, for about a month, get comments, determine the results, then proceed if there is established support; in general the "default" for changes is status-quo. — xaosflux ^Talk 10:28, 9 February 2022 (UTC)

I am going to say that I've only noticed one issue with the reply tool and i Have no clue what causes it or if it can still happen. For whatever reason, in the past some sections people created couldn't be found by the reply tool with no real reason as to why. I don't remember where this was happening or who the users were that were causing this to happen, however it appears to be very rare. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 03:10, 4 February 2022 (UTC)

Hmm, the issue you are describing @Blaze Wolf sounds curious and elusive. I wonder if any of the cases described on this page could help explain what you experienced... PPelberg (WMF) (talk) 03:19, 4 February 2022 (UTC)

Could you explain what "a bug in Parsoid causing it to render the page differently from the PHP parser" means in layman's terms? ― Blaze Wolf^Talk_{Blaze Wolf#6545} 03:30, 4 February 2022 (UTC)

That's not relevant and is a distraction. You are being asked whether the explanation given at that link might match your experience. The explanation is saying that certain listed factors might cause "Could not find the comment..." and if those do not apply, the software might have a bug. If the latter, they would like a report including a permanent link to the page involved along with a description of exactly what you did and what you saw. The "file a task" is an overly optimistic request that you can ignore. Instead, post your findings here or at any noticeboard such as

WP:VPT and someone will notify the appropriate people. Johnuniq (talk

) 04:32, 4 February 2022 (UTC)

Geez dude. I was merely asking so I could try and understand what it means. If I can't ask questions here then I can go. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 13:51, 4 February 2022 (UTC)

@Blaze Wolf, would you please post that question either at Wikipedia:Village pump (technical) or at Wikipedia talk:Talk pages project? The next question will be whether you get this error message when you click the [reply] button, or when you've typed your comment and are ready to post it. Whatamidoing (WMF) (talk) 20:12, 4 February 2022 (UTC)

Blaze, the core MediaWiki software that renders wikitext to HTML is written in the PHP programming language, but it's a one-way conversion. There is another component called Parsoid that can do two-way, and Reply Tool uses it because ... reasons. Visual Editor also uses the Parsoid service. (Apologies to all the technical peeps reading my mangled explanation.) ⁓ Pelagic ( messages ) 12:21, 6 February 2022 (UTC)

This is a visible change. The reply links positioned after every post aren't exactly an obscure UI element tucked away in a toolbar. Will this flip the setting for everyone who hasn't already turned it on then off again? People will notice and say "why weren't we asked?"

Any RFC or banner should run before changeover, not after. Even if it means we have to wait another fortnight or month. Putting it up after the fact would be a very bad look.

On the plus side, a lot of people are already familiar with Discussion Tools thanks to years of fantastic consultation and outreach from Peter and WAID. But enwiki is a big place and we might be surprised to discover how many people still didn't know.

. ⁓ Pelagic ( messages ) 11:00, 6 February 2022 (UTC)

No problem, @Pelagic. The exact date is not important to the Editing team, so if you all think we need to delay, then that's okay. Just please come to some agreement about what should be considered "enough".

To give some context, back in 2013, I personally posted announcements about the visual editor to more than 100 pages at the English Wikipedia, it had been discussed in the village pumps for months, the team ran CentralNotice banners in multiple languages for two straight weeks ...and many editors were still surprised. I remember one person saying that she had been on vacation for the exact 14 days that the banners ran. Most of us in this discussion have probably also seen CENT-listed RFCs that are claimed later to have not been well-advertised enough, because 99% of editors don't follow RFCs or CENT, and they sometimes regret that they missed important discussions. I have also seen an editor participate at length in a discussion about a proposed change, and later ask why there had never been any discussion about that change. All of which is to say: no amount of effort can completely prevent surprises. The English Wikipedia is too big for everyone to know about everything, and we have too much to keep track of to remember even the things we do talk about. I expect that most editors will consider the Reply tool to be a pleasant surprise, but I do expect its appearance to surprise a substantial number of editors no matter what we do or when we do it.

Offhand, in the past few months, I know that this tool and its deployment has been mentioned in at least three village pumps, Wikipedia:Talk pages project (but only ~20 active editors watching that page), the Wikipedia:Administrators' newsletter, and at least two issues of m:Tech/News. What else do you want to add to that list? Whatamidoing (WMF) (talk) 05:55, 7 February 2022 (UTC)

I feel your frustration, Whatamidoing. In my imaginary ideal world there would be a formal RFC that, for once, could come down clearly in favour of change, because of all the great community work you have already invested, and because this is a feature that I believe most people deem beneficial. There's a danger it could get bogged down in "no consensus", which would be a saddening demonstration that participatory decision-making doesn't scale, and that enwiki is something like Conway's Game of Life where interactions are localised to small scale but cause surprising ripples.

As to choice of channel, I almost wrote earlier something like "hey, why not go all out and run a mw:CentralNotice banner, rather than just a watchlist banner or a WP:Centralized discussion listing?" Not knowing that you had been through that before.

Personally, I'd be wouldn't mind if you turned it on tonight. Maybe there's nothing more you can do to influence the amount of pushback. As you say, how much is enough? ⁓ Pelagic ( messages ) 14:17, 7 February 2022 (UTC)

I'm sure that the product manager would be willing to wait for an RFC, but the number of times volunteer-me has had conversations along the lines of "There should've been an RFC! – There was an RFC last month; here's a link to it – But there should've been an RFC!" leaves me doubtful that even that would work.

For clarity, I really do want as little surprise as possible. I am just not certain that we can materially shift the needle on that with any non-disruptive means. Whatamidoing (WMF) (talk) 16:48, 7 February 2022 (UTC)

I think that makes a lot of sense. I agree that having a up-or-down vote on the matter is probably not productive. Maybe we should give it a week with a T:CENT banner plus a watchlist notice? Enterprisey (talk!) 22:22, 7 February 2022 (UTC)

I understand there are those who are suspicious of change, and can find it hard to adapt. Nonetheless, the visual change being proposed is a brief string of text added to the end of comments. Editors remain free to add comments the same way they always have and ignore the new link. I think it's overkill for there to be a large-scale RfC on the matter, absent any indication that there is in fact a significant proportion of editors who object. As an example: once upon a time, the section edit link was right justified. A number of editors raised complaints when it was changed. I could be wrong, but I don't get the sense that it continues to be a simmering irritant to this day. isaacl (talk) 22:40, 7 February 2022 (UTC)

Locations notified

I'm adding in this sub-section so we can bullet-list all those places notified of the Reply tool rollout. Nick Moyes (talk) 22:53, 8 February 2022 (UTC)

• The change to default-on has been announced at the Teahouse: Special:Permalink/1070670917#Another Announcement: Reply Tool roll-out imminent, Special:Permalink/1070697461#Reply tool might get here soon by Nick and GGS. ⁓ Pelagic ( messages ) 20:17, 8 February 2022 (UTC)
• Help:Talk pages has had a new section on the Reply tool inserted (see here) (Please don't alter the section heading until rollout has finished, as other pages are now being linked to it).
• Help talk:Talk pages has been notified of the addition (see here). Nick Moyes (talk) 22:53, 8 February 2022 (UTC)
• WP:Help Desk on 8th February. Nick Moyes (talk
  ) 23:26, 8 February 2022 (UTC)
• Wikipedia talk:Teahouse informed of delayed rollout. (see here). Nick Moyes (talk) 23:39, 8 February 2022 (UTC)
• Help talk:Introduction to talk pages/1 informed of future rollout (see here) Page is too basic to talk about something that isn't yet visible to users. Nick Moyes (talk) 00:01, 9 February 2022 (UTC)
• Wikipedia:Administrators' noticeboard informed (see here). Nick Moyes (talk) 00:09, 9 February 2022 (UTC)

I'm adding in this sub-section so we can bullet-list all those places notified of the Reply tool rollout.

@Nick Moyes what a great idea! PPelberg (WMF) (talk) 02:20, 9 February 2022 (UTC)

• User talk:Jimbo Wales notified a few days ago. ― Qwerfjkltalk 07:16, 9 February 2022 (UTC)

Reply tool next steps

Hi everyone, I really don't want to see a foundation (or developers) vs community fight here on what seems to be a small feature.

This discussion has kind of gone sideways - let's get back on track. The way I see it there are only two good options:

1. (HARD BLOCK) This new software deployment should be blocked on community consensus; we hold a normal RFC to get there. (Let's not pretend only the "deployment date" is under discussion - as "never" could be the result). Noting that such an RFC could spin in to debates about opt-out vs opt-in, new editors vs existing editors, default option, ip editor option; carefully setting up the RFC may help guide it.
2. (Gamma Test period) This is an advisory announcement only. A target date with some lead time is advertised. Anyone with concerns is invited (by way of notices) to test the feature (which AFAIK is not 'easy' to test in isolation?) - however deployment will be delayed if there are open bugs (not feature requests) in phab (link to what parent task should be used).

If the external-to-the-communty groups are willing to push forward (as almost all other software improvements are processed), then I suggest #2 is the way to go. My only concern with #2 is that it seems "tricky" to get people to test this, because the directions are to use a beta option which enables an entire suite of tools, not just this one.(Let me know if I'm missing something?) Directions for how to see the results of the change can be provided.

Thoughts? — xaosflux ^Talk 15:55, 9 February 2022 (UTC)

Discuss (Reply tool next steps)

Testing options? — xaosflux ^Talk 16:53, 9 February 2022 (UTC)

@Xaosflux: You can enable each beta feature individually. Yes you will still be enabling all discussion tools, however I don't see that as being a big of an issue. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 15:58, 9 February 2022 (UTC)

Indeed, you can enable the beta feature at Special:Preferences#mw-prefsection-betafeatures, and then disable the individual tools at Special:Preferences#mw-prefsection-editing-discussion. If you disable everything there except for "Enable quick replying", you'll see exactly what is proposed to be deployed as opt-out. Matma Rex talk 16:44, 9 February 2022 (UTC)

@Blaze Wolf and Matma Rex: thanks for the note! So yes, for #2 the "tester" directions would just be "Enable the Beta feature", "Only enable Enable quick replying". — xaosflux ^Talk 16:50, 9 February 2022 (UTC)

Just so you know, I myself would prefer #2. #1 makes it seems like this entire process of notifying people ahead of time was a complete waste if the software deployment were to be blocked by the community with the option for it to never be deployed. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 18:36, 9 February 2022 (UTC)

Personally, I think #2 is OK in this use case, but having been around to see mediaviewer, visualeditor, and flow deployment problems respect that the community could be wary. — xaosflux ^Talk 19:03, 9 February 2022 (UTC)

• So for #1 or #2 above, @PPelberg (WMF), Whatamidoing (WMF), and ESanders (WMF): is staff going to push for #2? — xaosflux ^Talk 16:56, 9 February 2022 (UTC)

  @Xaosflux, the mw:Editing Team supports moving forward with the "Gamma Test period" you described here and @Enterprisey and @Nick Moyes both expressed support for.^{[1] [2]} Also, planning the deployment for Monday, 7 March 2022, is fine with us.

  I've updated the deployment ticket (T296645) with this new deployment date.

  If/when you notice people reporting a significant issue with the Reply Tool, please ping me and I can add the issue as a sub-task of T296645. You're also welcome to boldly add any issues you believe would warrant the deployment being blocked. Although, I think it's important that the Editing Team review any issues of this kind.

  Does the above leave any part of the question you posed above unanswered?

  And before I sign off for the night, I wanted to express gratitude to:

  • @Gråbergs Gråa Sång, @Pelagic, and @Qwerfjkl for posting announcements throughout the wiki and updating relevant documentation
  • @Nick Moyes for seeing the value in, and taking the initiative to create a list of where the deployment has been announced
  • @Xaosflux for guiding this discussion toward clarity

  PPelberg (WMF) (talk) 03:29, 10 February 2022 (UTC)

• Thanks for starting this. I'm for #2; as I said, I can't really imagine what could be controversial about this (that's jinxing it, heh) besides the possibility of interference elsewhere on the page, but since we have hard numbers for that I'm sure it'll be fine. Enterprisey (talk!) 22:20, 9 February 2022 (UTC)
• (edit conflict) I'm for #2 as well. I think it's all about not surprising too many people, rather than seeking their permission for a rollout of an effective new tool. Either way, I'm still unclear if a Centralised Notice or Watchlist Notice is a) in the pipeline b) impossible to do c) deemed inappropriate/unnecessary. Personally, I'd prefer to read a banner that affects me, rather than all that fund-raising stuff. Even a non-editing IP visitor seeing such a banner notice would come away with a positive impression that they could participate in discussions should they ever wish to. What's not to like?
  ...and a final thought, how about preparing a Reply Tool Rollout Information page? Aim it directly at en-wiki editors, and summarise all information together in one place. Here's a mock-up of its bare bones if folk think it's worth running with the idea. Nick Moyes (talk) 23:50, 9 February 2022 (UTC)

  @Nick Moyes: we have Wikipedia:Talk_pages_project#Reply_tool, which can be expanded on for sure (and what we were planning on linking people to) - not sure we need a standalone page. — xaosflux ^Talk 00:02, 10 February 2022 (UTC)

  xaosflux I wasn't sure either. I only thought that if people were concerned about minimising community concerns or kickback, then it could be a sensible 'political' move to directly cater for them with a dedicated page or sub-page just for the rollout issue. I'm not trying to make work; it all depends on what level of concern you and others think there could be. Nick Moyes (talk) 00:17, 10 February 2022 (UTC)

  Such a big/important change really does deserve a dedicated page. I think it would make sense to start by simply splitting the Reply tool section out of the Talk pages project page and then possibly extend it to cover any further issues related to the deployment. That would also help to segregate any future talk page feedback from the talk page feedback for the other parts of the overall project — GhostInTheMachine ^{talk to me} 12:19, 10 February 2022 (UTC)

  Based on the experience of other wikis, I'm not sure this will feel like a big change, especially after the first two weeks.

  That said, if you want to create Help: content, then mw:Help:DiscussionTools has some screenshots and basic text. You can extract the plain wikitext from the translation system at this convoluted link. Whatamidoing (WMF) (talk) 21:00, 10 February 2022 (UTC)

  I think it's an important change, for those who want to use it, but I think it's also a minor change for those uninterested in it, as it can easily be ignored. I think from a help documentation perspective, having the two ways of replying consolidated under Help:Talk pages § Replying to an existing thread is reasonable. isaacl (talk) 22:52, 10 February 2022 (UTC)

  Enough community support here should be fine to plow forward with #2 as well. Maybe we pick a date, like March 7th and go with it. @Enterprisey: seems like phab:T296645 is the main ticket, so any possibly discovered bugs can reference it and block it. I'm going to block it with a community-consensus requirement right now, but that doesn't mean we need a "support RFC" - just that this section needs to get a direction. — xaosflux ^Talk 23:38, 9 February 2022 (UTC)

  Basically, option 2 is a final Gamma Test period - with the pass criteria being "no unresolved blocking bugs" (so the assumption is that this is ready to go and is bug free - for example if no one actually tests or reports new issues). — xaosflux ^Talk 23:43, 9 February 2022 (UTC)

• Number 2 seems like the best option out of the two. This change, although not minor, can be opted out of. Plus I see this change as only benefiting those who want to use the tool. I've been using this tool for a while, and it has saved me a fair amount of time. Dreamy Jazz ^{talk to me | my contributions} 20:53, 10 February 2022 (UTC)
• Go for #2. Mz7 (talk) 20:52, 12 February 2022 (UTC)
• I'm for #2. KevinL (aka L235 · t · c) 01:17, 17 February 2022 (UTC)

  Hey PPelberg (WMF), hope all is well. Looks like we have at least a local consensus in favor of #2. Is there anything further you need from us? Does the Gamma Test option work for your team? Let us know if there's anything we can do to help you with the rollout or logistics. Best, KevinL (aka L235 · t · c) 18:00, 20 February 2022 (UTC)

  hi @L235! Thank you for thing ping...

  Looks like we have at least a local consensus in favor of #2... Does the Gamma Test option work for your team?

  Wonderful. And yes, the "Gamma Test" option works well for the Editing Team. We are planning for the desktop Reply Tool opt-out deployment to happen on 7 March 2022, provided no issues we collectively see as "blocking" remain unresolved at that point in time. See phab:T296645#7699690.

  Is there anything further you need from us?

  The work y'all are doing to file tasks for issues people are raising (e.g. T302257, T268558, T302296)^[i] and post announcements to ensure people are aware of and expecting this change (e.g. Watchlist message) is a big help and we are grateful for y'all leading this. I think continuing to do those two things will go long a way.

  On our end, the Editing Team will be gathering later this week to review the issues volunteers at en.wiki have filed about the Reply Tool. We will use this meeting to identify which, if any, issues we see as needing to be addressed before the planned 7 March deployment. I will post the outcomes of this meeting before this week is over so that y'all can review it and if necessary, we can talk about it.

  Please let me know if anything above prompts new thoughts/question.

  ---

  i. Special shoutout to @Xaosflux) for taking the initiative to file these tasks...this is a big help. PPelberg (WMF) (talk) 22:23, 22 February 2022 (UTC)

  @PPelberg (WMF) I have not seen any show-stopper bugs get raised, please be sure to also check Wikipedia_talk:Talk_pages_project — xaosflux ^Talk 22:45, 22 February 2022 (UTC)

  I have not seen any show-stopper bugs get raised...

  Noted. If/when you encounter a bug that rises to this level, please do not hesitate to ping me or @Whatamidoing (WMF).

  please be sure to also check Wikipedia_talk:Talk_pages_project

  On it! PPelberg (WMF) (talk) 22:48, 22 February 2022 (UTC)

  hi y'all. Yesterday, the Editing Team reviewed (what we understand to be) the main issues volunteers at en.wiki have experienced with the Reply Tool.

  Of the issues we reviewed, we did *not* identify any issues thus far that we thought ought to block the mw:Reply Tool deployment scheduled for 7 March 2022.

  We would value any and all people here reading over the review we conducted and commenting here if you:

  1. Think there are issues we did not consider and/or
  2. Think there are issues that ought to be considered blockers that we determined not to be

  You can read over the results the review we conducted in Phabricator here: Determine what – if any – issues ought to block the deployment of the Reply Tool as opt-out at en.wiki. PPelberg (WMF) (talk) 01:11, 26 February 2022 (UTC)

  I didn't see phab:T301845 on the list, which was mentioned at Wikipedia talk:Talk pages project § Discussion tools hiding error messages?. Is it on track to complete QA testing prior to March 7? isaacl (talk) 04:07, 26 February 2022 (UTC)

  @Isaacl I wouldn't call that blocking - since it is a garbage in garbage out problem, correct? High level summary: If someone creates a malformed page with unmatched tags, some of the page will not display right in this situation? — xaosflux ^Talk 12:16, 26 February 2022 (UTC)

  As per request, I raised an issue that I think should have been considered and didn't appear on the list. I'm not convinced it should be a blocker, and perhaps its resolution timeframe makes it moot, which is why I asked about it. But it does introduce a change to existing behaviour, and hides the cause of an error which can make (to the outside viewer, a seemingly random amount of) text on the page disappear. I think it should be discussed. isaacl (talk) 16:36, 26 February 2022 (UTC)

  @isaacl The fix for T301845 is actually already deployed to Wikipedia, since last Thursday! (For future reference, you can deduce this by looking for the orange tags with the version number like "1.38.0-wmf.23" on Phabricator, and comparing that to the version shown on Special:Version.) Matma Rex talk 23:03, 26 February 2022 (UTC)

  Thanks for the update! isaacl (talk) 23:14, 26 February 2022 (UTC)

  A non-blocking issue I reported elsewhere, but never got a response to is the annoyance of the Preview shortcut (Alt-Shift-P) being used out of habit (as one does all the time in Source Editor.) I don’t need it to actually work, but I am constantly frustrated by it taking me out of the reply window and opening the print window at the top of the page. So, finding one’s way back down on a long talk page to some point in the middle where the reply window is located is a frequent annoyance for me. Just deactivating this key combination would be welcome. Nick Moyes (talk) 10:03, 26 February 2022 (UTC)

  This is phab:T302742. It's possible that something useful could be done with it (scroll down a little, so the preview can be seen more easily?). Whatamidoing (WMF) (talk) 20:05, 28 February 2022 (UTC)

• Down for whatever gets this deployed to everyone the fastest. WMF has done excellent work on this tool, and I'm excited to see how it improves talk page dynamics. ProcrastinatingReader (talk) 17:00, 27 February 2022 (UTC)

Bugs

It is already implemented on the Dutch wiki for a while: nl:Overleg:Bijlmerramp (without asking me and without having it enabled in the preferences).
One bug I found in the editor was:
If I edit something and after that I copy something by a middle mouse click (on linux), it is pasted top left at the start of the edit. It does not happen with CTR-V. A more disturbing bug is that when I reply to an earlier post in a thread, the reply is inserted after the last edit in the thread. --Wickey (talk) 11:54, 11 February 2022 (UTC)

• @Wickey: regarding the later, that sounds serious, but I haven't been able to replicate it yet. Could you set up a simple sandbox page (e.g. at User:Wickey/replytool) and document that steps that you are doing, what results you got, and what results you expected? — xaosflux ^Talk 20:56, 12 February 2022 (UTC)

Don't know how to do this and if there is a difference between en- en nl-wiki, but I replied to a comment early in a series of comments here and here. My reply appeared as a reply to the last one (or at least one lower in the thread) instead where I replied. I may be mistaken, may be it happens in the preview, but it happened already before. --Wickey (talk) 10:57, 13 February 2022 (UTC)

Reply tool editor

Is there a page somewhere that talks about the editor used within the reply tool and the plans to update it? I did start looking via mw:Editor but got lost in a maze of twisty little articles — GhostInTheMachine ^{talk to me} 13:28, 11 February 2022 (UTC)

Given that mw:Extension:DiscussionTools requires mw:Extension:VisualEditor, I'd assume it's based on Visual Editor and its 2017 wikitext editor. --Ahecht (TALK
PAGE) 14:27, 11 February 2022 (UTC)

In terms of engineering, the "backend" is mw:Extension:VisualEditor. This means that nearly all of Wikipedia:VisualEditor/Keyboard shortcuts will work, even in the wikitext source mode (if you have the toolbar enabled; it can be toggled off in prefs). The toolbar is custom. If you have suggestions for what ought to be in the toolbar, then you might want to skim through phab:T282153. Whatamidoing (WMF) (talk) 20:19, 11 February 2022 (UTC)

7 March Deployment

Hi y'all - the Editing Team will be making the Reply Tool available as an opt-out feature at en.wiki (T296645) this upcoming Monday, 7 March 2022.

If there is information that you think could impact Monday's planned deployment, *please comment here ASAP*.

In the meantime, here is a summary of what has happened in the seven days since we published a summary of the outstanding Reply Tool issues:

• @Isaacl, @Nick Moyes, @ProcrastinatingReader, @Gerald Waldo Luis, and @ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ raised the following issues: T301845, T291073, T269310, T230683, and T249293
• @Xaosflux helpfully reviewed and troubleshot many of these issues
• The Editing Team also reviewed the issues mentioned above and did not come to understand any of them "blocking"
• In light of not learning of any blocking issues, the Editing Team is taking this to mean we ought to move forward with deploying the Reply Tool as an opt-out feature this upcoming Monday, 7 March.

PPelberg (WMF) (talk) 00:40, 5 March 2022 (UTC)

I will add that the two tasks labeled as "Not blocking, but ideal" (

the usual schedule. Matma Rex talk

15:57, 5 March 2022 (UTC)

The reply tool is now enabled for everyone, with an option to disable it in preferences. Matma Rex talk 14:28, 7 March 2022 (UTC)

Is there a way for me to shut the new tool off? GoodDay (talk) 20:50, 7 March 2022 (UTC)

There is, according to the note at the top of my watchlist, a way to turn it off in our preferences tool. Not at all helpful help. Where in preferences is a better way to help? Anybody? My preferences are cobwebby obfuscatory dungeons designed to confuse a pensioner, and the "TURNITOFF" tool is hidden. Thanks. -Roxy the grumpy dog. wooF 20:55, 7 March 2022 (UTC)

I suggested an improvement to the watchlist notice: MediaWiki talk:Watchlist-messages#Improve link to reply tool preferences. Matma Rex talk 21:06, 7 March 2022 (UTC)

Now done. :-) --MZMcBride (talk) 21:19, 7 March 2022 (UTC)

@GoodDay Hi, I explained it in the comment just above yours; click the link to the "option to disable it in preferences" I provided. Matma Rex talk 20:58, 7 March 2022 (UTC)

I did & it worked. I'm guessing, a lot of editors will be disabling it. GoodDay (talk) 21:00, 7 March 2022 (UTC)

I clicked the supplied link, and it took me to my preferences, but didn't help. I need to know where "disable reply link" is????? -Roxy the grumpy dog. wooF 21:06, 7 March 2022 (UTC)

@GoodDay and Roxy the dog: Preferences -> Editing -> Discussion pages -> uncheck the box that says "Enable quick replying". ― Blaze Wolf^Talk_{Blaze Wolf#6545} 21:09, 7 March 2022 (UTC)

For anyone for whom the link doesn't work ( @Roxy the dog @GoodDay), it's at the bottom of the Editing section. ― Qwerfjkltalk 21:10, 7 March 2022 (UTC)

Is traffic that heavy on this page? I've tried 12 times, to correct my previous comment to say that I did it & it worked. Wowsers, 12 Edit conflicts in a row. GoodDay (talk) 21:13, 7 March 2022 (UTC)

@GoodDay: Ah alright. Glad it worked for you. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 21:18, 7 March 2022 (UTC)

GoodDay: I'm told there's a new reply tool that minimizes the likelihood of edit conflicts. Maybe you should try it out. ;-) --MZMcBride (talk) 21:21, 7 March 2022 (UTC)

Now, that would be something I could use. GoodDay (talk) 21:24, 7 March 2022 (UTC)

@GoodDay: Actually, you'd probably need CD to edit your comment... ― Qwerfjkltalk 21:28, 7 March 2022 (UTC)

That's correct: The Reply tool automagically and silently resolves nearly all edit conflicts, but it doesn't currently allow you to edit existing comments. (That idea is in phab:T245225, and I don't know whether it will get implemented any time soon.) If you want to edit your existing comments, then the similar volunteer-created user script Convenient Discussions has that ability. Whatamidoing (WMF) (talk) 21:57, 7 March 2022 (UTC)

The announcement at the top of the watchlist says the reply tool is now deployed for those editors who have not opted out. But I don't see any difference when I reply. How can I tell if the reply tool is in effect for me? Jc3s5h (talk) 22:13, 7 March 2022 (UTC)

I see that the reply button is at the end of the post that one could reply to. Jc3s5h (talk) 23:16, 7 March 2022 (UTC)

You know an old Jewish joke: "If you feel uneasy at your home, just buy a goat, and then get rid of it". It surely applies to me, with my Opera Presto 12.18 (that I cannot update because of the hardware). I feel happy because I am at last allowed to get to the Preferences and change them! For a year or more, I haven't been able to do even this. So thank you, thank you, thank you that I can get rid of yet another useless deploy, instead of slowly crawling to a cemetery. (Slowly, because nobody wants my panic). — Mike Novikoff 00:05, 9 March 2022 (UTC)

Currently date format for single digit dates is 5 March 2022 in the revision history. This format means it doesnt align well with previous or the next revisions in above and below lines, like with 22 March or 28th February. More alignment mismatch happens in case of months change too, like between February to March, and this date adds up. Visually the revision history doesn't look friendly.

I propose to change it to two digits date, as in 05 March 2022. This will fix alignments to some extent, not to full extent as the month name length are different. And user name lengths dont match, so it cant be aligned anyway. This new date format will improve alignment, and makes the revision history page more pleasing visually. This would look good in user contribution pages too. Crashed greek (talk) 04:42, 5 March 2022 (UTC)

@Crashed greek, User:Enterprisey/2-digit-day-of-month.js. Enterprisey (talk!) 05:30, 5 March 2022 (UTC)

But proposal is to change it for all. Crashed greek (talk) 08:26, 6 March 2022 (UTC)

Go to your preferences and pick the appearance tab. There are five options at date format:

• No preference
• 05:23, March 5, 2022
• 05:23, 5 March 2022
• 05:23, 2022 March 5
• 2022-03-05T05:23:03

Pick the last one and Bob's your uncle. It all lines up and you don't have to bother about May or September. CambridgeBayWeather, Uqaqtuq (talk), Huliva 05:27, 5 March 2022 (UTC)

But the proposal is to change it for all. Crashed greek (talk) 08:26, 6 March 2022 (UTC)

You already said that. But forcing something on everyone that only one person wants isn't the best of proposals. Personally, I like March 6, 2022 or 3/6/2022. Amaury • 11:29, 6 March 2022 (UTC)

Don't see the benefit, and we shouldn't be forcing the least friendly date time format on everyone. Joseph2302 (talk) 11:36, 6 March 2022 (UTC)

Date format is very much a personal preference, imposing one format on everyone is definitely not going to happen. Thryduulf (talk) 13:27, 6 March 2022 (UTC)

We are already imposing a date format on everyone, except some 1% people who create account and change preferences. Better alignment will help esp non logged in users. So the question is which is the best default settings for the imposed format. I am suggesting a very minor change to the existing imposition. Changing the order of month and date would be a much bigger change, also changing month text to number would be a much bigger change on top of that leading to confusion depending on location of the user. My proposal is a very minor change, that affects dates from 1 to 9 out of 30 days a month. Crashed greek (talk) 06:26, 7 March 2022 (UTC)

I don't think many of us want this change as the default. Perhaps you could ask for another option to be added to the preference screen. Alternatively, it should be easy to achieve in JavaScript. Certes (talk) 13:07, 7 March 2022 (UTC)

That is understandable, but I wanted to make clear that my proposal is not to change the default date format in a big way like other users suggested. Crashed greek (talk) 06:11, 9 March 2022 (UTC)

Now that we have a reverted tag, would it be desirable and feasible to discount reverted edits when granting autoconfirmed status? A new editor has been making unhelpful subtle changes, such as removing random letters, and replied to a warning with I just wanted to get to ten edits really fast. Others may be less candid. Edits can be reverted wrongly, but if a new editor is consistently reverted then we may not want them creating pages yet. Certes (talk) 12:53, 12 March 2022 (UTC)

The following scenario would be an issue:

1. A user does 10 edits and has 4 days since account creation.
2. The user does an action restricted to autoconfirmed users
3. Some of the edits mentioned in #1 get reverted.

93.172.238.76 (talk) 18:00, 12 March 2022 (UTC)

The editor would remain autoconfirmed in that case: withdrawing the privilege retrospectively would overcomplicate things. It won't cover all cases, but would catch anyone who makes ten bad edits soon enough to be reverted within four days of registering. Certes (talk) 19:01, 12 March 2022 (UTC)

I'm fairly sure that autoconfirmed isn't a "group" that's stored in the database like other user groups. Each time you click "edit" on a semi-protected page, the software checks your total edit count and tenure, and if it's enough, you're allowed to edit. (Note that extendedconfirmed and confirmed work differently.) So in the 93.172.238.76's scenario, the user would lose the ability to edit semi-protected pages, unless they've made a total of 10 non-reverted edits. But a here's a more concerning scenario:

1. Alice makes 9 edits
2. Bob reverts all 9 edits for the lulz
3. Carol quickly notices, and reverts all of Bob's edits.

Now those "reverted" tags are sticking around on Alice's edits. So does she have to make 10 more edits? Suffusion of Yellow (talk) 19:19, 12 March 2022 (UTC)

@Certes from a technical perspective, this isn't feasible. "Autoconfirmed" is primarily supposed to be a check against vandalism bots, forcing editors without it to have to answer CAPTCHA's when adding links and preventing less accountable editing of minorly protected pages. We can't really change "what" is counted, however we can adjust the number of edits and/or days required. — xaosflux ^Talk 19:27, 12 March 2022 (UTC)

Thanks. I realise that this would require a software change, but perhaps doing an actual filtered count rather than just checking a running total is a step too far. We've debated the numbers of edits and days here before, and I agree with the consensus that 10/4 is reasonable. Certes (talk) 19:30, 12 March 2022 (UTC)

I think the edit count of 10 to become autoconfirmed is (rightly) so low as to be worth ignoring. The people we should be more concerned with are those serious POV pushers who game the system to become extended confirmed.

Phil Bridger (talk

) 19:49, 12 March 2022 (UTC)