Talk:Growth/Focus on help desk/Flow export

Small alteration to name of feature

Although we originally started referring to the feature we are building in 2018 Q2 as the "help pane", we received some feedback that the name would be clearer if we called it "help panel". "Pane" sounds too much like "pain", and could be confusing. I updated the name on the project page and on the related Phabricator tasks. MMiller (WMF) (talk) 19:22, 29 November 2018 (UTC)

Rules, wording, and design of help panel

This is a topic for community discussion around the rules, wording, and design of the help panel. MMiller (WMF) (talk) 00:31, 6 December 2018 (UTC)

In User testing for help panel, the comment "Discoverability of the help panel call-to-action may be reduced in the case when the user is using the Visual Editor or wikitext2017 editor because those editors have a competing '?' icon", is certainly an issue. In VE [I'm less certain about the wikitext2017 editor], the dialog invoked by clicking on that "?" icon should be changed. It now begins "If you encounter any technical issues as you edit, please report them," which (a) is not likely to be why the user clicked on the icon, (b) is duplicated by "Leave feedback about this software", and (c) made sense back in the day when this was beta software, but it's not anymore.

As to what the VE dialog should look like, I suggest "Help:" as a heading, followed immediately by four items: "Open the help panel", "Read the user guide", "Keyboard shortcuts", and "Provide feedback on this software". That (obviously) gets the user to the help panel in just two clicks, while offering some other options.

Also, to quibble, a help icon is usually in the form of a question mark with a circle around it, not a naked question mark. And the icon for the user guide (and maybe the help panel), within the dialog, should be an "i" with a circle around it, for information. John Broughton (talk) 00:35, 11 December 2018 (UTC)

Thanks for thinking about this, @John Broughton. We also were thinking about the idea of letting the help panel be an option in the "?" menu. But what do you think about the help panel potentially just superseding the "?" entirely? And removing it from the toolbar? We are going to be able to keep an eye on this, because we recently started tracking how often users open the "?" menu. MMiller (WMF) (talk) 00:47, 14 December 2018 (UTC)

The only thing that I think is useful in the current ? dialog is the link to the user manual; I'd hate to lose that. Maybe split the difference - have a "circled i" (information) icon that links to the user manual, and a (circled) ? that offers help?

Alternatively, something that has been discussed at some length, but not implemented (for which I'm probably the most to blame, since WMF resources were offered to me a while back, to test the concept) would be to put links to various sections of the user manual in context-specific places (specifically, the various pull-down menus, and menu items of VE). That would obviate the need to put a main link somewhere. John Broughton (talk) 01:26, 14 December 2018 (UTC)

Yeah, I was thinking that we could put the link to the user manual in the help panel, so that we would consolidate all the helpful links in one place. How does that sound?

The idea you described about put links to various sections in context-specific places sounds like the "In-context lessons" idea that you helped us discuss a few months ago. I'm hoping that after we get some learning through the help panel, we might turn attention to that idea. MMiller (WMF) (talk) 01:46, 15 December 2018 (UTC)

Sure, a link in the help panel, to the user manual, is quite satisfactory. John Broughton (talk) 15:24, 15 December 2018 (UTC)

Also, I'm guessing (I don't see an explicit statement on this) that you're relying on a volunteer editor's response to a user's question to actually include the user name, which will then trigger an email to that user [I think]. However, while including the user name in a response is common, it doesn't seem universal - see, for example, https://en.wikipedia.org/wiki/Wikipedia:Help_desk#Fixing_Odd_Formatting_on_Article as well as the question and answer immediately below that section. And it's not mentioned in best practices at Growth/Communities/How to work with newcomers on help desks . Are you planning to automate/ensure that an email is in fact generated for the new user when the user's question is posted? John Broughton (talk) 00:50, 11 December 2018 (UTC)

Concerning the point about mentioning people, it is already in the best practices: "Make sure the newcomer is aware of the reply, by any method."

Thank you for pointing it out, though: I've clarified the sentence by having it as a separate point and added "For instance, on wikitext talk pages, mention the user when you reply." Trizek_(WMF) (talk) 10:38, 12 December 2018 (UTC)

@John Broughton -- an idea that @Martin Urbanec brought up is to use an abuse filter to remind responders to mention someone in their reply. Do you think that could be a helpful approach? MMiller (WMF) (talk) 00:51, 14 December 2018 (UTC)

While using the abuse filter has potential, I worry about the details. Specifically, not all edits require a user name - the first in a section, obviously, but possibly the second, because sometimes the user with the questions posts and then edits his/her post, or adds a second post immediately. Or the pattern might be (1) question, (2) response, and (3) elaboration on the response by another (helping) editor; if so, I suspect that the editor of the third post would not appreciate getting a warning, since the second post should already be notifying the user who had the questions. John Broughton (talk) 01:21, 14 December 2018 (UTC)

Regarding "Provide clearer times on both the review and confirmation screens for when a newcomer should expect a response from the help desk", that is obviously going to vary by community, and there isn't any way to pick a single number (or range) that is both accurate and helpful across all communities. (For example, "one day to two weeks" is probably accurate, but not helpful; "Within 24 hours" is helpful, and for the English Help desk is accurate, but may well not be for many other communities.

So, two options come to mind - either each community can specify that parameter (hidden comment on the Help desk page? central list that is updated by stewards upon request from an editor?), or an automated way of calculating the average time - say, a bot that checks once per day to compare the date/time stamps in each of the most recent ten sections that have both an initial posting and a posting that is [presumably] in response [different user name]. John Broughton (talk) 00:57, 11 December 2018 (UTC)

@John Broughton -- that's a good idea about letting each wiki specify their usual response time! We're going to hang on to that idea. For now, we know that Czech and Korean Wikipedias (the pilot wikis for this project) can commit to the "day or so" response time, and so we have it hard-coded that way. I hope that if this feature works, and if communities develop enthusiasm around it, they might be able to commit to shorter and more specific response times. MMiller (WMF) (talk) 00:54, 14 December 2018 (UTC)

That response time may change over the year, since some people may be away, or some events may slow down he activity on wikis. Trizek_(WMF) (talk) 19:02, 14 December 2018 (UTC)

One way to deal with a response time promise that hasn't been kept is to provide a link/option for the new user to report that "I have not had a reply within the promised time". That report might go to OTRS, for example, or to someone specifically charged with maintaining the response table. John Broughton (talk) 22:08, 14 December 2018 (UTC)

Interesting idea. It sounds like something we could include when we think about a way for users to give feedback on their experience with the help panel. We were thinking about that here on Phabricator, and I've added a note. MMiller (WMF) (talk) 01:34, 15 December 2018 (UTC)

Some ideas are described here: https://www.mediawiki.org/w/index.php?title=Talk%3AGrowth/Focus%20on%20help%20desk/Flow%20export#h-Improve_workflow_and_allow_storing_common_questions_/_answers_in_knowledge-base-2018-12-11T08%3A15%3A00.000Z.

I'd say the greatest failing of the current design is the fact that it includes an ability to immediately ask a question before even searching, and it makes it optional to add a page title. Neither should be visible in the first page, and it should not be possible to choose to include the page title as context, as that should always be included in the feedback.

In the short term it might be reasonable to include an extra item in the drop down for visualeditor, as suggested above. Long term, they should be combined into a button that routes the feedback to the appropriate place, either phabricator (for technical matters), VisualEditor/Feedback (for general feedback), a help desk (for general support), or a talk page (for page specific issues) depending on the nature of the problem or feedback.

Also, eventually there should probably be a non-javascript fallback, maybe Special:Help for when either editing without javascript or for users with temporary network glitches. 197.218.81.145 (talk) 08:25, 11 December 2018 (UTC)

I think a non-JS fallback is essential; anyone editing on a low-bandwidth or expensive connection has a strong motivation to not use JS. Things that require JS, or lots of bandwidth, risk increasing systemic bias. HLHJ (talk) 00:41, 12 January 2019 (UTC)

Thanks, @HLHJ. That's an important point. Right now, for non-JS users, the help panel icon shows up just like for other users. When they click it, however, instead of the dynamic experience of interacting with the help panel from the editing context, it opens up the help desk itself in a new tab. At that point, the user would be able to follow the directions on that page to ask their question. Do you think that is a good fallback? Can you think of other ways to do it? MMiller (WMF) (talk) 00:54, 24 January 2019 (UTC)

Добрый день!

Хотелось внести правку в панель "Помощь по редактированию - Предложенные правки - Советы по быстрому старту".

В предложении "Корректура помогает статьям быть более качественными и надежной." заменить слово "надежной" на "надёжными".

Спасибо! Павел Витальевич Новиков (talk) 17:05, 8 June 2022 (UTC)

@Павел Витальевич Новиков, it has been fixed. The change will be visible soon! Trizek_(WMF) (talk) 18:43, 8 June 2022 (UTC)

Improve workflow and allow storing common questions / answers in knowledge-base

Design issue:

The design emphasizes asking questions rather than retrieving existing ones. It also doesn't seem to facilitate storage of common questions.

Background:

The greatest flaw of the wiki concept is inefficiency. Consider this, what is the question always asked by users? How many times has it been asked? How many person-hours and resources and money has been wasted answering the same question over and over again over the 15+ year wikimedia projects have existed? Finally, how many times has it been asked in other language projects? The answer to all those questions is that nobody knows. As it stands this system will make things worse by making it too simple to ask questions without verifying first.

Concrete issues:

• The design has a checkbox asking to include a title.
• There are three basic types of questions asked, each needs its own flow:
  • Technical questions - without platform details.
  • Trivia questions - "Why is there a naked picture???", "Is blue pokemon tougher than green?", "Why can't I add my blog?". A good number of these are worthless, the rest should probably be directed to the article talk page instead of a help desk.
  • Topic related questions - These questions may be useful and may help improve the page.
  • Spam question - someone just writing random stuff there

Possible Solutions

1. Never allow the user to ask a question until they search first.
2. Never allow a question without a topic.
3. Always include page title as always an important context, oldid revision is also important.
4. Most importantly, it would be preferable to have a way for end-users to promote certain questions to the help pane. Maybe each newbie reply would come with a link that enables users to save the question with a standard answer. This would increase the pool of questions / answers, and overall reduce the eventual work.

Improving questions

• Technical questions
  • These must always (not optionally) require platform details (OS, Browser, etc). It is a waste of time to ask users these questions as follow-up.
  • It should also never be simply unstructured because it will result in a lot of unactionable or invalid reports. See VisualEditor/Feedback for a lot of messy questions, see also T86956
  • End-users often break their own interfaces using badly designed gadgets/ userscripts and browser extensions. First advise them to try to access the page using safemode, for example, https://www.mediawiki.org/wiki/pagetitle?action=edit&safemode=1, and possibly temporarily disable the extensions.
• Trivia questions - should be discouraged, and the interface should attempt to strongly indicate these are not the point before the user posts a question.
• Topic related questions - may need to go to the talk page instead of a help desk
• Spam question - Add some basic anti-vandal measures, e.g. don't allow single repeated character, e.g. "AAAAAAAAAAAAAAAAAAAAAAAAAA", have a sensible input length limit, maybe add captcha when questions include a link. 197.218.81.145 (talk) 08:15, 11 December 2018 (UTC)

https://phabricator.wikimedia.org/T100011 197.218.81.145 (talk) 08:30, 11 December 2018 (UTC)

Thanks for thinking about this -- it sounds like you have a lot of experience with questions from newcomers. I think you're right that there are several things we could do to help structure and store questions, and therefore improve efficiency in the future. And in fact, most of our user testers said they would try to help themselves by looking at existing help pages before asking their own question.

There are a few things about our approach and our learnings that have made us

We plan to release the help panel in Czech and Korean Wikipedias in January, and we plan to iterate on it over the course of at least six months (potentially adding additional wikis along the way). We're going to keep close watch on what kinds of questions are asked and how productive the help panel seems, and we'll be able to make adjustments as we go along. If questions contain trivia, spam, or topic questions, we can change the workflow to encourage other types of questions. But we don't want to spend too much time engineering that system at the outset before collecting some questions to see how they turn out first.

Another thing we're thinking about is the secondary benefits of newcomers asking questions. The primary benefit may be that the newcomer gets their question answered and figures out how to proceed. But our research has also taught us that newcomers are more likely to stick around when they make positive contact with other editors, when they see that there is a vibrant community behind the project, and when they feel like they belong. Because of those things, we're not sure if we want to discourage asking questions in favor of reading answers to existing questions -- we're figuring out how to balance that. It might become a different story if wikis end up overwhelmed with too many questions. Does that make sense?

And with respect to including page title -- we wanted to try making this optional (but checked "on" by default) in case it turns out that there are users who don't want to disclose the article they're planning on editing. We anticipate that most people will leave it checked. If we find that almost no one unchecks the box, we may revisit whether it's important to have it. If we find that many people uncheck the box, we'll want to look into why. MMiller (WMF) (talk) 01:13, 14 December 2018 (UTC)

> I think you're right that there are several things we could do to help structure and store questions, and therefore improve efficiency in the future.

Seems to be something worth doing in advance, to save end-users and the developers a lot of unnecessary headache. Consider the difference between these two questions:

How do I get a reference to work?

vs

Question: How do I add a new citation / reference to a page?
Attempted steps: 
1. Open 2010 wikitext editor 
2. Clicked on the reference icon in the toolbar
2. The editing tool added <ref></ref>
3. Waited for a dialog
Expected
A dialog or anything to add a link or book or resource appeared
Actual:
No prompt to add anything, no help .

If "Question", "Attempted steps", "expected" and "actual" are different form fields, then question 2 is much useful than just a generic question 1.

> If questions contain trivia, spam, or topic questions, we can change the workflow to encourage other types of questions. But we don't want to spend too much time engineering that system at the outset before collecting some questions to see how they turn out first.

..

>Does that make sense?

This seems like a risky proposition. You may increase the burden on users, and then if the burden is too heavy you'll fix it? The fact of the matter is that the project deals with two variables it can't control, volunteers and development time. If they find it annoying they can simply ignore the questions, or answer badly and chase away newbies, or simply add automated tools to block such questions.

The project can be interrupted for any random reason, and it will leave users with a very limited basic tool. As an example, the tool being used here (Structured Discussions) was also an optimistic endeavor, yet it was mostly indefinitely halted in live sites, without even a simple ability to search existing threads, forcing users to have to rely on external search engines to find stuff here.

A similar endeavor exists in the English wikipedia's project teahouse with a question archive that allegedly doesn't even update anymore, and no sensible ability to search (https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Questions/Archive_Index). So there's a lot of history of limited tools being abandoned in place.

> in case it turns out that there are users who don't want to disclose the article they're planning on editing

That's a legitimate concern only if users haven't ever edited the page. If they have already edited it, then the fact that they've interacted with the page will be known anyway. Perhaps, a compromise would be to only show the checkbox if they've never edited the page in question. 197.218.84.60 (talk) 19:28, 14 December 2018 (UTC)

Thanks for pointing out some valuable things to keep in mind. I hadn't seen that Teahouse archive link. As we roll this out, we're going to keep close watch on how much of a burden we're putting on the experienced editors by counting how many questions are answered and how quickly. We're also in touch on a weekly basis with ambassadors in the Czech and Korean communities, @Martin Urbanec and @Revi (WMF), who are preparing their communities for these incoming questions, and who will be able to tell us whether things are getting too burdensome. MMiller (WMF) (talk) 02:01, 15 December 2018 (UTC)

Suggestion: Make it possible to search past questions

Issue:

From the mockups there doesn't seem to be any way to search a question archive.

Proposed solution

Build a way for users to search any "approved" question.

Note:

This may need to take into account the fact that people may put non-sensical gibberish into the search box. So it might be preferable to only add moderated questions in the search index. 197.218.84.60 (talk) 19:32, 14 December 2018 (UTC)

Thanks for recording this as a specific topic -- we actually have a Phabricator task for it! Here it is: https://phabricator.wikimedia.org/T209327. I made a note on the task that you brought this up. MMiller (WMF) (talk) 02:04, 15 December 2018 (UTC)

Suggestion: always include the Editing tool being used in every single feedback

Issue

Sometimes the problem lies with the tool, and the editor might not even know what they are using.

Proposed solution:

Always include the Editing tool being used in every single feedback post / thread. 197.218.84.60 (talk) 19:40, 14 December 2018 (UTC)

Thanks -- this sounds like a good idea that we'll keep in mind. MMiller (WMF) (talk) 02:06, 15 December 2018 (UTC)

Improve text for VE vs wikitext

The tips on how to post a good question currently says:

• If you know that information, mention whether you are editing with the visual editor (you directly edit and format the a article) or with wikitext code (you edit the code that builds the article).

That is poorly worded, confusing and arguably factually erroneous. I suggest one of these two versions:

• If you know, mention whether you are editing with the visual editor (graphical editing mode) or with wikitext (text editing mode).
• If you know, mention whether you are editing with the visual editor (graphical editing mode, links look like this) or with wikitext (text editing mode, links look like [[this]]). Alsee (talk) 21:17, 20 March 2019 (UTC)

Thanks for the suggestions, @Alsee. I'm tagging @Trizek (WMF), since he is managing that page. MMiller (WMF) (talk) 23:59, 21 March 2019 (UTC)

Thank you for the suggestion. I've used the first one and added some links. Trizek_(WMF) (talk) 14:03, 22 March 2019 (UTC)

Note that I changed "wikitext code" back to "wikitext". That phrasing is not normal usage outside of Foundation, and would be an inconsistent and poor choice for public consumption.

A search for wikitext on EnWiki gives 117,499 hits, while a search for "wikitext code" gives 329 hits (a ratio less than 0.003). Most of those 329 hits use the phrase to refer to a specific string of wikitext, many search hits were written by a staff member or were incidental in bulk copypaste of text written by a staff member, some are false-search-hits, some are in a technical context contrasting wikitext from lua or other programming language.

Referring to wikitext as wikitext code really is virtually non-existent English usage outside of the Foundation. Alsee (talk) 08:56, 25 March 2019 (UTC)

Numbers

"we also observe that large numbers of newcomers open the help panel (20%) and interact with it once open (50%)" -- how can the first percentage smaller than the second? Samat (talk) 09:46, 1 November 2019 (UTC)

@Samat -- thanks for reading closely. It's because the 50% is 50% of the 20%. In other words, of the people who open the help panel, half of them interact with it. To get the overall percentage, you multiply them together (i.e. 10% of people who see the help panel button interact with something in the panel). Does this make sense? MMiller (WMF) (talk) 17:32, 1 November 2019 (UTC)

Thank you, that's clear for me now. (And I made it clear in the translation as well.) Samat (talk) 17:41, 1 November 2019 (UTC)

Currently negative experiment results

It increases edits during a newcomer's first day, but decreases them over the following two weeks.

I support improvements, exploration and experimentation. A project may of course require a few revisions before reaching positive results.

If the team doesn't find a way to reverse the longer term negative impact, can someone confirm that there is an explicit plan for full rollback? This is a general concern to avoid accumulating complexity, cruft, and inconsistency across our wikis when some projects don't work out. Alsee (talk) 19:13, 18 November 2019 (UTC)

@Alsee -- thanks for following along and reading our notes closely. The help panel indeed has ambiguous results. On the one hand, we see anecdotal stories of users who ask questions, get answers, and then continue to edit. On the other hand, we don't see an impact on activation and retention, and we see this ambiguous impact on edit volume. So one thing that you're pointing out that we don't know is whether the help panel seems to increase or decrease edits over the entire first two weeks. I think that so far our analysis looks at Day 1, finds a positive impact, then looks at Days 2 - 14 and finds a negative impact. We can look into what the overall impact is.

But beyond that clarification, our current thinking is that the help panel may work better as part of a broader "integrated newcomer experience", along with the welcome survey, homepage, and newcomer tasks. In other words, it may not be a specific feature that makes the difference for newcomers, but a general overall upgrading of their experience via several connected features. In fact, for newcomer tasks, we plan (in the January/February range) to evolve the help panel to be the feature that guides newcomers as they complete tasks.

All this is to say that we want to keep the help panel around for now and integrate it with the newcomer tasks experience, and see how that affects its usage. If it is not proving useful in that context, then I think we'll need to revisit the questions you're bringing up -- because I agree that we should not leave up features that are not working.

How does this sound? MMiller (WMF) (talk) 22:44, 19 November 2019 (UTC)

Thanx. If you reach more positive results that's of course a good thing, and I apologize if it seemed I was jumping the gun about the initial results. I appreciate your confirmation that we should not leave up features if it turns out they're not working. To be honest, the topic caught my interest because there have been difficult times where teams have resisted their own data when it was unfavorable or counter-intuitive. It's easy for good intentions and big positive goals to feed into confirmation bias. The most crucial metric for any project is our inflow of new users as sustained-activity community members. Any negative data in that area should be taken very seriously. Alsee (talk) 07:28, 20 November 2019 (UTC)

Place of note about translations on this page

A note template with the text "The sections below may be changed significantly in the coming weeks, or they are too technical or less relevant for the understanding of the project. We have decided not to have them translated." is currently above the paragraphs that are marked for translation. May I ask that someone either moves it where it should be placed now or makes some other action, so that it was a bit clearer for translators? Thanks. Ата ^(talk) 15:19, 12 April 2020 (UTC)

This note is above the paragraphs that are not mandatory for translations. However, some users prefer to have the whole page being translated. We, as the Growth team, put a limit on what is really important to be translated, but it is up to anybody to translate whatever they like. Trizek_(WMF) (talk) 13:09, 14 April 2020 (UTC)

Oh I see. Previously it wasn't even marked for translation down of the note. I guess I misunderstood it. Ата ^(talk) 15:18, 14 April 2020 (UTC)

The first screenshot is out of date

I think you need to update, I just don’t know which part of form is important to you. Iniquity (talk) 16:21, 6 July 2020 (UTC)

You mean the prototype image in the infobox? Trizek_(WMF) (talk) 15:26, 7 July 2020 (UTC)

Yes, and the fact that no actual screenshot of the page looks a little strange. Iniquity (talk) 16:13, 7 July 2020 (UTC)

@Iniquity -- thank you for pointing this out. I added three up-to-date screenshots to the top of the page under the infobox. Does this seem better? MMiller (WMF) (talk) 03:20, 16 July 2020 (UTC)

@MMiller (WMF) Yes, much better, thanks :) Iniquity (talk) 08:46, 16 July 2020 (UTC)

