Hi Wikimedia Growth Team! Here are my initial thoughts/questions on the proposals:
Newcomer tasks
For a newcomer-friendly place to find tasks to work on, what we currently already have is the WP:Task Center, with some preferring Wikipedia:Community portal/Opentask. The tasks listed at the Task Center need a bunch of updating, but there are a few of us actively working on it. This feature, once fully developed, looks like it'll be a lot better than the current tools, but you might be able to take some inspiration from them.
I'm not too familiar with ORES models, but it'd be nice if editors, in addition with being presented with a bunch of interests, could also specify their own, so that those really passionate about e.g. railroads can get a feed of railroad articles.
For the tasks listed in the difficulty filter, one missing easy one is reverting suspected vandalism. You may want to coordinate with the Cluebot folks so that editors can be presented with suspected vandalism and help train Cluebot while reverting.
The 13% of editors who make more than 5 edits and 9% who come back after 3 days seems a little worryingly low.
Newcomer homepage
The start module looks good! Encouraging editors to go to the tutorial (probably the recently revamped Help:Introduction on en-WP) is much more important than getting them to create a user page.
Wow, you have a lot of notices haha!
How long are you planning for the homepage to be a thing for? Could it transition into something more like the dashboard or community portal as editors become more experienced?
I'm not sure there are enough active hosts for every new editor to automatically have a mentor. If mentorship ends up being an opt-in feature, what will the page look like for editors without one?
"view your mentor's other conversations", presumably going to their talk page, seems unnecessary.
I love the "your impact" module, and I think even experienced editors would love to have it. It reminds me a bit of Local Guides, Google's program for user contributions to Google Maps. That program does an excellent job of sharing statistics on e.g. how many views the photos you've uploaded have had, and it's a big motivator. That program also gamifies the experience, with badges that you can earn for e.g. making your 1000th edit, and I think a similar thing could be implemented here. The closest analogue we currently have is the Million Award, which is more for experienced contributors and not at all precise in terms of viewcounts. The xtools also have some neat data, such as authorship percentages, that could potentially be ported over to here. I.e. it'd be cool to see "hey, after your recent edits, you're the #3 top contributor to Foobar, and have authored 14.7% of the page!"
The above said, one issue with the impact module is that it doesn't take into account the type of edit. So if I put a ton of work into a more moderately trafficked article but then correct one comma at the COVID-19 article, it doesn't seem right that the module would essentially then be like "99% of your impact has been at COVID-19". I'm not sure how to address that issue, though.
Help panel
Experienced editors will absolutely not want this panel floating around their pageview, so it's essential that there be an option in preferences to disable it or it'll meet with a ton of community opposition.
The help pages listed should be customized based on the type of article being viewed, so for instance, there should be links to biography policies/help pages for biography articles.
Hi Sdkb -- thank you for taking a thorough look at the features and for these detailed thoughts! They are definitely helpful. I've lots of follow-up comments and questions, so I hope you have time to respond.
For a newcomer-friendly place to find tasks to work on, what we currently already have is the WP:Task Center, with some preferring Wikipedia:Community portal/Opentask. The tasks listed at the Task Center need a bunch of updating, but there are a few of us actively working on it. This feature, once fully developed, looks like it'll be a lot better than the current tools, but you might be able to take some inspiration from them.
Thanks for pointing out the Task Center -- I didn't know about that page. This shows several good examples of editing tasks that we hadn't previously considered (e.g. "Merging/Splitting" and "Image Maintenance"). I'll add those to our list to consider including in the suggested edits feed in the future. I have a few follow-up questions now that I'm looking at it:
If looks like the Task Center is geared toward newcomers -- how do newcomers discover the page?
Do you think the page is "working"? (maybe by helping newcomers make their first edits, or by encouraging them to return and continue editing?)
When newcomers do some of these tasks, like copyediting or expanding short articles, what is the workflow for removing the templates or categories that brought those articles to the page in the first place? This is a question that we haven't been able to figure out yet for our features -- we don't think that a newcomer with only one or two edits will understand how or whether to remove templates/categories.
In our experience, we think that some newcomers really like adding wikilinks to articles, because it is easy and fun. I noticed that that's not listed as a task in the Task Center. Is that because it is part of "Copy editing"? Or because it's not considered that valuable? MMiller (WMF) (talk) 17:44, 14 April 2020 (UTC)Signature refactored in by {{u|Sdkb}}talk to make it possible to reply to each section more directly; hope you don't mind.
Although the Task Center has existed for a while, up until recently, it's been quite hidden, and has not gotten many visitors. I recently spearheaded a redesign of the standard new user welcome template, which introduces it to that template for the first time (and does so quite prominently). It'll take some time to see how well it's working, and I'm not sure quite how we'll measure its efficacy even once it's more active. Similarly, more attention from experienced editors who notice it in the template should help refine the tasks listed there. Adding wikilinks is a great idea; we should add that. The only hesitation is that linking is one of those things that's harder to do well than you might assume. It's still an easy task compared to many, but if new editors assume they don't need to read the instructions, they might start introducing e.g. MOS:SEAOFBLUE or MOS:EGG issues. And there's no specific workflow currently for when to remove the template. Maybe add something like a small (not too prominent, and unchecked by default) checkbox at the bottom that says something like "the issue has been resolved (will remove the maintenance tag)". {{u|Sdkb}}talk19:11, 14 April 2020 (UTC)
I'm not too familiar with ORES models, but it'd be nice if editors, in addition with being presented with a bunch of interests, could also specify their own, so that those really passionate about e.g. railroads can get a feed of railroad articles.
I think this is a great idea that we've talked about on the team a couple times -- finding a way to let users type in their own specific topics! There are a couple ways we can think of doing this in the future. For instance, Citation Hunt searches all categories titles. We do want to get to this at some point -- especially because it looks so far that topics are appealing. About 75% of newcomers who have the option to choose topics end up choosing some. MMiller (WMF) (talk) 17:44, 14 April 2020 (UTC)Signature refactored in
For the tasks listed in the difficulty filter, one missing easy one is reverting suspected vandalism. You may want to coordinate with the Cluebot folks so that editors can be presented with suspected vandalism and help train Cluebot while reverting.
I'm somewhat surprised to hear this idea, because I would have thought that in order for users to patrol other edits, they need to have some experience editing themselves (and not be newcomers). What's your take? MMiller (WMF) (talk) 17:44, 14 April 2020 (UTC)Signature refactored in
Reverting vandalism is not really a difficult task — all it normally requires is clicking the undo button and then warning the offender on their talk page with an automated template (Twinkle has this functionality semi-automated already), and of course good faith (which editors using the tool are likely to have). For our purposes, there are three types of vandalism: (1) vandalism that easily trips Cluebot's filter and gets reverted automatically, (2) vandalism that Cluebot flags, but isn't confident enough to revert, and (3) vandalism subtle or unusual enough that it doesn't trip the filter. New editors seem very well-positioned to help out with the second category. Tools like WP:WikiLoop Battlefield are already functional, and that one has been written about in this article at Fast Company. The one thing I'd be a little concerned about is that editors might be exposed to offensive content, but I'd guess that most such content is in the first category. Vandalism isn't my area of expertise, but I'd certainly suggest talking to others more knowledgeable. {{u|Sdkb}}talk19:11, 14 April 2020 (UTC)
@MMiller (WMF):@Skdb: It's worth noting that, IIRC, most of our current anti-vandalism tools (Twinkle, Huggle, STiki; there are some newer ones I haven't looked into) require the user to be at least autoconfirmed (Twinkle) and often a rollbacker (most others). Presumably this is because the ability to rapidly revert edits would be dangerous in the hands of a bad-faith user.
That being said, it absolutely is possible for IPs and new users to revert vandalism - I often see them do so, presumably in pages they came across anyway - and we could always use more recent changes patrollers. We'd just want to make sure that, in making it easier for them to do so, we're not giving brand-new users tools we currently restrict to more experienced users for fear of abuse. Gaelan💬✏️03:23, 12 May 2021 (UTC)
Oops, here's a non-broken ping to Sdkb. Also, oops, I just realized the conversation I'm replying to is almost a year old. Hopefully my feedback was still helpful :) Gaelan💬✏️03:24, 12 May 2021 (UTC)
The 13% of editors who make more than 5 edits and 9% who come back after 3 days seems a little worryingly low.
We definitely want this to be higher, but it's actually high compared to what usual retention rates are like on the wikis. When we talk about "retention", we are talking about the percent of newcomers who make an edit and then return to edit again within some given time period. Looking at two-week retention, most wikis are around 4 or 5%, i.e. 4 or 5% of newcomers end up being retained over two weeks. So when we see that 9% make suggested edits on three separate days, we're encouraged that it seems to be improving on the baseline retention rate. Does that make sense? MMiller (WMF) (talk) 17:44, 14 April 2020 (UTC)Signature refactored in
That's good context! Wish we could get the rates much higher, but we'll definitely take an improvement over the status quo! {{u|Sdkb}}talk19:11, 14 April 2020 (UTC)
How long are you planning for the homepage to be a thing for? Could it transition into something more like the dashboard or community portal as editors become more experienced?
Great question! This comes up a lot -- the idea that experienced users could also benefit from some kind of homepage, and perhaps the page's contents could evolve as a user gains experience. For the foreseeable future, our team is focused on new editor retention. We think we're on a path to improving it, but we haven't quite cracked the problem yet. We want to stick with that for a while (at least another year), and then perhaps we could pivot to thinking about the later parts of a user's journey. MMiller (WMF) (talk) 17:44, 14 April 2020 (UTC)Signature refactored in
I'm not sure there are enough active hosts for every new editor to automatically have a mentor. If mentorship ends up being an opt-in feature, what will the page look like for editors without one?
This is definitely something we're concerned about as we deploy these features to bigger wikis. Just doing some projections -- let's say we think that it is comfortable for mentors to get something like 5 or 6 questions on their talk page per month. That's the rate of questions in Czech Wikipedia right now, and they have 15 mentors. English Wikipedia gets 100 times more new accounts per month than Czech Wikipedia. If we assume the same rate of asking questions, English would need 1,500 mentors in order for each of those mentors to only get 5 or 6 questions a month. This is obviously a super high number -- so we're not quite sure what to do about this yet. We'll be trying to experiment on some of the other large wikis, like French Wikipedia, which only gets 10 times more accounts per month than Czech Wikipedia, and figuring out what can work. What is your opinion on how to think about this? MMiller (WMF) (talk) 17:44, 14 April 2020 (UTC)Signature refactored in
The Teahouse hosts might have better insight about this. I can see advantages to having a single point person to be connected to, but having a Teahouse-like system allows for quicker and likely more knowledgeable responses. {{u|Sdkb}}talk19:11, 14 April 2020 (UTC)
"view your mentor's other conversations", presumably going to their talk page, seems unnecessary.
I understand why at first this may seem unnecessary. The reason we did it is because we thought that newcomers might want to gather some context about what a talk page is and what kinds of questions people tend to ask their mentors. They might be worried about asking a question that is too long, or too short, or embarrassing in some way, and perhaps checking out the page gives them confidence to ask the question. We do see newcomers clicking that link. What do you think about this angle? MMiller (WMF) (talk) 17:44, 14 April 2020 (UTC)Signature refactored in
Glad you like it! Our designer has definitely been inspired by Local Guides -- so that is good to hear. In the coming year, we're going to be expanding the "impact" concept to a broader "positive reinforcement" effort, thinking about how we can promote awards and recognition in effective ways. For instance, we hypothesize that awards may be more motivating when they come from people than from the system. So we're thinking about questions like: how might we promote "thanks" from experienced editors to newcomers? MMiller (WMF) (talk) 17:44, 14 April 2020 (UTC)Signature refactored in
The WikiLove and Barnstar systems are pretty established at en-WP, so you may want to be careful to make sure changes build on them rather than supplanting them, or there may be community opposition. {{u|Sdkb}}talk19:11, 14 April 2020 (UTC)
one issue with the impact module is that it doesn't take into account the type of edit
You're right that the current logic is really simple: if you've edited a page recently, it is in your impact module with the number of pageviews that page has gotten, whether you've changed one byte or written the whole page. The main goal with the impact module right now is just trying to drive home the idea to newcomers that their work has impact, but we still aren't sure the best way to give them a more granular understanding of the impact. Interestingly, we see a lot of newcomers return to that module and click on the articles they've edited in the past, either to just look at their work, or to continue working on them. MMiller (WMF) (talk) 17:44, 14 April 2020 (UTC)Signature refactored in
so it's essential that there be an option in preferences to disable it or it'll meet with a ton of community opposition
Yes, that makes sense. One thing I want to clarify is that when we turn these features on, we don't turn them on for all users -- just for newcomers registering after the date that the features are deployed to that wiki. The idea is that these are features are most important during a user's first days on the wiki. That said, we would be able to turn them on for broader groups of users if the wiki was interested. And yes, the help panel is collapsible, and it has a setting in the upper right that allows it to be turned off. MMiller (WMF) (talk) 17:44, 14 April 2020 (UTC)Signature refactored in
The help pages listed should be customized based on the type of article being viewed, so for instance, there should be links to biography policies/help pages for biography articles.
Good idea! We originally thought to personalize the pages in the panel based on the editor the user is in -- so different pages for mobile/desktop, or VE/wikitext. But I hadn't thought about different pages based on the type of article -- I've added it to our Phabricator task about personalizing the help pages.
Hi Sdkb -- thanks for these responses and clarifications. I just have a couple follow-ups if you have a moment:
Maybe add something like a small (not too prominent, and unchecked by default) checkbox at the bottom that says something like "the issue has been resolved (will remove the maintenance tag)".
Is your idea that such a checkbox would be there in the edit summary dialog, where the user also types their summary and says whether they want to watch the page? That's an interesting idea, allowing them to basically say, "Here's my edit, and I believe I have finished all the tasks on this article."
The WikiLove and Barnstar systems are pretty established at en-WP
Great point -- we will be mindful of how the existing positive reinforcement systems work on en-WP, so as not to undermine or confuse them. It's starting to seem like the best way to get that kind of recognition to newcomers is to encourage experienced users to use the existing forms of recognition rather than build new forms.
Yep, that's the thought. We'd certainly want to test it first to see if it results in editors improperly removing tags. And re awards, I agree with Nick's thoughts below. {{u|Sdkb}}talk17:45, 28 April 2020 (UTC)
New discussion: structured tasks
Hi all (especially Nick Moyes and Sdkb) -- I wanted to let you know that the Growth team is thinking about a new project called "structured tasks". It builds on the "newcomer tasks" project that we've already posted about here, but is geared toward breaking down simple editing workflows (like copyediting or adding wikilinks) into steps that are easy for newcomers to accomplish, potentially assisted by algorithms. We think this may help unlock editing for many newcomers, and so we're looking for community members to help us think it all through as we design and plan. The full project page is here on mediawiki.org, and the discussion is happening on the talk page. You're also welcome to discuss on this page. Sdkb already weighed in -- thank you! -- MMiller (WMF) (talk) 00:45, 19 May 2020 (UTC)
Awareness
Hi Marshall,
After seeing this on the AfC talk page today I've dropped it in a couple of other places, including the new WMF Village Pump page, the Discord, and the Wikipedia talk:Help desk (while less beginner-oriented than the Teahouse, they still handle a lot of that traffic), in the hope of driving a few more eyes towards it.
I was unaware of it until now, but will get some feedback in during the next couple of days, so I imagine some others are in the same position. Nosebagbear (talk) 09:30, 19 May 2020 (UTC)
Hi Nosebagbear -- thanks for checking out the page and spreading the word! I just found on Discord where you posted, but I don't usually keep an eye on Discord. Would you be willing to let me know if anyone follows up there -- I know you directed them to the wiki page, so hopefully discussion happens here. And I'm looking forward to your own feedback! -- MMiller (WMF) (talk) 16:55, 19 May 2020 (UTC)
Hello Sdkb, Nick Moyes, ProcrastinatingReader, Pelagic, Czar, and Barkeep49 -- I'm pinging you because you have all been following along with the development of the Growth features over the past years, and have shaped what they've become. Thank you for your support so far! In November 2020, we found that the features statistically improve newcomer outcomes. Because of these results, we're now confident in spreading the features to more and more wikis. Right now, they are deployed on 19 Wikipedias, including big ones like French, Russian, Arabic, Portuguese, and Polish (with no problems so far). We're talking with the German, Italian, and Spanish communities about deployment, as well.
I know that deploying these features on English Wikipedia would be a big decision, and require community consensus and careful planning. I'm asking for your advice on when and how to get such a discussion going, knowing that it might take time to unfold. One thing to keep in mind is that it will be easy to safely test the features in English Wikipedia by deploying them to only, say, 5% of new accounts. This way, if there are any issues with vandalism or patrolling, they'll be contained.
A rollout beginning with only a small fraction of new accounts certainly seems safe to me. The discussion could perhaps take place here, with invites to WP:VPR, WT:Help Project, WT:Teahouse, and possibly WP:CENT. I'd recommend placing {{Notified}} here to make it clear that the discussion was broadly advertised. {{u|Sdkb}}talk22:08, 26 February 2021 (UTC)
I think the first step is to put together what the ask will be. I agree with Sdkb that a small scale test to begin with (in the range of 3-5%) is going to help make consensus easier to achieve. If you go the formal consensus route, that is asking for an RfC, it will take 30 days (most likely) and then unless it's very obvious a formal close. It might be that for a small trial (3-5% for a month or two which given the number of accounts on enwiki might be sufficient for good data) could get by with a more informal consensus, along with notification as suggested by Skdb. To roll this out beyond a test group would definitely take an RfC which is why if data can be gleaned first, you can then do a very high profile ask including CENT. In terms of current notification I would just add WP:VPWMF to the list. If it goes "big" in terms of needing an RfC and all I'd also add WP:AN to the list of places to notify. Hope that all makes sense. Best, Barkeep49 (talk) 22:52, 26 February 2021 (UTC)
Would there be a way to specify an account that would be dropped into this test pool, so I could make a test account to get the feeling of what is like from a no script/permissions viewpoint? Regardless of that, the test method, run for month, generate feedback, generate summary of that, present to Community for full rollout all seems like a good route. Nosebagbear (talk) 01:33, 27 February 2021 (UTC)
Thank you all for weighing in with these ideas! As you recommend, I'm going to draw up a plan for which actions to take in which order, and I'll post here to see what you all think, before we start doing anything. -- MMiller (WMF) (talk) 17:29, 1 March 2021 (UTC)
@Barkeep49: I'm glad to hear you're enthusiastic! I've written up a proposed plan for how to go about a test of the features on enwiki, and I'll post it next week for you to take a look at. I'm hoping you (and other community members) can help publicize the test to places on the wiki that need to hear about it. Along those lines, I posted a message at Wikipedia talk:Teahouse to encourage some of the hosts to follow along with the work here, since the Growth mentor feature has some overlap with the work they do. -- MMiller (WMF) (talk) 04:29, 16 April 2021 (UTC)
Mentors for beta?
Hi @MMiller (WMF): - I'm looking forward to seeing your proposed en.wiki beta test outline and took a moment to re-read everything on the page above. Did the Growth Team come to any conclusion on how to handle needing so many mentors if the ratios seen on other wikis was scaled up to en.wiki's size? TH/HD obviously benefit that they have lots of people who answer questions who aren't technically "hosts" or similar. In any case, if your proposal includes any consideration of how to handle that aspect in the beta stage then I'd be happy to be part of any such group. Keep up the great work and great community interaction Nosebagbear (talk) 01:14, 19 March 2021 (UTC)
Thanks for taking a close read of the page, Nosebagbear. I think you're picking up on something important with the needs for mentorship. I just took a look at the frequency of mentor questions in other wikis, and there is a wide range, making it difficult to anticipate the volume that will happen on en.wiki. For instance, newcomers on Arabic Wikipedia ask about 5 times as many questions per capita as newcomers on Vietnamese Wikipedia. Czech and French Wikipedias are in between. I think the small-scale test will allow us to benchmark the volume of questions we can expect per capita on en.wiki. Another important variable is how many questions per week mentors would want to receive. On Arabic Wikipedia, the mentors are comfortable getting about 12 questions per week, but on French they are only getting about 3 per week. Taking these two variables together, we could estimate how many mentors we would need for full deployment. If that number ends up being prohibitively large, we'll have to take a step back and think about how the feature would need to be changed to work well for en.wiki. But I think for a test in which the Growth features only go to 2% of en.wiki (about 650 newcomers per week), we would be safe with only about 5 mentors signed up (based on the frequencies from other wikis). Does this all make sense?
I definitely think we should ask Teahouse hosts their opinion on mentorship. We wouldn't want the Growth features to conflict or confuse what the Teahouse is doing successfully. Hopefully, the two initiatives can be complementary. I'm going to post a draft plan next week, and I'll invite Teahouse hosts to reflect on these features and help us think through our plans. Does that sound right? -- MMiller (WMF) (talk) 06:24, 20 March 2021 (UTC)
Hi Sdkb, Nick Moyes, ProcrastinatingReader, Nosebagbear, Pelagic, Czar, Barkeep49, and Ipigott -- after taking in all your advice from this page and talking about it with the team, we've put together an outline for how we might try out the Growth features on English Wikipedia. The main goal of this plan is to determine the extent to which the Growth features would be a net positive for English Wikipedia.
We want these features to help newcomers become involved, without increasing the burden on the experienced users who monitor changes and answer questions. Because the plan proposes deploying to a small portion of newcomers, there will not be enough data to statistically calculate impact on metrics like newcomer retention (we can run such experiments further down the line), but there will be enough data to identify whether the features seem to be generating good edits without too many damaging edits and interactions. We'll also be able to benchmark the volume of edits and mentor questions we might expect when scaling up to more newcomers.
If this outline looks good to you, I can ask people from potentially interested groups (like Teahouse and Help Project) to look it over, as well. And then, most importantly, we'll need your help to make sure that sufficient notice is given around the wiki such that it's okay to proceed -- since you all know the right way to unfold a project like this. We're not in a rush to proceed with this; it's more important that community members have had a chance to weigh in to make sure we do it right.
We make the Growth features available for all users as preferences defaulted off. This means no users would have them on by default, but would allow community members involved in this discussion to turn them on manually and try them out. It's important to note that any users who notice these checkboxes in their preferences would also be able to turn them on, but we would expect very few people to do that.
To try out the mentorship functionality, we would need to sign up about five community members to be mentors. We would make a sign up page to list these usernames (like this, as on other wikis), and the feature will read the mentor names automatically.
Community members take a couple weeks to try things out, ask questions, and identify any issues.
When we're ready, we start deploying to 2% of new accounts. This means that for all accounts created after the deployment, a random 2% of them will have the features, and the rest will not. On English Wikipedia, this will amount to about 2,600 accounts per month. Looking at trends on the other wikis with the Growth features, that might yield something like 500 article edits and 100 mentor questions per month (though this varies so much by wiki that it is hard to predict). We expect five mentors to be able to handle the question volume.
During the test, if anything problematic is occurring, like runaway vandalism or abuse of the mentor feature, we'll be able to discuss and turn off the feature if needed.
After a month of deploying to 2% of newcomers, we'll evaluate how things have gone. We'll be able to see all edits and mentor questions made through the features using edit tags in Recent Changes. Specifically, we will want to look at:
The revert rate of suggested edits. We want that rate to be about the same as or better than the usual revert rate for newcomer edits on English Wikipedia (about 15%).
The volume of mentor questions. This would allow us to extrapolate how many mentors would be needed to handle 100% of new accounts. In English Wikipedia, it's possible that this would be in the hundreds, which the community might consider unmanageable. If that's the case, we'll need to rethink the way the mentorship feature should work on this wiki.
The quality of mentor questions. While on other wikis that have Growth features, the majority of mentor questions are appropriate for wiki work, it will be important to get a sense of whether that trend holds up on English.
Then we'll discuss the results here and decide what, if anything, to do next. If things go well in the test, perhaps a good next step would be to deploy to 25% of newcomers, in preparation for deploying to 100%. And perhaps community members will think it is appropriate to set up an RFC before scaling the feature up.
How does this sound? Is this a plan that it would be okay to get started just with consensus of the users on this page, and then an announcement when it begins? We definitely need help from you all to navigate the right way to go about this in English Wikipedia. -- MMiller (WMF) (talk) 19:28, 23 April 2021 (UTC)
@MMiller (WMF): while the plan seems fine, is there a reason you don't think that, say, 5% would be viable as a trial rate - or just an abundance of caution? If that 5% (c. 6500 accounts/month) could allow the retention question to be answered that would be a big plus. On the consensus one, hmmm, I'd drop a notice on VPR pointing to this page if I were you - it would help prevent issues when you roll to the 25% stage with individuals say they missed a chance to hear about it at the start. I'd also be happy to be one of the mentors. I'd suggest more than 5 - if a couple of us took a week off it would have a substantial impact. We'll still be able to figure out if we'd be overwhelmed even we're receiving comparatively few questions per mentor by use of some suitable maths. Nosebagbear (talk) 19:39, 23 April 2021 (UTC)
Thanks for looking it over so quickly, Nosebagbear. I did propose 2% to be cautious -- it is about the smallest number with which we could get a good sense of how things go. Unfortunately, even taking it up to 5% would not allow us to scientifically detect increases in things like retention without several months of data. That's because retention is a rare occurrence (about 5% of new accounts end up being retained), and so when we increase that small number, it is a small increase to a small number, requiring lots of data to build up statistical significance. Perhaps an experiment like that, though, could be possible at the 25% threshold.
I'm glad you're willing to be a mentor! And yes, I think it would be fine to have more than five. The only thing is, I don't think it should be too many: if we have, say, twenty, then it's possible that each mentor only gets a couple questions and some get none. That would make it hard for the mentors to speak to what it would be like to mentor under higher volume. Based on your advice, I think we should shoot for about ten mentors. -- MMiller (WMF) (talk) 19:56, 23 April 2021 (UTC)
I had the same thought as Nosebagbear, but that makes sense. If there would be benefits to starting out at the 5% level rather than 2%, I think there would likely be plenty enough editors interested in being mentors to prevent the volume from becoming too much. But I definitely understand/appreciate the impulse to roll out cautiously, so 2% sounds fine as an initial level. {{u|Sdkb}}talk21:56, 23 April 2021 (UTC)
If I remember correctly, the suggested edits functionality is only available on the apps (iOS and Android)? Will it be available on mobile web or desktop? Is the platform availability the same for mentor questions? Whilst I think 20 questions per mentor per month is reasonable, I feel like getting more than 5 mentors is a good idea for safekeeping (to stop anyone being overwhelmed, for example). A couple of the regulars/hosts at WP:Teahouse & Wikipedia:Adopt-a-user may make for a good choice for mentors, and even if not they may be well positioned to advise on your plans in general (pinging a handful of names from those pages I know of and think would be a good fit: @CaptainEek, DESiegel, Dreamy Jazz, Rosguill, Bilorv, Oshwah, and Joe Roe). ProcrastinatingReader (talk) 19:56, 23 April 2021 (UTC)
@ProcrastinatingReader: you're right that until recently, suggested edits were an experience only on the apps. What the Growth team has done is adapt those learnings for mobile web and desktop. All the features we're talking about (including suggested edits and mentorship) are for the web, and so can be exposed to the bulk of the English Wikipedia users (when we're ready). Thank you for pinging some potential mentors! I'm looking forward to hearing what you think of this whole feature set/plan, and also hope that you'll be part of this test group of mentors. -- MMiller (WMF) (talk) 20:02, 23 April 2021 (UTC)
I would note that I'm a bit busy at the moment, but I would be happy to be a mentor as I look at my notifications at least once a day. I would advise that 5 mentors is probably too small and 10 seems better. Dreamy Jazztalk to me | my contributions20:56, 23 April 2021 (UTC)
Are people getting assigned mentors at random, or choosing them (maybe based on their self-descriptions)? I'm potentially interested in signing up at a later date and this does look like a very good plan overall. I started editing in 2013 with the "gettingstarted" featured (I think now defunct) and it was really helpful, I think. — Bilorv (talk) 22:32, 23 April 2021 (UTC)
Hi Bilorv -- Presentation of the "mentorship module" on the newcomer homepagethanks for checking out the plan. The way the mentorship feature works now is that when an account is created, a mentor is assigned at random to that account from the list of mentors. Then the newcomer sees their mentor on their homepage, along with whatever the mentor sets as their "introductory" blurb (see image at right for what this looks like). I agree that it could be good for newcomers to choose mentors based on their descriptions, or perhaps based on shared interests -- like if mentors selected a handful of interests from a list (e.g. "math", "music", "engineering"). One consideration here is that we believe there's some value in just showing newcomers that they already have a mentor assigned, as opposed to making them proactively choose one. We think (but don't know for sure) that it makes more of them comfortable with asking questions. I definitely think we should explore this idea of matching mentors more deliberately in the future. -- MMiller (WMF) (talk) 23:11, 23 April 2021 (UTC)
That all makes complete sense. I think the optimal thing might be to have mentees choose tags initially that are used as both the basis on which mentors are assigned and the initial/default settings for the pages/tasks they're suggested, but I imagine that's quite a big thing to achieve technically into an already-existing system and assigning a mentor at random is definitely alright and has its advantages. — Bilorv (talk) 01:46, 24 April 2021 (UTC)
@MMiller (WMF): - what happens if a Mentor doesn't answer a question in, say, a couple of days? Does it just no get answered, or is there a mechanism to drop the question to another mentor? And while not relevant for the trial, if a mentor withdraws themselves from the list, will the system allocate a new mentor to those now without one? Nosebagbear (talk) 23:20, 23 April 2021 (UTC)
@Nosebagbear: good questions. I think you're touching on something that is both a strength and a weakness of the mentorship feature. We wanted to build it so that questions would get posted to a place that mentors already look at and use (i.e. their talk page), as opposed to some new page that they have to check separately. That means, though, that after a mentor question gets posted, it's just a talk page revision like any other one, and doesn't have special properties with which we could do something like transfer it to another mentor. That said, there are a few things we've added and are working on that help:
Mentor dashboard: this is the biggest upcoming improvement to how mentorship works. In most communities where we've deployed mentorship, the mentors ask for a way to see who their mentees are and how they're doing. The dashboard will show the list of mentees and stats about them, and will eventually also contain a module to list unanswered questions (just done by parsing wikitext from the mentor's talk page). Perhaps in the future we could consider a central place to list all unanswered questions so that mentors can keep each other accountable and cover for each other. What do you think? You (and everyone) are welcome to chime in with opinions on that project's talk page. We're just beginning development on that project now.
Mark as away: we have some work in progress through which a mentor could mark themselves "away", and that would cause all questions asked to them to be redirected to substitute mentors (Phab T227876)
Claim Mentee: randomly assigning mentors works well for newcomers that organically create accounts, but it causes issues for organized editing events. Say that someone is teaching a group of 15 people how to edit Wikipedia at an edit-a-thon: they want to be the mentor of all fifteen of them; not for them all to have random mentors. With this feature, a mentor can "claim" all those mentees by entering their usernames into the special page after their accounts are created.
For your question about what happens if a mentor withdraws themselves, what happens is that we stop assigning that mentor to new mentees, but the old ones retain them as their mentor on their homepage. We don't yet have support for reassigning mentees to a new mentor. We don't expect this to have been too much of a problem because mentees usually ask questions during their first couple days on the wiki; it's not like a mentor withdrawing themselves continues to get many messages from their legacy mentees from months past. But it is something we would like to add in the future (it's a similar use case to the "Mark as away" one from above).
Those all sound like good things - I'd certainly think a general pool of unanswered questions would be good, though you'd probably want it to have some max time or an ability for individuals to remove it from the list without answering it (such as if wasn't actually a question or similar). Nosebagbear (talk) 00:37, 24 April 2021 (UTC)
The plan is very well thought out already IMO, so not much I can add there! In addition, I'd like to say thanks for being one of the most communicative product managers I've seen in a while (in general at any company, not just in a WMF-enwiki sense). I'm sure the rollout will go well! Re mentoring: not sure I can mentor in this pilot, in part because I'm trying to refrain from anything feeling like a commitment at this time. ProcrastinatingReader (talk) 09:34, 24 April 2021 (UTC)
I've dropped a note on WP:VPR giving a mention of this discussion - I don't think it needs actual Village Pump agreement, but with a mention those who have an interest but have missed it thus far can come review the plan. Nosebagbear (talk) 23:13, 23 April 2021 (UTC)
This sounds like a great idea!! I would be more than happy to be a mentor, editor retention is my absolute number one concern on Wikipedia and I am a frequent adopter and help question answerer. CaptainEekEdits Ho Cap'n!⚓00:54, 24 April 2021 (UTC)
Hi all
In case it might be relevant, you might like to look at the old Wiki Guides pages.
It was an idea from the WMF to try and retain new editors. Unfortunately, I had to drop out due to real-life issues a few months after start up, and have only discovered it's demise in the last few days after a conversation with another editor - User_talk:Jay#Resources_page.
I was really only involved with the infrastructure creation, and some discussions, and just assumed it was plodding along welcoming new editors and guiding them through the intricacies of WikiWorld.
It only lasted five months, which I could not understand, after such a promising start, why had it failed?
After a bit of research I discovered it seems the community decided to go down a different path.
It is sad, because in 2019, 8 years after it's demise, the retention was 10% less, with over double the edits of 2011 (see discussion with Jay for table of figures).
It seems that the only thing to come out of it was consensus to make only autoconfirmed editors capable of making new pages - which is, to me at least, an appearance of being diametrically opposed to the principles of an encylopedia that anyone can edit.
It really is perturbing that such a promising start was so easily turned into a puff of smoke.
Please, do read the material, as I wonder how many OTHER times this sort of effort might have been started and waylaid in the last 10 years!!
Hello Chaosdruid -- thank you for pointing out the Wiki Guides project. I think in addition to that project, there was also the Adopt-a-user program, and of course, the Teahouse. I believe that of those three, the Teahouse is the one that showed the most success in newcomer outcomes. There are a couple of interesting papers about those latter two:
I think that the mentorship capabilities in the Growth features are more similar to the Teahouse than to the Wiki Guides or Adopt-a-user programs, in that it is meant to be quicker and more transactional. Newcomers frequently have a quick question when they get stuck (e.g. "How do I add a photo to an article?"), and fewer of them are looking for the longer-term mentorship relationship that Wiki Guides and Adopt-a-user were meant to foster. With the Growth features, those longer-term relationships can certainly happen organically, but there's no commitment required from the newcomer just to ask their first question. I think we'll see how that looks and feels on English and then reflect. -- MMiller (WMF) (talk) 23:08, 27 April 2021 (UTC)
No worries, I was more concerned with the table I made though, which clearly shows a 10% lower retention rate by 2019 after around 10 years trying to make it better !! (I would have used current figures, but couldn't work out how to get the new tool to do it) Chaosdruid (talk) 06:28, 28 April 2021 (UTC)
This plan sounds like a great idea, and I'd like to be a mentor. I usually fight vandalism, and it's honestly quite sad to see how many editors are just confused about why their edits were wrong (although, I must say, many of them are SPAs). I created a separate section for a list of volunteer mentors. Pinging User:Nosebagbear, User:Dreamy Jazz, User:CaptainEek (who have previously volunteered to be mentors). Although, one thing: The mentor system seems like the Teahouse except more personalized, and slower response times. Looks like we're trading speed for personalization. Well, there's only one way to find out if it works! Sungodtemple a tcg fan!!1!11!! (talk) 13:21, 29 April 2021 (UTC)
Hi @Sungodtemple -- good question, and thanks for trying the features out. The articles are sourced using maintenance templates (like the ones you've put on your example page), which indicate that the article needs links, copyediting, etc. Next week, we'll start setting this up for English Wikipedia, and I'll ask community members to indicate on a Phabricator task which maintenance templates they want to align with each task type (here's an example of when we did this for Russian Wikipedia).
For Test Wikipedia, we've just hard-coded the test articles into the feed, i.e. we're not actually replenishing it with new articles as templates get added to them. So here's how to try the workflow out on Test Wikipedia:
Go to the "User profile" tab of your preferences, and turn on both homepage checkboxes at the bottom.
Go to the "Editing" tab of your preferences, and turn on the help panel.
Click you username along the top of the page to go to your homepage.
Choose a task from the feed.
Please let me know if the above works!
Also, you might be interested to read about something we're planning for the future around how the articles get "chosen". We're soon going to pilot a way to do this algorithmically on a few wikis, in a task type called "add a link". It will find articles that need wikilinks added and then point the user to the specific link suggestion based on an algorithm. We think this will help new kinds of people edit easily, especially from mobile. MMiller (WMF) (talk) 18:09, 30 April 2021 (UTC)
Hello future mentors! I'm Trizek (WMF), community relations specialist supporting the Growth team. I'm taking care of the configuration of the features for the trial.
First of all, thank you for volunteering for this trial.
To try mentoring features, we need a mentors list, hosted somewhere at English Wikipedia. This list must be formatted in a certain way:
mentors have to sign up using this special formatting [[User:Name]]|Description (add no links nor wikitext in it, it will break)
The Description is a short introduction of yourself that would encourage newcomers to contact you.
Protect that page. We advise to protect it so that only Extended confirmed users can sign-up. This would prevent well-attentioned but not-much experienced users to sign up.
MMiller (WMF), Trizek (WMF): I'm excited to see a trial of these Growth Team features on en.wiki! If at all possible, it would be best to avoid assigning mentors to Wiki Education student editors (typically identifiable soon after they sign up by a userpage template that adds Category:Wiki_Education_student_editors), especially during the trial period when the experience for new users will vary randomly. It can be very confusing and disruptive when some student editors have a significantly different user experience from others.--Sage (Wiki Ed) (talk) 17:08, 18 May 2021 (UTC)
Hi @Sage (Wiki Ed) -- thanks for checking out the features and thinking this through. We've definitely heard from other wikis that having treatment and control groups can be confusing in the event or program setting. We're working on building up enough data so that we can be giving the features to 100% of users instead of varying the experience. I'm trying to think what we should do here so that Wiki Ed students (and other users at events) are not confused. Would you say your primary concern is the students having differing user experiences? Or do you expect that the Growth features themselves are disruptive to the Wiki Ed workflow, in which they get a popup saying "go to your homepage to get started", they would all have a randomly assigned mentor, etc? Would that be disruptive? MMiller (WMF) (talk) 01:31, 25 May 2021 (UTC)
MMiller (WMF): We're mainly concerned with students having different user experiences from each other, which will result in a lot of emails from confused instructors and students. If it's possible to disable the new features via the API, we could probably incorporate that into the onboarding flow. (We already make an OAuth preferences edit upon enrollment to standardize VE settings.) But if/when it gets to 100%, we can work with it one way or another, by either updating our training modules to include it or by automatically disabling it.
@Sage (Wiki Ed) -- thanks for the clarifications and the brainstorm. I'm going to bring this up with our team's engineers next week to generate some thoughts on what we could do. In this section below, I've proposed that we start giving the features to 2% of new accounts starting June 7. We might not have a solution to your questions by then -- I'm hoping that giving the features to 2% of users would be a tolerable amount of disruption for a few weeks. Do you think that would be okay? MMiller (WMF) (talk) 01:02, 27 May 2021 (UTC)
MMiller (WMF): We're transitioning into the summer term classes now, which typically total under 1000 new student editors, and only a fraction of that over any specific period of a few weeks. We should be able to handle the likely handful of student editors who end up in the test condition. Can you clarify whether or not it will be possible for us to use the `options` API to disable these features during the test phase? If so, I could implement it now and we won't have to worry about it much either during the test period or later on.--Sage (Wiki Ed) (talk) 16:32, 27 May 2021 (UTC)
Hey @Sage (Wiki Ed) -- we realized today that the Growth features conflict with the GettingStarted extension on this wiki, and we're thinking about whether it's time to deprecate GettingStarted, since it's a seven-year-old project that is being superseded by the new Growth features. I wanted to ask you -- how do WikiEd operations handle that? I believe all new accounts get that popup. Do you work it into the WikiEd flow? Or tell students to dismiss it? Or something else?
MMiller (WMF): The GettingStarted extension never caused us much problems, likely because it's easy so easy to dismiss. It doesn't also doesn't disrupt any expectations from our training materials, and new users who create their accounts via a link from the Dashboard don't get the popups anyway, since they return to the Special OAuth page upon creating an account. (I do think it makes sense to turn off GettingStarted at this point.)--Sage (Wiki Ed) (talk) 21:51, 8 June 2021 (UTC)
Growth features are now available at English Wikipedia. They aren't available for newcomers yet, only experienced users can enable them in their personal preferences.
To test the tools, please go to your user preferences on one of these wikis and then:
This will give you access to the Homepage (Special:Homepage), and, from there, you will be able to:
contact your mentor
select your favorite topics and tasks to make some Suggested edits
browse help pages
see your impact
You will also see the Help panel being visible when editing, or browsing help pages.
We encourage you to actively try the tools, both on mobile and desktop if you can. The tools have been configured to use some templates and help pages, but these may not be the best ones. Please let us know if you think some elements should be changed.
Please share your questions and thoughts with Marshall and myself, by creating a new section on this talk page. Please also check the documentation and the FAQ about these features.
@Sungodtemple, MMiller (WMF): this is really good stuff. Some comments. 1) the text in the popout help menu advances fairly quickly. We have a large number of non-native speakers and I worry that it will go too fast for them. How was that speed determined? 2) When I first opened the screen Mohammad Shahabuddin was my most viewed article which makes sense since he's been in the news. However, after I applied page protection to it, it dropped off and YouTube became my most viewed (which was the article I would have expected). What is the logic that is determining what articles to exclude? Best, Barkeep49 (talk) 15:03, 5 May 2021 (UTC)
It advances quickly to show users they can discover the different steps. We are considering to change this design.
The logic is to show 5 articles max edited by the user, with most seen articles first. The number of views is the one for the last 60 days, as indicated. However, we never considered the interactions with admin actions. This is something we need to investigate.
Well the admin action does create an edit in this case (adding the PP icon which is why it was on there in the first place). I wondered if it intentionally dropped off the list because I semi-protected it (i.e. the list was designed to exclude pages with page protection). This doesn't seem to be the case. so I'm glad I reported it. Best, Barkeep49 (talk) 16:15, 5 May 2021 (UTC)
Oh I've figured it out @Trizek (WMF). It's showing me views since my most recent edit. Since I edited that article today there is no updated data for how many views its had. Is there a reason that it's being calculated from the most recent rather than the first edit to the article? Best, Barkeep49 (talk) 16:33, 5 May 2021 (UTC)
Impact is calculated on the edits you made yesterday and the days before. When the module is empty, it encourages newcomers to make some edits. We only show the page views if some edits have been made, with a delay. Trizek (WMF) (talk) 17:59, 5 May 2021 (UTC)
@Barkeep49 -- I just want to add some detail to @Trizek (WMF)'s explanation of the auto-advance in the help panel. The steps advance every five seconds, not because we expect the users to read each one during the five seconds, but rather so that the changes draw the user's eye to the panel such that they discover that there are different steps to look at. Then they can click on the tabs to read at their own pace. We have an idea, though, to change the panel from having those numbered tabs for each "quick tip" to instead having arrow buttons to navigate back and forth through them.
About page protection, it's possible that protecting pages changes the way they're processed for the impact module. We'll look into it.
I would strongly suggest that cycling through is not helpful because they are linear and we won't them reading them all. However you all do it, I'd make that change personally. As for impact, I really do think it's a bug. When I first looked at the page Shahabuddin was there. I edited the page and it disappeared and it has stayed gone. If it was because I also protected it well that's a bug no genuine user of the tool will come across. But I would encourage you to test it to make sure that's what it was because. And no @MMiller (WMF) I do not intend to be a mentor at this time, as my arbing and UCoC drafting means that I can't be assured of having any wiki capacity at a given moment and don't want to take on a newcomer who I may not be able to adequately support. Best, Barkeep49 (talk) 02:12, 9 May 2021 (UTC)
You may notice new users who create an account, and then turn the Growth features on. It can happen since a lot of new accounts are created daily at English Wikipedia. Since the tools have been promoted for other wikis (where they are active now) and the documentation on mediawikiwiki explains how to enable the features, some users will connect the dots! We may also have the case of some curious people who check on their preferences and try to tick a box. This may lead to suggested edits being made by new users, or some (real) questions being posted to mentors. Consider it as a pre-trial! :) Trizek (WMF) (talk) 17:59, 5 May 2021 (UTC)
@Sungodtemple -- yes, we have separate tags for those two types of mentorship questions so that we can see where the questions are coming from. In other wikis, mentorship module questions from the homepage are more common than ones from the help panel. MMiller (WMF) (talk) 01:35, 25 May 2021 (UTC)
Configuring links and templates
@CaptainEek @Barkeep49 @Sdkb -- I'm starting this new section to talk more generally about the configuration questions you raised in the section above. The links and templates used in the Growth features are totally configurable! We pre-populated them using Wikidata, but it is easy to change any/all of them based on your guidance.
Speaking directly to your question, @Sdkb, we are actually undertaking an effort to make it possible for communities to modify these things on their own without our team's engineers. Here's the project page for how we're doing it, and we welcome everyone's thoughts on the talk page.
For now, there are some parts of the Growth features that communities can modify directly, and some that we need to do on our end.
Growth team needs to do it
This includes help links in the "Get help with editing" module on the homepage, and the text and links in the help panel once you're on an article.
The easiest way to change these is to leave us a comment on this Phabricator task with what should be changed. You can also leave comments here on this talk page.
Community can do it
This includes the templates used to identify which articles should be in the newcomer tasks feed (i.e. which need copyediting, links, references, etc.) and the help links that go along with those articles in the feed.
These are governed by the JSON config file here on wiki. If you have the appropriate role and are comfortable with editing the JSON, you can change that page and the features will update within a few minutes.
The important thing about this set of configurations is choosing the right templates for newcomer tasks. For instance, you can see that right now, there are nine templates listed for copyedit. In other words, any articles that have those templates can show up in the task feed for newcomers. We want to choose enough templates so that there are plenty of tasks even when users narrow to a specific topic (e.g. "Sports" or "Physics"). This special page shows how many tasks are available for each topic and task type. Right now, there are plenty of articles for all the task types except for "Add links between articles", which only has about 1,500. But we couldn't find additional templates that belonged in that group.
If you don't want to modify the JSON page, you can also leave comments here or on that Phabricator task and we can make the modifications.
Thanks for the background, MMiller. I'm not surprised linked has the fewest because it's already an easy task to get done. I'll leave it to @Sdkb to submit the changes for what is linked because I think he's got a better vision for it. Best, Barkeep49 (talk) 02:08, 9 May 2021 (UTC)
I have the comments here about appropriate link targets. I think those need to be changed before this goes live. As for customisability, I think it's fine to do things that don't scale like hardcoding the values. Eventually it'd be nice to make it customisable but IMO I don't think it hurts to leave this for later.
Hello @ProcrastinatingReader, we're actually working on allowing communities to change links easily as we talk , as part of making the features scalable. Once deployed to your wiki, there will be a community configuration special page that can be used to customize various aspects of the Growth features, including the links displayed in the help panel. You can find a project page about community configuration at MediaWiki.org, and I'm excited to hear what you think about it. You can leave any notes at the talk page. Martin Urbanec (WMF) (talk) 13:36, 10 May 2021 (UTC)
@ProcrastinatingReader, regarding the email, we assume that most people know how to use an email. As a consequence, we encourage users to add their email so that they can get notifications, like when they are mentioned by other users on wiki. Communication with other users all happen on the wiki: we aren't creating a new messaging system based on emails. Trizek (WMF) (talk) 13:00, 11 May 2021 (UTC)
@Trizek (WMF): I get you might show a prompt asking a user to link their email if they don't have one linked, but since I have for a while it just seems a bit strange IMO to see "Email: [my email here] (change)" every time I visit the page. ProcrastinatingReader (talk) 16:10, 11 May 2021 (UTC)
I understand your point. I also know from experience some people who forget to upgrade their email address on websites they are active on when they change it. This design element could be changed (it up to @MMiller (WMF) to consider it), but I'm a "better safe than sorry" person there. ;) Trizek (WMF) (talk) 16:58, 11 May 2021 (UTC)
To follow up on this section, we got good suggestions from Sdkb on the Phabricator task and updated the help links in the help panel. Please feel free to check them out and see if you recommend any other changes! -- MMiller (WMF) (talk) 20:33, 14 May 2021 (UTC)
Feedback after trying out tools on enwiki
I think this will be a great addition for newcomers. Referencing my own experience as a newcomer, I was unsure what to do when I first came here and who to ask for help. Some suggestions for improvement:
Help panel --> General editing help --> How to write a "good article" leads to the MOS - surely there are other things to keep in mind to write a "good article"? (verifiability etc.) I note that these are covered in later links, but this is the first one in the menu and phrase used is rather broad. For a newcomer, it could also be a bit daunting when presented with a long manual like MOS on the click of "how to write an article" - in comparison to the more user-friendly tutorials we have for other links.
Homepage --> Suggested edits --> Hard has a grayed out box: "create a new article" with reasoning as to why it isn't suitable for a newcomer. Is the box perpetually grayed out - if it is, it could confuse some users as to when they will be allowed to create articles directly in mainspace.
Overall I found the system user-friendly and helpful. Apologies if any of this has been brought up above :-) Pahunkat (talk) 08:58, 9 May 2021 (UTC)
As suggested in the discussion above, he link about "How to write a good article" will soon be changed to Help:Introduction to the Manual of Style/1. You comment is like a +1 in favor of this change! 👍
"Create a new article" checkbox is greyed out by default. Consider it as a placeholder, but this may change. At the moment, we encourage people to work on easier tasks, so that they can become more familiar with Wikipédia's processes and culture. But there is a link below the inactive checkbox that allows newcomers to directly create an article if they like to. It is phrased this way: "To successfully create a new article, you'll need to use many of the skills you can learn through completing some easier tasks. To learn more about how to create a new article, click here."
Hi @Pahunkat -- thanks for trying out the features. I'm glad you think we're on the right track. One other thing to add to what @Trizek (WMF) said: we know that lots of newcomers come to the wiki intending to create a new article, but they don't realize how difficult it is. We expect that when they arrive on their homepage they are likely thinking, "Okay, where is the button to create a new article?" We actually want them to try easier tasks first, but we wanted a way to acknowledge that we understand they want to create a new article, and that's why we addressed it with the presence of the gray box. MMiller (WMF) (talk) 20:37, 14 May 2021 (UTC)
Feedback on the feature
After testing this feature for a bit, I find it very helpful! I just have one concern:
On all Wikipedia pages, the left-most tab is the page tab and the one to the right of that is the talk page. On the user's userpage, however, the homepage tab is the left-most tab. When I first noticed this, it felt a bit disorienting. If the tab could be the right-most tab or something, it would probably be more helpful.
Thank you for your appreciation, Aknell4. Can you explain a bit more why you think the tab that goes to the Homepage should be in a different order?
The resonating is the following for this new design: this is the only case where newcomers will see 3 tabs on the left side of their personal pages (Homepage, user page and user talk page), and most newcomers are true newcomers who aren't ware of the existence of the previous state, with the duet user page/user talk page.
Thank you for your reply! I was thinking that on all pages other than their personal pages have the Page tab on the left side and the Talk tab to the right of that. I would think it confusing for someone to go into their userpage and find a homepage tab on the left and the Page tab to the right of that. I also thought it odd that it was called "homepage" and I initially thought it to mean the main page.
Well, actually newcomers access their homepage by clicking on their username, at the top of any page. So the tab for the homepage is at the right place now. :D
We named the Homepage the homepage because the actual homepage for the wiki is called "Main page". As a consequence, we are using "homepage" since the very beginning of this project. But each community has the possibility to change this name.
@Aknell4 -- thank you for trying out the features and thinking about them. I'm wondering what you think a stronger name for the page might be. I've learned that some communities have translated it to "Dashboard" or "Start page". MMiller (WMF) (talk) 20:39, 14 May 2021 (UTC)
@MMiller (WMF): Thank you for replying to my suggestion! I would say that "Dashboard" is more descriptive of the homepage, as the homepage acts more like a dashboard. This would also alleviate the problem I addressed earlier about "Homepage" being mistaken for the Main Page. --Aknell4 (talk • contribs) 20:47, 14 May 2021 (UTC)
Mobile help icon
I love that this is incorporated on the mobile version! My one nitpick however is that the icon is too large and obtrusive. It would be better if it were reduced to like 75% or 50% size, or if it could be like collapsed. CaptainEekEdits Ho Cap'n!⚓04:08, 11 May 2021 (UTC)
@CaptainEek -- thanks for bringing this up. It's definitely a challenge to design and build for the small mobile screen! I'll pass along your thoughts on the size of the button to our team's designer. Did you feel like it was covering up or blocking things you were trying to do? Or more that it was large and distracting? MMiller (WMF) (talk) 20:41, 14 May 2021 (UTC)
Having said that, I notice that on mobile web it also gives me a total-views number in addition to the top five. Pelagic ( messages ) – (09:29 Sat 22, AEST) 23:29, 21 May 2021 (UTC)
Thanks for checking things out, Pelagic! I'm glad to hear that you found the impact module interesting. It's quite a simple module now, and we have plans in the coming year to make upgrades to it so that users can do things like: see more than just five articles, have more engaging visuals, be able to sort and filter, etc. This is the beginning of the project page about the work, if you'd like to follow along. -- MMiller (WMF) (talk) 01:20, 25 May 2021 (UTC)
@Pelagic -- we've had ideas in the past around highlighting or otherwise pointing out where in the article the template is. I think you're touching on what might be a simple way to do it: just scroll the page to where the template is. The downside, though, is that it might be disorienting for a newcomer to load an article to its middle, as opposed to at the top where the title and infobox are. I agree that we should figure out a graceful way to point out the maintenance template. The issue you're talking about is just one of many problems with using maintenance templates to surface tasks, and that's why the Growth team has been focused on generating tasks without using templates, instead using algorithms. You can see that work happening here with the "add a link" structured task, which we're going to be trying out in a few non-English Wikipedias in a couple weeks: https://www.mediawiki.org/wiki/Growth/Personalized_first_day/Structured_tasks/Add_a_linkMMiller (WMF) (talk) 01:25, 25 May 2021 (UTC)
Could I check usage
Could I check both whether I have correctly added myself to the mentor list and how much activity we've been getting in terms of mentor questions, as I have not yet been asked any questions? Nosebagbear (talk) 11:48, 25 May 2021 (UTC)
@Nosebagbear -- yes, everything is in order with your signup. The reason you haven't gotten questions yet is that we've not yet actually begun the test! The features are still in "dark mode", in which people only get them by flipping them on in their preferences. This has resulted in a few mentor questions from newcomers who have stumbled upon their preferences, but not very many. We're now talking below about when to start actually giving the features to new accounts. Please weigh in! MMiller (WMF) (talk) 18:54, 26 May 2021 (UTC)
We've gotten almost entirely positive reactions on this page, at WP:VPR, at Talk:Teahouse, and in a few other places.
We have 14 mentors signed up, which I think is a good number. Any more might be too many for the small scale of the test.
We've also gotten feedback on tweaking the templates and help links on the homepage.
There have already been 141 suggested edits completed (revert rate about 10%) and 41 mentorship questions, both from experienced users trying things out and from newcomers who have stumbled upon the preferences.
All this adds up to me thinking that we're about ready to start the test of giving the features to 2% of new account creations (~2,600 accounts over the course of a month). I propose that we start on Monday, June 7 (the idea is to begin at the beginning of a workweek, so that if anything goes wrong within a couple days, staff will be available to address it).
Please let me know what you think about this! Also, I'm wondering if anyone could help us announce/inform about this test in the right places. @Nosebagbear, you helpfully posted to WP:VPR initially. Is that where you think we should follow-up? Or are other places also good to announce this? MMiller (WMF) (talk) 18:52, 26 May 2021 (UTC)
Sounds good to me. I would suggest a post to VPR, as well as FYIs to WT:TEAHOUSE and WT:HELPDESK, as issues with the mentor system are most likely to end up there, and the respective hosts who are not mentors should know. Nosebagbear (talk) 21:25, 26 May 2021 (UTC)
Why is everyone saying "sounds good to me"? I have no qualms, just a little strange. Anyways, the trial sounds good to me! ;) Sungodtemple (talk) 11:48, 27 May 2021 (UTC)
@Sungodtemple: I'm personally putting it down to people not being sure what to do when a WMF product manager doesn't just meet but actually exceeds what the Community hopes for in terms of community engagement - none of us know how to cope with it! I just hope MMiller can cope when we tell Community Engagement to have him run workshops on how to do it right. Nosebagbear (talk) 11:53, 27 May 2021 (UTC)
Thanks for all thumbs-up! We'll start the test on June 7, and I'll post here when we've started it. I'll also post to VPR, WT:TEAHOUSE, WT:HELPDESK, and a few other places. -- MMiller (WMF) (talk) 00:45, 2 June 2021 (UTC)
Hello @Sungodtemple -- thanks for checking. We decided this morning to delay one more day to tomorrow, because we noticed one thing in our code we needed to tweak: we've never deployed to a percentage of a wiki that wasn't a multiple of 10 (i.e. 10%, 20%, 30%, etc.). In order to deploy only to 2%, we needed to make a change which is being merged today and will be ready tomorrow. I'll (hopefully) return tomorrow to let everyone know we're off to the races! MMiller (WMF) (talk) 17:57, 7 June 2021 (UTC)
Test has begun -- and question about "GettingStarted"
Hello everyone -- we began the test today, deploying the Growth features to 2% of new accounts! Thinking about the rate that new accounts get created, I would estimate that something like 50 newcomers received the features so far. Thank you all for the discussions and planning that led to kicking this off! I'll be posting here with updates as we gain data and learnings.
There is a question that I want to bring up and that we noticed today after deploying. English Wikipedia has a legacy feature called "GettingStarted", which is a guided tour for newcomers that pops up after they create their account and asks them to make an edit. This was built about eight years ago by WMF and has been on English Wikipedia ever since (see the accompanying image). I know @Bilorv is familiar with it. The work on that feature partly inspired the Growth team's work on what we're testing now, but we think the workflow we've built for newcomers is much more cohesive, smoother, and nurturing. We realized today that some of the users getting the Growth features are also seeing GettingStarted at the same time -- this is confusing for them because there are now two things telling them how to get started. I regret that we didn't anticipate this conflict earlier, but that's one of the benefits of starting out with a 2% test -- to notice issues like these before we go broader!
We're trying to think about what to do here -- GettingStarted hasn't been worked on for several years, and we think should be superseded by the Growth features (which do what GettingStarted does and more). But I also want to check if people here have opinions on GettingStarted, if anyone hears about it from newcomers, or thinks it is valuable to keep around in some way. Let me know! MMiller (WMF) (talk) 04:49, 9 June 2021 (UTC)
I encounter that feature whenever I create a sock test account,[FBDB] but I'd guess most Wikipedians don't know about it and wouldn't have a strong opinion if it gets turned off. I agree that the new features you all are working on seem much better, and should supersede the old ones so that there aren't conflicts.
One instance where I know that message pops up and really shouldn't is where someone creates an account to edit a specific page and follows the return link. For instance, H:ITW prompts you to create an account if you don't already have one, and then the software simultaneously tries to take you back to the tutorial and also to get you to go off and edit a random page that needs help. That sort of behavior is bad.
Another tangent while I'm thinking about it—the trickier integration aspect will likely come later, as these features start rolling out to everyone and we start adjusting things like {{Welcome}} to them. Currently, the welcome directs editors to the Teahouse for questions, but if everyone starts having a mentor, we'll want to consider if that should change (either by including both or by switching to the mentor). {{u|Sdkb}}talk05:10, 9 June 2021 (UTC)
Yep, superseding GettingStarted seems like the right move. I've always thought the welcome messages we have are terrible (none of the defaults for IPs are short enough; they look like they're sent automatically by bot even though a human is actually taking the time to send them—worst of both worlds etc.) but yes, a few things like these will need to be discussed after it's rolled out to all accounts. — Bilorv (talk) 05:43, 9 June 2021 (UTC)
I was not even aware of it, I think. Actually, I realise I technically created my account just prior to its existence, even I then had a 5 year hiatus. Anyway. It should certainly be superceded - @MMiller (WMF): I assume that, given the timespan, it's not viable to make it just not appear for those getting the new and improved setup? At 2% it may or may not be worthwhile leaving it on but would be worth removing by the time we're ready to go to 25%. Nosebagbear (talk) 13:01, 9 June 2021 (UTC)
How to write a good article link
I think I brought this up earlier, but I forget... The "How to write a good article link", can we change where it goes? It goes to Help:Introduction to the Manual of Style/1 atm but that's a page about MOS, ie style guide formatting, and not particularly helpful IMO. Three links off the top of my head as possible replacemnets:
As I mentioned above, my problem with it isn't that we link to a beginner MOS page, but rather that we do so as the very first link and under such a broad name. Style adherence just isn't the most important skill to teach, and we're currently overemphasizing it. {{u|Sdkb}}talk13:56, 9 June 2021 (UTC)
I'm sure there's a technical hurdle involved, but if we're going into a live trial this is one of the things that needs changing. The MOS does not help anyone write an article, any more than AP's style guide teaches journalism to someone, or Google's Java style guide teaches someone how to program in Java. ProcrastinatingReader (talk) 14:13, 9 June 2021 (UTC)
Hi all -- I'm glad you're thinking about this link. I just want to say that we can easily change the link to whatever this group decides; it will only take us about a day to turn around the change (and won't affect any of the other wikis; since the help link configuration are wiki-specific). As @Sungodtemple says, in the future admins will be able to make changes like these themselves via mw:Growth/Community configuration. Let me know when you've decided what the link should be! MMiller (WMF) (talk) 17:57, 9 June 2021 (UTC)
Hmm. I'll ping some names involved in FA/GA who might have a more informed idea than I. @Barkeep49, Ealdgyth, Dweller, Buidhe, and Gog the Mild: on Special:Homepage (you might need to enable it first) there's a link shown to newcomers titled "How to write a good article". There's 3 suggestions (bulleted above) to where it could link. Any ideas on which of those, or some other link, might be suitable? I think wherever it goes, it should probably provide some kind of overall breakdown - not overly technical - on how to write a decent article (writing, structure, research)? I personally find those kinds of guides helpful when looking at a blank canvas. ProcrastinatingReader (talk) 18:21, 9 June 2021 (UTC)
Although I guess that's more relevant once the person has learned what a FA is and that they want to write one :) IMO, SG's essay covers similar ground but is more helpful than Dweller's. WP:DEVELOP isn't bad for a truly basic intro. (t · c) buidhe18:35, 9 June 2021 (UTC)
Not sure if this is the best place to post this but I wanted to leave some feedback. I very much like the concept of this but I ran into a couple of pain points:
Clicking on an edit suggestion - and honestly, every link on the dashboard - should open in a new tab - leaving the dashboard open in the original tab.
Is there a way to view who you are mentoring? I couldn't find this.
Is there a way I can ditch my mentor if I don't like them, besides someone else claiming me? Is there a way to get rid of your mentor altogether?
Whenever there are two dots for a two-step process, they should be clickable to navigate between the steps, instead of requiring clicking the "continue" button.
Hello Elli -- thanks for checking out the features and signing up to be a mentor!
Can you say more about why you think it's better for those links to open up new tabs? Also, would this be your preferred behavior on a mobile device as well as on desktop? Tabs on mobile have a different feel, and maybe your preferences would be different there.
There is not yet a way for mentors to see who their mentees are, and this has been a really common request from other wikis since this feature was first deployed. To that end, we're now in the middle of engineering a "mentor dashboard", which will be a special page where mentors can see who their mentees are, some statistics on how those mentees are doing, and other useful tools for mentors. On that project page, there's now even a link to the prototype of the mentor dashboard that you can check out. Please let us know what you think, either here or on the talk page!
We don't have a way for a mentee to switch mentors or disable mentorship. It's not something we've ever heard from newcomers that they want to do, which I hypothesize is because mentorship interactions tend to be initiated by the mentee (i.e. without the dashboard I described above, mentors can't proactively reach out to mentees because they don't know who are theirs). But we can imagine reasons why a mentee would want to switch mentors -- perhaps they want to work with someone they met on an article they were editing, or someone they met at an in-person event. It's something we're considering for the future.
Regarding your idea on dots, I'll pass that along to our team's designer so that I can learn more about what the best practices are considered there.
@MMiller (WMF): thanks for taking my comments into account. For opening in new tabs - maybe it's just me, but I always feel a bit of anxiety that when I click on something like that, I'll be taken away from what I'm currently doing, and it'll be a pain to get back there. Especially with web 2.0-ish style dashboards, which often don't have a different URL for every state they can be in. Opening in a new tab is an easy and painless way to avoid this, so I don't see the reason not to (also, personally, I tend to open lots of tabs whenever I'm doing on-wiki stuff - for example, from my watchlist I always open pages in new tabs, though I can see why that's not the default). Hopefully that helps explain my thoughts? Regarding mobile, I don't know - I still think opening in a new tab would be marginally beneficial, especially with loading times on mobile being what they are. Elli (talk | contribs) 01:35, 22 June 2021 (UTC)
Two things
Hi MMiller,
Two thoughts from the homepage side, apologies if I've missed prior discussion on them
Is there a reason that the homepage stresses the user's email so prominently?
Something on the homepage pointing to the Teahouse, perhaps below the Mentor bubble "Ask for help from more editors?" Nosebagbear (talk) 16:43, 15 June 2021 (UTC)
@Sdkb: I saw that and I concurred, both then and now, with the team's judgement on having the most prominent bit being the mentor, but I'm not so sure why the consideration needs to be either/or. As it is, if the Mentor doesn't rapidly reply, there's nothing on the homepage itself guiding to the next logical port of call. Nosebagbear (talk) 18:35, 15 June 2021 (UTC)
Hi @Nosebagbear -- thanks for continuing to think about this. @Sdkb -- good memory of when we talked about this a bit!
The original reason we made the email an important part of the homepage is because we hypothesize that having a confirmed email address associated with your account makes a newcomer more likely to be retained, on the grounds that they would find out via email that they have a message, or have been reverted, or that they got thanked. The module is there mainly to prompt users with no email to add their email, and then to prompt users with unconfirmed emails to the confirm theirs. What you're seeing is its final state -- in which the user has a confirmed email, and so no more actions are required. We want to let the user dismiss that module once their email is confirmed so that it no longer takes up space on the page. It's in our backlog, and ticketed here with designs: https://phabricator.wikimedia.org/T275155. Does that sound like what you're envisioning?
I like the idea of a Teahouse or Help Desk (most wikis don't have an explicit "Teahouse") as a backup for the mentor -- especially because a mentor can be away from the wikis for days at a time. Maybe it could be part of the mentorship module (as you say) with a less-prominent link that says something like, "You can also try asking your question at the Teahouse." This is a good idea to explore for the future.
How is this module choosing which five (mainspace) articles to show me and what pageviews to count as being "since I edited"? It looks like it could be the five I've most recently edited and their pageviews from the day I first edited them onwards, but that's just a guess. In any case, I'd recommend that it should always exclude ones with the symbol indicating it's too soon for pageviews to be calculated if there are five it can display with pageviews available (it's sometimes not doing that for me). It would probably also be good to list at least the one or two that are most-viewed, and I have ideas of some simple heuristics that could evaluate the most important contributions to articles and display at least one or two of them. (I'm going to take more satisfaction from 10 views on a short article I've added a referenced paragraph to than 10,000 views on a long article I added two links to.) — Bilorv (talk) 16:45, 15 June 2021 (UTC)
Hi @Bilorv -- figuring out how to assemble that list of five articles was harder than we thought it would be! And it sounds like you're picking up on that. When we built this module, our priority was to make sure that newcomers would realize that they have impact -- and so we wanted to show them the most read articles that they contributed to (as opposed to just the most recent).
This is the Phabricator task from when we built the impact module, and the description contains the logic we used:
Definition: "edits" counts any edit, no matter the size, whether it was reverted, or whether it was a revert. We are only counting edits to the article namespace, namespace 0. The talk namespace does not count.
Definition: "pageviews" is the number of pageviews since (inclusive) the first day that the user edited the page. If the user has edited the page multiple times, the first time they edited it is when the counting begins. Pageviews should include the day the user first edited. Although this includes many of the user's own pageviews, we think they will be able to understand that. This means the user will start seeing some data the day after they make an edit. For pages that the user first edited on the same day they are viewing this module, there will be "null" pageviews, since data will not yet be available.
Among the set of 10 most recent pages that the user has edited, choose the 5 pages that have the most pageviews since the user first edited them (or in the last 60 days, if their first edit was more than 60 days ago -- because of constraints of the API). If a user has edited a page multiple times, their most recent edit of that page is what is counted for deciding whether it is part of the 10 most recent pages. For this sort, "null' sorts below 0 pageviews. If the user has edited fewer than 5 pages, show them all.
Display those 5 pages in descending order of pageviews.
Re-reading this logic, if you have been editing lots of pages recently, you shouldn't be seeing any "clock" icons, because you'll have at least five pages that have some pageviews to them. We didn't want to exclude the "clock icon" pages because we wouldn't want newcomers to make their first edit, return to look at their impact module, and then wonder why their edit isn't showing up.
I think, though, that this discussion underscores that different users will want to see different things in their impact module. To that end, we've been planning future work to build out some options in the impact module -- some dropdowns or filters that users could set so that they could, say, always see their most recently edited pages, or see their all-time top most viewed pages, or exclude pages with minor edits, etc. Do you think that would be an improvement? What would you want to be able to do with a more flexible impact module? MMiller (WMF) (talk) 03:27, 22 June 2021 (UTC)
Okay, I think for one it only showed me 3 pageviews and 2 clocks, probably because I was editing a lot of pages I'd never edited before that day (7 of the most recent 10). Rather than looking through 10, you could keep looking from the most recent backwards until you hit 5 with pageviews (or the start of a user's contributions or some fixed cap to stop this from crashing). All of those dropdowns or filters would be good, if all-time most-viewed is computationally/pragmatically feasible. The module is certainly functional and very useful at the moment, so the rest of this is just spitballing.
Clicking "More" and seeing the list expanded by 5 would be nice. It'd only apply to more experienced users, but showing just articles you created would be a very meaningful one. Some metrics to order by that already exist include most-edited pages (XTools), pages with the highest %age authorship by you or pages with at least X% authorship by you (XTools). I might like to "pin" a particular page to always be shown on the list, to "remove" a page from being shown by the feature, or to type in a page manually and have it do the count. I do think the feature would probably be used by people until their edit count hits maybe 3 or 4 digits, when they'd transition to their own "impact" metrics (as people often do on their userpages).
Also, to count the whole day's views when you could have edited at 23:55 is a bit misleading—I've heard that you record hourly pageviews, so using those just for the first day could be a bit more accurate (and make the clock only show in the first hour, not the first day). And I don't know what you're doing if the number of pageviews is literally 0 (is that possible when it includes the editor's pageview?) but maybe keeping it as a clock in that case would be sensible. — Bilorv (talk) 09:54, 22 June 2021 (UTC)
Hi all -- I wanted to give a status update on the test so far. We've been giving the Growth features to 2% of new accounts for the last three weeks (since June 9). I've been keeping an eye on suggested edits and mentor questions coming in, and I haven't noticed any particular problems or damage happening to the wikis through them. I've seen lots of good diffs, including some where users expand articles and add references.
There have been 276 suggested edits completed by 54 distinct users during that time, with a revert rate of about 10%.
There have been 84 mentor questions by 71 distinct users.
All of this seems aligned with the activity levels we see in other wikis. I would like to keep the test going through the week of July 9, to give it a full month (plus a few more days). Then we'll assemble all the statistics, look at them together, and discuss how to proceed. Have any of you encountered issues or concerns, or any reasons not to stay the course here? Thank you! MMiller (WMF) (talk) 23:06, 30 June 2021 (UTC)
@MMiller (WMF): I haven't seen any particular issues that would advise against advancing to the 25% stage. Could you put together a few stats for the general numbers/98% of the other new accounts for things like what their % of reverted edits are? I'm aware that their statistical strength at this stage will be fairly light - I'm looking forward to being able to do some proper compare & contrast at the 25% stage, which will be needed for the ammo to get the support for full rollout etc Nosebagbear (talk) 00:30, 1 July 2021 (UTC)
Thanks, @Nosebagbear. Yes, after we gather the data from next week, my plan is to assemble numbers from the 2% group, multiply them by 50 to predict what we would see at 100%, and also to put them side-by-side with similar metrics for users outside of our test (i.e. revert rate for normal newcomer edits, volume of normal newcomer edits, etc.). I'm looking forward to us all looking through those together and figuring out the next steps. MMiller (WMF) (talk) 19:44, 2 July 2021 (UTC)
Community configuration now available
In several threads above (here, here, and here), this group discussed which help links should be available on the newcomer homepage. There's now a new feature available that will allow volunteers on this wiki to make those changes yourselves without intervention from the Growth team. We're calling it "community configuration", and it's a Special page with a form that allows administrators to configure many parts of the Growth features, like the help links, maintenance templates, and mentorship settings. The idea is that different communities have different preferences for how the Growth features should behave, and we want them to be able to make those adjustments on their own.
Because changes to this configuration will immediately affect the experience of all newcomers, we consider it a pretty powerful feature, and so it's limited to use by administrators and interface administrators. Our thinking is that communities can develop their own processes for debating and deciding on changes to make. Since what the form is doing is changing pages in the MediaWiki namespace, there is an edit history for changes and Talk pages for discussion.
This concept of community configuration naturally has applicability beyond the Growth features, making it a pretty exciting idea (in my opinion). This same approach could be implemented to enable volunteers to adjust the knobs and buttons on other MediaWiki features in the future.
From my perspective I think it has gone alright. There is one thing I feel will be quite important for scaling this to all new users though and that is regulating how many mentees you get. The amount of mentor questions different people want to answer is likely to differ significantly and I think excluding good mentors because they're worried they will get too many questions is bad. I can also see a possibility of mentors withdrawing because the burden gets too large concentrating mentees among fewer editors causing more mentors to leave making a bad situation worse. --Trialpears (talk) 23:29, 30 June 2021 (UTC)
This is not to say that I think I'm getting too many questions now, but rather that I'm concerned what will happen when we get 50 times as many newcomers being assigned mentors. We will certainly not get 50 times as many mentors, perhaps more like 10. Also there will need to be some oversight of the mentor question recent changes. When this system is more mature some mentors will have left the project or otherwise won't handle questions. This problem should be solvable by the community though. --Trialpears (talk) 23:38, 30 June 2021 (UTC)
Trialpears, I've only gotten one question per few days, so I could definitely handle five times the volume. This could definitely work if advertised enough. Sungodtemple (talk) 02:49, 1 July 2021 (UTC)
Oh it definitely could work but it's far from inevitable. A 5x increase in questions would probably be quite comfortable for me, but if its 10x that would probably be too much. If the only way to regulate the amount then is stopping entirely that would be what I would do which wouldn't be optimal for anyone. For it to be just a 5x increase in questions we would need 10x the amount of mentors or in total almost 200. That is a figure I don't see us reaching while maintaining quality. --Trialpears (talk) 08:27, 1 July 2021 (UTC)
Hi @Trialpears @Sungodtemple -- yes, this is also my biggest concern about scaling up: the number of mentors we'll need. When we put the numbers together, that will help us project what might happen. I've been trying to think of ideas for how to deal with the high volume of incoming questions, such as:
Perhaps there are volunteers who want to get a high volume of questions, and would be happy to spend a lot of their wiki time on answering them. I could imagine making it possible for these people to sign up to get five or ten times their share of mentees (like buying multiple raffle tickets).
Perhaps rather than having one big pool with hundreds of mentors, mentors could be grouped by topic (e.g. Sports, History, Science, etc.) And if we encourage newcomers to indicate their topics of interest, they could get assigned mentors from that topic. Those topical groups of mentors might only have a dozen or so people in them, making them easier to manage amongst themselves.
Anyway, those are just ideas I've thought of so far -- I think we'll need to delve into this discussion and get some more ideas going. Please let me know what you think of! MMiller (WMF) (talk) 19:50, 2 July 2021 (UTC)
Signing up for "x number of entries" would make sense to me, so someone can scale up and down their involvement based on other commitments. A fairly strict pruning of the mentor list—like removing someone by default every three months and giving them a talk page message saying they can re-add themselves if still active—might be necessary for the long-term. And I'm hoping it'll happen naturally that a couple of people will be watching the mentor list at any one time and checking that people adding themselves are suitable (though the page is already ECP'd). — Bilorv (talk) 09:04, 6 July 2021 (UTC)
Given it's been mentioned a lot that some way of filtering mentors - primarily due to the issue of not having their answers seen by others as in TH/HD, would be desired.
One logical question to me would be is if it should be a regular userright, or a quasi-userright more akin to AfC, perhaps done at Talk:TH, and an admin can just add them to a fully protected mentor-list if accepted
In terms of criteria (very informally phrased), something like:
6 months tenure
1000 edits
A previous history of assisting new editors, either at a help desk [e.g. TH, HD, VRT] or by a demonstration of direct mentoring
A strong demonstration of "non-biteyness" to new editors A demonstrated commitment to welcoming and avoiding the biting of new editors
Please no more user rights. No admin/other gatekeeping. No formal list of criteria. Just have a normal page, ECP protected, and anyone can sign up to it as they want. ProcSock (talk) 12:27, 23 July 2021 (UTC)
Given that frequently I see Teahouse/Help desk answers that needs to be corrected, but mentor answers won't have any review going on at all, how would you handle the issues that would arise from no restrictions at all at who signs up (other than being ECP)? Nosebagbear (talk) 14:04, 23 July 2021 (UTC)
I wrote about some of my issues with the PERM system here, which is why I have concerns with this idea. As for your specific question, I would prefer to use a wait-and-see approach. If ECP prot proves too light, I would like to see a self-sustaining peer-based system, like anyone in the group being able to vouch for and add another editor, for example. I don't want to jump into a PERM/AfC-like system just due to assumptions. ProcrastinatingReader (talk) 12:06, 30 July 2021 (UTC)
@ProcrastinatingReader: - but how are you going to be ascertain if there is a problem? Mentors don't have anyone reviewing their answers, and by its very nature, those seeing the answers aren't going to know an answer is incorrect to report in the first place nor will they know how to do so. We see incorrect answers in the Teahouse all the time, so we'd expect to see them with Mentors, but in the case of "don't act until evidence" position you need to set out how we'd get it Nosebagbear (talk) 13:47, 30 July 2021 (UTC)
Firstly, because people can report issues to AN. And secondly, since I recognise many newbies won't know about AN, because they're flagged in recent changes and any more experienced editor can go and spotcheck a sample of edits. ProcrastinatingReader (talk) 14:20, 30 July 2021 (UTC)
I think this is necessary because this mentorship will happen outside the public eye unlike the teahouse so it does need to be screened for. I'm pretty agnostic to the where though but prefer a pseudoperm to actual perm. Your criteria seems fine but I would chop #3 to "A pervious history of assisting new editors" as, for instance, I demonstrated that for VRT because of work I had done on IRC. I'd also rephrase #4 to "A demonstrated commitment to welcoming and avoiding the biting of new editors". Best, Barkeep49 (talk) 14:35, 23 July 2021 (UTC)
I'm conflicted here. On one hand there is a probably not-insignificant risk of getting poor mentors with just an EC protected page. On the other hand I feel like a formal perm system is a bit overkill and likely to scare away some good mentors. Perhaps having it EC protected and allow users to add themself but being very clear that the expectation is that they fulfill the criteria above. That as well as allowing anyone to remove folks from the list given that they start a discussion on the subject would probably be sufficient. Probably problems with that approach as well, but I feel a middle ground could work here. --Trialpears (talk) 15:44, 23 July 2021 (UTC)
(edit conflict) But the most key criteria (#3 & #4) require subjective review, so can't just be immediately checked in a minute, and there's little reason to remove someone because no-one will be checking a significant number of mentor answers, so I don't think this method would significantly reduce problematic cases, whilst still limiting the pool of candidates Nosebagbear (talk) 15:57, 23 July 2021 (UTC)
That strikes me as the worst of all worlds in that we're not open but we're not screening either. With a pseduo-perm system we know who can remove someone: admin. With your system it would require an ANI type discussion every time. That is going to cause more hurt feelings if someone needs to be removed or even if the discussion finds that they don't. Best, Barkeep49 (talk) 15:48, 23 July 2021 (UTC)
Although relying on administrators to handle complaints is a practical solution, personally I wish there would be a way to empower the mentors to manage the mentor pool themselves. On a somewhat related note, could a vouch system be used as an alternate route to become a mentor? This might help broaden the pool of potential mentors and provide some upfront vetting, rather than relying on something triggering admin action in the future. isaacl (talk) 01:27, 24 July 2021 (UTC)
I think one advantage of using a pseudoperm system is that it'd discourage hat collecting. We could also make the permission list the same thing as the "wants to be actively receiving mentee questions" list, which would give an out to anyone who ends up not being cut out for mentorship: rather than being removed being seen as a punishment, it'd be more of a thing where people take themselves off the list all the time because they're done trying it out, and someone removing themselves because they were prodded that "hey, you're not really cut out for this" would just blend in and be able to preserve their dignity. {{u|Sdkb}}talk01:37, 24 July 2021 (UTC)
Done. Best, Barkeep49 (talk) 18:07, 4 May 2021 (UTC)
, as part of making the features scalable. Once deployed to your wiki, there will be a community configuration special page that can be used to customize various aspects of the Growth features, including the links displayed in the help panel. You can find a project page about community configuration at MediaWiki.org, and I'm excited to hear what you think about it. You can leave any notes at the talk page. Martin Urbanec (WMF) (talk) 13:36, 10 May 2021 (UTC)
