Yes, mentors have to ping newcomers. A newcomer returning back to their mentor's talk page is unlikely to happen, and, on a crowded page, their chances to find back the message they left is really rare. Pinging is a best practice we documented as a more successful way to have a real discussion between mentors and mentees.
I thought so, then it should be explicitly indicated somewhere to the mentors (because I repeat this every week for someone), and this message should be rewritten. Since if the mentor did not ping newcomer, then it does not correspond to reality. I think we can also give a link to d:Q12377052.
Yes, I insist on this when communicating with other mentors, but sometimes it is not only mentors who answer newcomers. And some mentors may simply forget about pinging a user. Tired after work, for example.
Not only beginners want to see the process of their work. I think it will be useful for mentors as well. I propose for mentors to replace the "ask the mentor" module, the "mentor monitor" module, where they will be able to see the following:
Number and list of newcomers under mentor's supervision
Number of questions asked to the mentor
Number of newcomers continuing to work after their question has been answered
1. A form for answering questions posted on mentor discussion pages - as a mirror mechanism to the "ask a question" form available to the newcomer.
+ A recommender system that would offer 2 to 3 choices of blanks to answer. Which would be based on keyword searches in the question . Using a common table "key" (or RegExp) - "answer blanks" would be convenient, especially with access to updates and additions by mentors and other experienced participants.
+ Perhaps in the light of this hide (!) these questions from the mentor discussion page, because (A) there have already been complaints about cluttering the page (B) this will now be possible by using mirror question-answer forms.
It is a parent task for several sub-tasks, these sub-tasks describe the different possible modules that would be activated on the mentor's homepage.
Can you detail the reason why all the (nice) ideas you have would address mentors' needs or issues? Some context would help to define better tools. As a comparison, if you ask for a dog, I could give you a dog. But if your need is to plant flowers seeds, maybe you don't really need a dog but a shovel.:)
> Can you detail the reason why all the (nice) ideas you have would address mentors' needs or issues? Some context would help to define better tools. As a comparison, if you ask for a dog, I could give you a dog. But if your need is to plant flowers seeds, maybe you don't really need a dog but a shovel.:)
1. Number and list of newcomers under mentor's supervision
I'm not sure to understand what "forced mentoring mechanic" means there. Can you clarify please?
I understand the motivation need, but there is a drawback. Imagine two mentors, whose names are equally distributed to mentees. Mentees may not have the same motivation, and you can ha a mentor that will interact with 10% "their" mentees, while the other one will interact with 40% of them. Contacting the mentor is up to mentees, and getting no questions from mentees is discouraging mentors (I had this from a mentors from uk.wp). Don't you think such a feature would discourage some mentors, since they can't improve this figure?
Also, our plans so far are the following: when a user ad their name to become a mentor, the system automatically adds modules or replaces modules on the existing homepage. In your opinion, should we enhance the existing homepage with tools for mentors, or create a separate one, dedicated to mentoring?
> I'm not sure to understand what "forced mentoring mechanic" means there. Can you clarify please?
There are some very unconstructive, inexperienced users who make a positive contribution to Wikipedia, but do not know how to communicate well. They are assigned "forced mentoring" by our administrators. That is, all their edits are strictly moderated by mentors, or in general, are published only by mentors
> Don't you think such a feature would discourage some mentors, since they can't improve this figure?
Yes, that's a very good point. But I can't think of any other number that could be motivating. Anyway, not about motivation, we need some kind of open statistics, like Special:Stats.
> Also, our plans so far are the following: when a user ad their name to become a mentor, the system automatically adds modules or replaces modules on the existing homepage. In your opinion, should we enhance the existing homepage with tools for mentors, or create a separate one, dedicated to mentoring?
A very good question, I generally thought to propose an idea, to make a "Homepage" not only for beginners, but for all participants. For example, remove a block with a mentor from users who have more than 1000 edits. Or make it possible to programmatically switch from the beginner's home page to the experienced editor's home page.
As for mentors, it depends on the number of new functions, if there are a lot of them and they overlap the main editorial blocks, then yes, we need to create a new special page.
There are some very unconstructive, inexperienced users who make a positive contribution to Wikipedia, but do not know how to communicate well. They are assigned "forced mentoring" by our administrators. That is, all their edits are strictly moderated by mentors, or in general, are published only by mentors
Thank you for explaining it. Definitely, our tools might help. If you deploy the homepage for everyone, anyone can claim a user and then monitor the edits they made. But it is also a way to harass people, by actively stalking their contributions.:( We need to find the right balance. I keep the process you use in mind for the time we will think about this feature.
About motivation, a possibility would be to sum the number of thanks received by a mentor from their mentees. But again, this depends on the number of mentees that interact with you.
and thank you for your feedback about homepages options!:)
In Bengali, if number passes 100 000, instead of saying 100 thousand (or 100K) we say 1 lakh (it feels weird to say e.g. 300 thousand). The doc of this message says, to disable number formatting using suffixes for 100, 1,000,000, etc, disable this message (translate it to '-').
My question is what will happen if we disable it? Will "300K visits (past 60 days)" become "3 00 000 visits (past 60 days)"?
@MMiller (WMF)@Trizek (WMF) Hi, there's something wrong with the navbar template: all the italian translations that contains it, got bugged. Can you fix it? Thanak you
I briefly had a look at the template, the translations and pages where this template is implemented. Apparently, not translating the last line's title breaks the template. Before - after. I let you review my "translations". :D
The last edits for this template have been made there by Shirayuki. @Shirayuki, can you have a look so that this bug would not happen anymore? Thanks.:)
The grammar for these sentences in a bit tricky. This is the kind of detail I usually spot, but I miss these.
'Continue to start with small suggested edits.' is to be understood as "if you want to continue the mission of sharing free knowledge, you can start with small suggested edits". Or " To continue [sharing free knowledge], start with small suggested edits.'
Same for the next one: 'Help add to the world's knowledge with some easy fixes on Wikipedia articles.' -> "Do some easy fixes on Wikipedia articles to help add [more information] to the world's knowledge."
Concerning the last one, can you provide me the ideal sentence you want to make, and why the variable $1 blocks you?
@Iniquity: Are other cases of the following message "Ваша учётная запись существует уже $1" correctly displayed? The examples would be - "Ваша учётная запись существует уже 3 неделИ" or "1 год" vs "3 года".
@Etonkovidova Yes, we need to put each part of the message in the accusative case:) https://prnt.sc/u96jt3. If this is impossible, then we will think about how to reformulate. But I would not like it.
There's a slightly similar problem with this message in Hebrew, too, and probably in other languages.
I took a quick look at the code. The time string is generated with the separate function getRelativeTime(), which in turn calls the core formatDuration() from the Language class, and inserts it into the message.
Using a standard core function is nice, but evidently it doesn't exactly provide the necessary functionality. Perhaps it could show a simpler time stamp, to just one precision: days or weeks or months or years, but not years and months?
@Iniquity, is there a Phab report about this particular "неделИ" issue?
Hi @Iniquity -- I'm sorry for the delay in responding. The links that go in that module are given to us by the wiki community. You indicate them in the Phabricator task you created under the "Help panel" header. The Phabricator template came with pre-filled options from Wikidata, which is what is in there now (shown in the screenshot). If those are the right pages on your wiki, then you can leave them alone. Or you could replace those QIDs with better QIDs or with links to pages on your wiki. The idea is to choose the best help pages on your wiki for the subjects listed. Does this make sense?
Wonderful to see mobile access as a priority and being tested. This is something that is currently lacking in many of English Wikipedias new editor landing pages. Has the project also been thinking about blind readers with screen readers. My disability prevents me from using a mouse effectively often...thus I use voice navigation software or if not able to use (as a result of complicated coding) the tab button is used. My only recommendation is information all on one page as clicking link after link is very difficult for many of our disabled readers.... who could easily become editors if over navigation obstacles are removed --Moxy (talk) 23:06, 7 April 2020 (UTC)
Great recommendation! Just to double-check, are you referring to having to expand each section one by one? If so, a couple things come to mind...
On wider screen (tablet) devices the mobile interface loads with all sections expanded. Separately, but related, when screen readers (or tab navigation) are used with the desktop interface, I see a "Jump to navigation" link appears, but seems hidden otherwise.
I was wondering if perhaps a similar (normally hidden yet focusable) "Expand all sections" link for the non-wide-screen mobile interface would be a useful approach?
i.e Help:Introduction VS Wikipedia:Contributing to Wikipedia. Accessibility for all should be an end goal for any page especially help pages. Module tutorials like Help:Introduction requires someone to click 60 times to find servicible info - let alone discouraging having to review so many pages. Also format should work with screen readers (need alt text) and work in mobile view and TV boxs. A table of contents is also very important to help with navigation when no mouse is used and is why collapsed items should be omitted.--Moxy (talk) 22:06, 14 April 2020 (UTC)
Hi @Moxy -- thank you for looking at the Growth team features and bringing up accessibility. In general, we try to make sure that our features are accessible by using visual components that are built for accessibility. That said, there are still some parts that we may have missed. After your comment, we ran some tests that brought up two issues that we want to work on: this one and this one. Beyond those, would you be interested and willing to help us test out the features for accessibility? We can set you up with the features in Test Wikipedia. Let me know!
@MMiller (WMF) We now have some horrible stats...as seen here the vast majority of potential editors dont go beyond the first page of the tutorial and that page has zero serviceable information. We need a page the is navigable with a TOC and works with screen readers.--Moxy (talk) 11:48, 12 June 2020 (UTC)
Thanks, @Moxy, for posting those stats about the Help:Introduction page. That's actually something built and maintained by volunteers, and I recently saw a conversation in which it would be given more prominence on English Wikipedia. @Sdkb -- these thoughts on the accessibility of the Help:Introduction page might be interesting to you, as you continue to talk about whether to send more newcomers toward it. If there are ways that WMF staff could help with the accessibility of the page, let's keep talking!
Thanks for the ping, @MMiller (WMF)! We introduced a single-page version of the Help:Introduction series a month ago; it is linked from the main menu page for anyone who prefers it for accessibility or other reasons. I also brought the series to WikiProject Accessibility a little while back to have the folks there vet it. With that said, if the WMF has folks who specialize in accessibility and want to take a look, I'd be very happy to hear any suggestions they have.
In order to help newcomers as best as possible, I suggest that the "ask for help" button should open a chat window and connect the newcomer to an experienced user who provides help in real time and on the spot. This is not meant as an introduction of chat for all users, but only as a tool for which experienced users who want to help could sign up for. I believe that is is often difficult for newbies to write down what their problem or question actually entails and even more difficult to understand the answers written down by wikipedians. Real-time chat would help to come to the point since both participants could ask further questions to identify the specific problem the newcomer is facing. Ideally, this would be combined with a kind of back-end view, showing the experienced user the page which the newcomer is looking at (similar to a remote support functionality, but read-only).--~~~~
This is the best statement of the problem that I have seen!
often difficult for newbies to write down what their problem or question actually entails and even more difficult to understand the answers written down by wikipedians
As someone who very occasionally visits en-wp Teahouse and Helpdesk, and was recently looking at VE-feedback, I’ll say it’s quite common to see a post that make me go “huh? what?”. Another big issue is not knowing whether the newbie has come back and read the responses, as they rarely post an acknowledgement. It can be discouraging writing answers that will just get archived after a few days. Perhaps live help could be (sometimes) rewarding for the helper as well as the helpee?
Hi @Pelagic -- thanks for checking out these materials. I agree that newcomers have trouble formulating strong questions. This is definitely something we've struggled with in the help panel project. We've tried a couple ways to frame the prompt to ask questions, but we continue to get plenty of newcomers whose question is simply something like, "Hello" (which, I suspect, is because they expect someone to chat them back a "hello" right away).
And it is definitely also a problem that newcomers frequently don't see the responses. Our data from the help panel makes us think it is less than half of users who return to view the responses they get to their questions. To address this, we've encouraged newcomers to add email addresses to their accounts (via the newcomer homepage) and told them to expect a notification on wiki (via the help panel). We haven't yet revisited whether we increased how many newcomers read responses.
I agree that live chat help could be rewarding for the helper, and this has been an ongoing topic of conversation on our team: how to make the helping of newcomers feel rewarding and productive. One idea we have is the mentor dashboard, which would allow mentors to monitor how their mentees are doing, and to track the kind of impact they may have had through helping those newcomers succeed. Please feel free to add any of your ideas to that talk page!
But overall, the team has not yet prioritized to digging in how we could make live chat work -- we have been prioritizing the "newcomer tasks" features that you commented on separately. I do hope we can return to this idea.
Hi @Poupou l'quourouce -- thanks for reading about our team's work and proposing this idea. The idea of "chat" has come up a lot in our team's work, especially around the help panel feature. Newcomers frequently expect the help panel to have live chat, and experienced community members have expressed interest in supporting it. And at Wikimedia Hackathon 2019, we actually built a small prototype. But there are a couple of really big challenges around it that have kept us from working on it too much, and I'm wondering whether you have ideas around these:
Resourcing: how could we make sure that enough experienced editors are available at all times to respond to chats?
Patrolling: live chat could potentially be a vector for abuse, and we would want to make sure that it is a safe place for all users.
Resources and potential abuse are indeed relevant issues. I do not think that there will be enough editors available at all times for live-support. But in that situation there could just be a note saying "sorry, no live chat available at the moment, please try again later or leave your questions at XYZ, where they will be answered within the next days".
For abuse reasons there should be an easy way for the newcomer to end the conversation any time. And, possibly more important, the tool should (from a back-edn perspective) not be available to anyone, but only to experiecned users that have been approved by others, for example users who have mentor status (in de Wikipedia they are elected similar to admins, I do not know about other versions). Those users who engange would need to have some sturdy attitude, so they do not bother too much, in case they receive abuse messages from fake newcomers. Regards,--~~~~
I stumbled onto a Growth newsletter at somebody’s talk page; it was great to browse some recent back issues and see how you are progressing!
I remember thinking “it would be nice to play with this, but Vietnamese, Korean, etc. are beyond me”. I only discovered by accident that I could enable the Homepage on testwiki.
Could you add something to this page in the timeline under Current status, please? It might also be nice to mention in future newsletters.
@Pelagic -- thanks for getting in touch and checking things out! Yes, it is possible to use the features on Test Wikipedia if you enable the preferences, but the experience has not been ideal because the suggested edit queue only has a few articles in it. @Trizek (WMF) is actually in the process of setting it up for wider consumption via this Phabricator task, in which we'll populate more articles in the suggested edit queue. We will let you both know when that's done. Good idea to publicize that fact in future newsletters and on the project pages. We'll do it. @Pelagic, please feel free to join the conversation about "structured tasks" if you get a chance!