Auto-sliding

The auto-sliding is annoying. I do not succed to read the entire slide. The auto-sliding could be replaced with a round and blue button that says "Next". --Paloi Sciurala (talk｜contribs) 17:08, 15 February 2021 (UTC)

Thank you for your feedback!

This is not something that showed up during our tests, since users were clicking back on the numbers to read the content of the tabs. However, I'm passing it to the development and design team. :)

May I ask where you checked on our tools? Trizek_(WMF) (talk) 17:47, 15 February 2021 (UTC)

I tested the help panel here, when editing pages. An alternative to button would be the adjustment of the speed for each slide. Also, each slide has more or less content to read, so (for example) for slide 1 you need 7 seconds to read it, for slide 2 you need 10 seconds to read it and for slide 5 you need 4 seconds to read it... (These numbers of seconds are randomly; only examples). --Paloi Sciurala (talk｜contribs) 17:54, 15 February 2021 (UTC)

The goal of this auto-sliding is to show that tips are available. Then people can click back to see them, which stops the timer. We are considering to have arrows instead of tabs, to make it clearer. What do you think? Trizek_(WMF) (talk) 09:11, 17 February 2021 (UTC)

Watchlist question

I'm testing the add-link beta feature and I realized that all the sites I've edited are on my watchlist. Is it possible to disable adding them there because it makes a mess and annoys me terribly. Zamkorus (talk) 17:05, 11 July 2021 (UTC)

Thank you for testing the tool, Krzysiek.

Have you selected "Add pages and files I edit to my watchlist" 'Dodawaj do obserwowanych strony i pliki, które edytuję) in your preferences?

What do you think of the quality of suggested liks? Trizek_(WMF) (talk) 12:35, 13 July 2021 (UTC)

No, I have this option unchecked. Only when I make edits with this beta they are being added to my watchlist. I think suggestions are very good. Polish is very difficult language, and AI doing great and hardly ever misunderstoods the meaning. Most links I refuse are things that everybody knows. Zamkorus (talk) 12:49, 13 July 2021 (UTC)

Thank you for your feedback.

I'll ask about the watchlist but I think it is done purposefully. This way, newcomers can check what happen to the article after they added some links. What newcomers do is different than what experienced users do.

Good to know that the AI works well for Polish! Trizek_(WMF) (talk) 12:56, 13 July 2021 (UTC)

Disabling panel

The panel says that it can be disabled but even when one unchecks the enable the help editor box and saves your preferences the panel still keeps showing up for me a day later. This is more annoying than the panel. Not sure if this is a bug or what but its very frustrating. 100.38.169.48 (talk) 02:45, 22 January 2022 (UTC)

Hi, could you say a bit more about where exactly (main namespace; talk namespace; editing/reading?) you see the help panel after unchecking the box? Thanks! KHarlan (WMF) (talk) 18:02, 24 January 2022 (UTC)

Thank you for reaching at us. on which wiki do you see it? Are you logged-in? Trizek_(WMF) (talk) 19:15, 24 January 2022 (UTC)

Черновик готов! Как его опубликовать в Википедии? Чтобы все его видели при поиске

Черновик готов! Как его опубликовать в Википедии? Чтобы все его видели при поиске например гугл? Моя статья не появляется?? 213.230.87.109 (talk) 17:27, 6 April 2022 (UTC)

Removing a blocked/locked mentee

So actually this has two purposes.

#How can I remove a blocked/locked mentee from my mentorship?

#On my dashboard, even though the mentee is blocked, it does not show it on my dashboard. It shows 0 under the blocks. Thanks and edit well!- PDL^{Talk to me!}_{Please don't eat da 🐑!} 00:00, 23 March 2024 (UTC)

Hello @PotsdamLamb, thanks for reporting this!

It looks like we have a Phab task for that first request: T351234, I have updated the task to show that this request is coming up again and to make it clear that this is a higher priority.

That second issue sounds like it might be a bug. @Etonkovidova (WMF) - could you test this and log a bug if needed? Thank you! KStoller-WMF (talk) 15:51, 25 March 2024 (UTC)

Regarding #On my dashboard, even though the mentee is blocked, it does not show it on my dashboard. It shows 0 under the blocks.

I checked the block counter behavior - it gets updated in about ~3 hours after the block was assigned to a user. I added comments to T351234. Etonkovidova (WMF) 15:59, 27 March 2024 (UTC)

@KStoller-WMF So the next day, the editor was no longer on my dashboard. I think it would be a better option if we could manually remove them, just like we could manually add them. Thanks and edit well!- PDL^{Talk to me!}_{Please don't eat da 🐑!} 12:50, 26 March 2024 (UTC)

The list of mentees is refreshed every 12 hours, but their number of edits are updated faster. Maybe this use was in your list as they created articles that got deleted. Trizek_(WMF) (talk) 18:25, 26 March 2024 (UTC)

The only pages they edited were requests for deletion and comments on other notice boards. But since they are not there any more, I am okay. It is great to know its's twice a day. So the only issue is that when they were blocked, it didn't show. Would that be part of the 12-hour refresh, by chance? Thanks and edit well!- PDL^{Talk to me!}_{Please don't eat da 🐑!} 11:58, 27 March 2024 (UTC)

Yes, logged actions are refreshed every 12 hours. Trizek_(WMF) (talk) 15:13, 27 March 2024 (UTC)

Ok thanks. I appreciate your assistance. Thanks and edit well!- PDL^{Talk to me!}_{Please don't eat da 🐑!} 03:26, 28 March 2024 (UTC)

You're welcomed! :)

And thank you for being a mentor.

By the way, you have listed mentors at your wiki, but not activated (yet ?) the mentoship feature for newcomers. You can do it at https://simple.wikipedia.org/wiki/Special:EditGrowthConfig (or I can do it on your behalf). This way, newcomers will be able to ask you questions, which is the very first goal of mentorship. Trizek_(WMF) (talk) 10:22, 28 March 2024 (UTC)

Let me talk to someone about it and have them answer. I cannot make that decision on my own. Thanks and edit well!- PDL^{Talk to me!}_{Please don't eat da 🐑!} 12:12, 28 March 2024 (UTC)