Hi Growth Team! I wanted to call your attention to a neglected Phabricator task that I think may fall within your realm, task T288161. In short, syntax highlighting is an extremely useful feature that would make things a lot easier for someone trying out wikitext editing for the first time. The en-WP community found clear consensus to turn it on by default for new editors, but more than two years later, it has still not been implemented. Would you be able to help with that?
Talk:Growth/2023
Hello, @Sdkb, I'm sorry that this task has been neglected! I can chat with the Growth team about it. It looks like the Community Tech team is the maintainer of CodeMirror: Developers/Maintainers, so I'm not sure if Growth is best suited for that work. But I see what you are saying about it perhaps being helpful for new editors, and therefore could be something the Growth team could help with. I'll look into this further, catch up on the discussion on the associated task, and follow up. Thanks!
Just a quick note to follow up: I've discussed this with several people at WMF, but I haven't made much progress on finding ownership or solid next steps. I'll follow up with more info soon.
In response to your drafted RfC, I'm wondering if we enable Syntax highlighting for existing accounts by default, do you think we should also provide some sort of GuidedTour explaining the feature and how to disable it? Or do you think that experienced editors who dislike syntax highlighting will know how to disable it?
Thanks for the update, @KStoller-WMF! I would absolutely support having a GuidedTour when the switch is first made. The reason is that, although Syntax highlighting is trivial to turn on and off if you know how, many people don't know how. It's pretty common that even moderately experienced editors come across it and go "woah, how did I not know this exists?" The unintuitive icon is a part of that.
Having a GuidedTour would be exactly what we'd want to ensure that anyone who missed the RfC knows what's going on and we don't get a flood of comments about it. Once the transition recedes into the past, though, I don't think the walkthrough should be maintained. Since at that point, for any new editors, it'll be just how the editor works, and with no expectations from prior experience they'll have no reason to be confused. And reason to turn of syntax highlighting is rare enough that it's not one of the things we should be emphasizing as people try to climb wikitext's (steep) learning curve.
Hi! I wanted to inform @Sdkb and others interested that Community Tech is currently working on upgrading CodeMirror to the latest version. This will make it compatible with RTL languages, greatly improve performance, among other exciting features such as multiple cursors (but no new features will be added without consultation / preferences to turn them off, etc.). We hope to finish the upgrade in 1-2 months. I say this in case you'd rather wait to do a global RfC, as by then we will be able to turn it on for everyone across all wikis which we can't do now. If the new version is as performant as promised, I personally see little reason to not turn it on by default for everyone across all wikis.
I don't know that my team will be able to add a guided tour until after the upgrade, but the Growth team or anyone else should feel free to implement that now if you so desire, as well as proceeding with turning CodeMirror on for everyone on English Wikipedia.
Echoing Sdkb, I do think phab:T174145 should ideally get some attention too.
It looks like T174145 has quite a few differing (strong!) opinions, so it might be hard to find consensus. But I'll discuss with our designer next week to get her opinion. I'm not sure how much engineering time we can invest in all of this work as it lies outside of the Growth team's domain and the Growth team annual plan, but I'll see if we can squeeze in the icon update. 🤞
I’ve just had bad experience with CodeMirror earlier this week: after a power outage, the content of the edit window was lost. (Fortunately I could redo the edit in half a minute, because it wasn’t much, but it could have been worse.) Would CodeMirror have been turned off, the form auto-recovery feature of Firefox would have restored the content – but since CodeMirror seems to neither synchronize the content with the plain <textarea>
nor do any auto-recovery on its own, it didn’t work. I think this should be addressed before thinking about CodeMirror as a tool for normal, day-to-day edits (vs a tool to understand complicated wikitext).
@Tacsipacsi As it happens, my team is currently working on an edit recovery feature! This will be compatible with CodeMirror. I expect us to wrap that project within a month or so, around the same time we hope to complete the CodeMirror 6 upgrade that I mentioned above.
To follow up, I chatted with the Senior Group Design Manager who works with the Growth team about T174145.
She pointed out that it sounds like the underlying issue sounds more like a discoverability issue rather than a major issue with the icon. If we enable the feature by default (and perhaps add a GuidedTour) then that should address the discoverability issue.
That being said, if you truly think an icon update is needed, the Design Systems Team is likely the team that could make that call as they are maintainers of the visual style guide and icon library.
It sounds like there is a path forward once the CodeMirror update is finished and the edit recovery feature is complete.
The Growth team is now focusing on the Community configuration 2.0 project, which I hope can help in situations like this. Community configuration will provide admins with more control over how features are configured on their wiki and if features are enabled or disabled by default. I recognize that doesn't help with this issue in the short term, but I hope it helps remove some of this type of friction in the future.
Thanks for the follow-up! I've watched phab:T259059 and I'll plan to launch the RfC on Meta once it's been completed. Cheers,
@KStoller-WMF - I was looking back at this, but the phabricator tasks are a little hard to parse. When does the WMF expect CodeMirror 6 to be deployed? It would be great to get some of these changes rolled out, like syntax highlighting by default. Thanks!
@Ganesha811 Good question. I don't actually know much about the CodeMirror timeline. I can see that the epic T259059 has many subtasks, and the subtasks are being worked on by MusikAnimal (WMF) and a few others. A considerable number of subtasks have been resolved, but there are also quite a few tasks that haven't been started.
@MusikAnimal (WMF) - does the CodeMirror 6 work have a timeline or release date, or is this work just happening as we can find time to squeeze it in? Thanks!
Are the events when an user drops a mentor and chooses another one logged? Who can access those logs?
Asking because the Mentor changes log seems empty on rowiki, although I changed my mentor recently. However, I can see entries on enwiki. I'm not sure whether this is a bug, or intended.
Strange. We should see changes on the log.
I see changes you performed when I filter by name, but not changes that targeted you.
Who was your previous mentor, and who is the new one?
I changed from Accipiter Gentillis Q. to NGC 54 and back.
@Trizek (WMF) what are your thoughts on this? Should I open a bug?
I think we have a bug, yes. I let you open a ticket, as you offer to do it. :)
Thank you!
Feedback moved here from mastodon, per request of @srishakatux@wikimedia.social. Referring to en.wiki where I'm a decades-old editor.
(a) The page is random for long-time users, is it only looking at recent edits for efficiency? Where is this documented?
(b) There is no talk page and there should be, even if it's just a cross-wiki redirect to this project.
(c) The "Get shortened URL" link is misleading, since it takes the resulting link takes the dereferencer to their impact, not the minter's impact page.
(d) The page appears to be set up to compare 60 day edits with 60 day views as the two main visuals, but (i) these are over very different domains (all namespaces vs article namespace) and not really comparable, (ii) the time-series graphs slightly offset making direct comparison impossible (iii) far better use of space with be bars and lines on a single graph with a consistent timeline and (iv) you end up with situations like my current Impact, where it looks like I don't even view the pages I edit (see screenshots).
(e) It would be great to see my impact against average impact of those in my editor-cohort (i.e. other accounts of a similar age / longevity).
~~~~
Two more things:
(f) the last 60 days have included a NPP Backlog drive (see https://en.wikipedia.org/wiki/Wikipedia:New_pages_patrol/Backlog_drives/October_2023) where I made the top 10 and won two barnstars. Most of that is not in my impact, since it's mainly log actions.
(g) there are many phabricator threads about inconsistencies in counting edits, because there are a large number of intricacies in this area. Any new tool in this area needs to be very clear and open about how edit count is being measured and that other methods exist.
Hello, and thank you for your message
Overall, the project is documented at Growth/Positive reinforcement. The impact module is part of positive reinforcement tools, and, overall, it is part of the entire Growth features. Please don't forget that these features are for newcomers; we provide certain features for experienced users (such as mentorship) but the impact module is not one of them, even if it gains on popularity.
a) What do you mean by random? Only edits made at the main space (Articles) are taken into account. I checked your impact data on a few random days, and the numbers make sense. Again, it is not a feature for experienced users: we decided to highlight what matters: edit to the contents.
b) can you be more precise? Which page are you referring to? If it is Special:Impact, special pages don't have talk pages.
c) I tested the shortener on your impact module (Special:Impact/Stuartyeates) and https://w.wiki/873v sends me to your impact. https://w.wiki/873x goes to mine. However, if you don't add the username to the URL, you have the case you described. I documented it on T350932.
d) i) All impact is shown for articles.
d) ii) You'd like to have a comparison between the edits graph (in bars) and the views graph (the line)?
d) iii) We asked ourselves the question, and we were afraid of overcrowding the graphs with two sets of data at the same place. The distinction between the two graphs wasn't highlighted as an issue during the testing we performed with newcomers.
d) iv) I'm not sure to get it: the graph highlights pages views for everyone, not just the pages you visited.
e) Good idea, I documente it as T350936.
f) As I said, we have only take articles into account. Logged actions would be for a next iteration, for ex-newcomers looking for challenges. You mention barnstars: we have a few ideas around providing rewards to newcomers (and beyond), based on the number of edits.
g) The edit count is based on what we have in the database, i.e. what you have in Special:Contributions. Regarding pages views, we rely on stats.wikimedia.org.
Hope this helps, and thank you again for your feedback! :)
(a) By random I meat two things (i) that it's insane that I have edits on tens of thousands of pages but those pages were only viewed 247 times. If it's only counting views on pages I've editing in the last 60 days, it should say so. and (ii) I've been involved in AfC in the last 60 days, not all of my edits to pages that are currently in main space were in main space when I edited them.
(b) We're spending considerable effort training people to go to the talk page if they have an issue with a wikipedia page. The fact that this wikipedia page doesn't have a talk page undermines that.
(c) Where on https://en.wikipedia.org/wiki/Special:Impact does it give me the hint that I can see someone else's Impact.
(d) (ii) I'd like the red lines in my annotated screenshot to line up, so that features of the two graphs can be directly compared. BTW: is there a reporting delay on the views? if so this needs to be made obvious. [couldn't upload screenshot because that's not working for me right now.]
(d) (iv) I visited the (now) articles when they were in draft: to make the edits but maybe those views are not counted, because only edits/logs and not views are moved from draft: to mainspace?
If may seem that I'm obsessing about AfC, but there are a lot of newbies at AfC...
Hi @Stuartyeates, First of all, thank you for all the feedback! I think several of the issues you pointed out could help us improve the feature further! We've had this feature released on several pilot wikis for over six months, and I think you have provided more feedback here than we've received in those six months of testing on pilot wikis.
(a) We tried to keep the layout and information simple for new account holders, but I can see how we might want to consider further design improvements or add more clarity on how the data is populated. The Your recent activity (last 60 days) header is meant to apply to all the data underneath, including on the "Views on articles you've edited". I take it that isn't very clear though?
(b) That's a great point, I've also been thinking that there is more that we should do to ensure new editors understand and feel comfortable interacting with Talk pages, and furthermore know how and where to leave feedback. There should be an easier path to getting help or leaving feedback from where newcomers actually encounter the Impact module: the newcomer Homepage (Special:Homepage). This task has been sitting unfinished for a long time: T229869, but you can see in the comments I was just thinking about this task earlier this week. Do you think completing that task would help?
(c) That's admittedly a somewhat hidden feature currently. Are you interested in seeing the impact module of other editors? We are currently working on a task to make it easier for people to share their impact module, or potentially even embed their impact module on their user page T341911.
(d) I agree that it would be nice to eventually make these graphs more complex and even interactive. But we wanted to keep it fairly simple to start to get the the new Impact module released and get feedback, and A/B test the changes, before investing considerable time in these data visualizations. I believe there is a ~24 hour reporting delay on view counts after an edit. The data is populated in the same was as https://pageviews.wmcloud.org/pageviews/, and has the same limitation: The Wikimedia pageviews API generally takes a full 24 hours to populate, sometimes longer. In some situations you may see data missing for yesterday's date as well, which will be left blank rather than showing a count of zero views.
As Trizek (WMF) mentions, the Impact module is mainly intended for new editors, and as we don't often get extensive feedback from new account holders, so it's great to hear from you what is unclear or frustrating. And although the Growth team is mainly focused on features to help onboard new editors, I think it would be great to see the Homepage (and the Impact Module) become more usable and customizable for experienced editors.
We'll work on fitting in some of the Phab tasks Trizek (WMF) added and I mentioned, but please feel free to pass along further feedback as well! Perhaps when we add a Feedback link from the newcomer Homepage, we should also add a general Help link in which we can link to a help page with a full breakdown on how the Impact module data is populated. Do you think that's a step in the right direction?
"The Your recent activity (last 60 days) header is meant to apply to all the data underneath, including on the "Views on articles you've edited". " Does it also apply to the "Longest streak above" ? I've not written a quarry query to check, but it seems unlikely that my longest streak out of >15 years is right now.
Something else I've just realised is that "Thanks received" (which is listed) is a symmetric with "Thanks given" (which is not).
As you both pointed out, I'm a long way from your target audience.
I've just had another look, and right now https://en.wikipedia.org/wiki/Special:Impact/Stuartyeates doesn't list any
impact right now: the second graph which appeared earlier has vanished and all of the articles have clock faces next time them.
(b) Help links on talk pages is a pretty standard feature (see Special:Watchlist, Special:Contributions etc.) Adding a such link to Special:Impact could probably help – at least on desktop, because they don’t appear on mobile (T75299 – the task is exactly nine years old today!).
@Stuartyeates, you said:
If may seem that I'm obsessing about AfC, but there are a lot of newbies at AfC...
Growth is actually considering to work on article creation for new editors. We know that more than 20% of newcomers (on average, at all wikis) create an account to create an article. This project is still under definition.
Something else I've just realised is that "Thanks received" (which is listed) is a symmetric with "Thanks given" (which is not).
You suggest to have a module where we would count thanks given? Won't we have a risk of users playing with this count, by thanking every edit they can to have an higher number?
Re: the graph being broken - I can't reproduce it as I see numbers now. Sorry.
@Tacsipacsi, as the feature is not designed for all users but mostly for newcomers, would it be relevant to create this link? I don't think we want experienced users to be frustrated by an experience that is not designed for them. What we would do, if our mandate was going in that direction is 1/ ask experienced users what they'd like to see in the graph, 2/ work on the feature 3/ release it with the link at the right place.
You said:
You suggest to have a module where we would count thanks given? Won't we have a risk of users playing with this count, by thanking every edit they can to have an higher number?
(a) You can't thank your self for your own edits (b) I'm not sure I see excessive thanking of editors impeding the encyclopedia (c) If you create a sockpuppet to do it, this is banned on en.wiki by clause 1 of en:WP:Sockpuppetry ''Creating an illusion of support'' (d) thanking random other editors doesn't seem to be harmful to me. You said:
Re: the graph being broken - I can't reproduce it as I see numbers now. Sorry.
I'm pretty sure it's because all my recent edits at the time were AfC pages and so either in Draft: or mainspace articles too new for their page views to have appeared in the stats engine.
Exactly, the page view stats are including only mainspace article edits, and the clock icon displays if there isn't yet view count data (the Wikimedia pageviews API generally takes a full 24 hours to populate, sometimes longer). If you click on the clock icon you'll see: "Pageviews have not yet been calculated. Check back tomorrow!"
That being said, if that's unclear to you, then I imagine it might be unclear to many new editors, so thanks for the questions / feedback.
@Stuartyeates the Your recent activity (last 60 days) header does not apply to the "Longest streak" data listed above that header. However, there is the "Longest streak" is limited to your last 1,000 edits. We actually just released an update that should add clarity to the info pop-up next to the Longest streak: T338174.
We needed to place some sort of reasonable cap to ensure the query wasn't too slow or costly. Since the feature is mainly intended for newer editors, 1,000 edits seemed reasonable. Would you find that stat interesting if we had a higher cap or it was an "all time" longest streak?
@Tacsipacsi, as the feature is not designed for all users but mostly for newcomers, would it be relevant to create this link? I don't think we want experienced users to be frustrated by an experience that is not designed for them.
I don’t see why it wouldn’t be relevant; it’s just the opposite: help links are mostly for users new to a given feature. I’m pretty sure the help links on the watchlist or contributions pages are predominantly used by newcomers – experienced editors don’t need help on what is a user contributions page or how to use their watchlists.
(a) You can't thank your self for your own edits (b) I'm not sure I see excessive thanking of editors impeding the encyclopedia (c) If you create a sockpuppet to do it, this is banned on en.wiki by clause 1 of en:WP:Sockpuppetry ''Creating an illusion of support'' (d) thanking random other editors doesn't seem to be harmful to me.
Random thanks have two problems:
- Checking who and trying to understand why thanked an edit wastes the thanked user’s time. It’s probably not more than half a minute, but if people start to get dozens of thanks every day, those half minutes accumulate.
- And, more importantly, a thank communicates that the edit is welcome. If a newcomer randomly thanks another newcomer’s edit, the thanked user may think that what they did is good, even if it’s actually a test edit, an edit against policies, or even vandalism.
By the way, I don’t think sockpuppetry would be a problem at all: if you start thanking users with a sockpuppet, you increase the sockpuppet’s counter instead of the main account’s one.
@Tacsipacsi, I see your point regarding the link, but I have a different perspective. An experienced user will see an Help link and think "it is not for me, I know how to edit". They won't think the same with a link to Impact, as they will expect to have useful data showing their involvement on the multiple facets of the wiki.
@Trizek (WMF), yes, of course it will be useful also for editors who are generally experienced but not in this field. Is it a problem? Do you want to build a tool that’s only useful for newcomers, that you actively make useless for experienced editors?
@Tacsipacsi @Trizek (WMF) If experienced editors don't come to understand something, the burden of supporting the new users to understand it will forever remain with the WMF, which doesn't seem such as win.
We designed the Growth features with newcomers and for newcomers. In the case of Special:Impact, the feedback you shared proved that it is not adapted to experienced users. Should we make this module more visible if not adapted? I don't think we should.
Another point to consider besides the lack of relevance of the current design for experienced users is trust and reputation. Making Special:Impact more visible to all users as it is will expose us to negative critiques. You came here with constructive ideas, and we really appreciate that. But we also all know how some people can react to something that is not suiting their needs. These are not a pleasant nor constructive experiences, plus it takes a lot of time to fix things afterwards. This is why we prefer to avoid these conflits by taking the time to properly design a feature that suits the majority of cases for all profiles.
It means that this can change in the future! After all, the newcomers who use Growth features now are the next generation of experienced users: we will have to provide more extended tasks that fit their needs. Your feedback confirms that some experienced users expect this to happen as well. :)
At the moment improving Special:Impact for more experienced users is not in our plans. But we can consider these tasks for the next annual plan. Its definition will start in April. It is quite soon!
This help text is wrong, the count is correct, but they're not all from my most recent 1000 edits.
@Stuartyeates Hmmm, thanks for mentioning this. Indeed it doesn't seem like the Thanks count is capped at a person's most recent 1,000 edits. Looking at the related code it sounds like it "might exclude thanks received a long time ago."
@Tgr (WMF) - sounds like the Growth team should update the info presented to users... any chance you can share more about how that metric is calculated/capped, so I can improve that explanation?
We are using ThanksQueryHelper::getThanksReceivedCount(). It's capped at 1000 thanks, not thanks for 1000 edits. (It's not limited to thanks received for edits, either.)
This should redirect to the login page or something.
T351920 documents it.
I logged into a dormant personal account today and was happy to see the impact of my previously made edits available via the new feature - it is amazing! One feedback - I had difficulty discovering the homepage feature. I had to refer to the docs on MediaWiki.org to figure out how to get to Special: Homepage and take the necessary steps to enable it. It would be a good idea to make the homepage feature easily discoverable for all users.
@Srishti Sethi - Thanks for the feedback about the Homepage!
The Homepage is enabled by default for all newly created accounts, and has been for awhile, but for established accounts I agree that the Homepage is difficult to discover!
I've held off on encouraging advanced editors to enable the Homepage until it boasts a more robust set of features that cater to their needs. Nevertheless, I wonder if the recently introduced Impact module might pique the interest of experienced editors? Are there any other features you'd like to suggest for inclusion on the Homepage?
Do you have any thoughts on how we should make the Homepage more easily discoverable for established accounts?
@Srishti Sethi and @KStoller-WMF, thank you throwing a small stone into the pond, and I am one of the old bones who enjoys the feature time to time: it presents me topics that I have never read before, and everytime I am thrilled to find there are white maps for me but explored by Wikimedians.
Would be nice for a translate bee like me, to be nudged to red-link pages that has article(s) in other language than my local one: it might be handy with features like:
- analysing which area I have worked on translation in the past,
- an indicator for word counts/number of categories
- language pair default to choose from, and
- the matching portal on local wikis.
Cheers,
@Omotecho thanks for the feedback! It's so great to hear that you find the homepage useful! The Growth team has discussed ways to better integrate translation tasks into the Homepage or Suggested edits. We started a project page to start documenting ideas and research, but the project hasn't yet been prioritized: Growth/Translation task for homepage.
I've just added your idea to that project page so we can be sure to consider these ideas once we can move that project forward. Thanks! :)
Do you have any thoughts on how we should make the Homepage more easily discoverable for established accounts?
Couldn’t you just enable Display newcomer homepage for everyone (but keep Default to newcomer homepage from username link in personal tools disabled by default)? I think the extra tab on the user page isn’t too annoying for people who don’t want to use it but easily discoverable for those who do want to give it a try.
If it’s too resource-intensive to compute data for people who will never use it, you could just display the tab for everyone (or display it if another, opt-out preference is enabled), and keep the actual homepage feature opt-in for senior editors. Maybe also replace the current link to preferences on Special:Homepage with a button to enable the homepage without navigating away.
@Tacsipacsi Thanks for the response! I think you not only suggested some good solutions, but also clearly acknowledged the constraints that are top of my mind:
• The Growth team is hesitant to make any major UI / menu changes for experienced editors without community approval. But perhaps the extra tab on the user page is unobtrusive enough that it wouldn't cause frustration for experienced editors? Or perhaps we could add a setting to Community Configuration (Special:EditGrowthConfig) so that admins can make the final decision about how the Homepage is surfaced to experienced editors.
• There is some hesitation to compute the Impact module data for ALL accounts when the homepage might be ignored by most experienced account holders. But I think your idea to simply make the opt in easier when visiting Special:Homepage could be a great compromise!
I'll chat with the Growth team further about these ideas for making the Homepage more discoverable. I'm not sure when we can fit in this work, but if nothing else I will document some initial ideas in Phabricator. Thanks!
I've chatted with some Growth team members about the feedback in this thread today and added this task:
Homepage access for all account holders T350837
It doesn't solve the discoverability issue, but I think it's a step in the right direction. That being said, I need to chat with engineers about the feasibility of requirements, and I'm still unsure if/when we could fit in the work... so I can't make any promises that it will be completed. But feel free to leave feedback about the task in Phabricator or here. Thanks!
@KStoller-WMF, thank you indeed to keep us in the circle. And great to feel the missing link will be bridged someday, to encourage web natives to the world of Wikimedia.
BTW, do you think the "Let's Connect" people are informed of this project? They are sharing group, and resources are explained/trained camped by for the local coordinators. Yes, the very consumers of the HomePage as well as those gentle nudges to walk out of shadow and start your first editing. (: Cheers, --
@OmotechoThanks for the suggestion! At least some of the Let's Connect organizers are aware of Growth features, as they asked me to present at a Let's Connect session earlier this year. I shared a presentation about Newcomer tools for campaign participants.
But I think there is likely more that the Growth team could do to partner with Let's Connect, so that local coordinators know about the newcomer Homepage, Mentorship, Suggested edits, etc. @Trizek (WMF) and I discussed and will consider this approach as we think more about spreading awareness of Growth features.
Thank you picking up my thoughts, and to supplement the climate of newly participated old bones like from Japan; users are a bit over fed with newsletters: The bus terminal is too packed, and ppl don’t find if they are picking the right bus.
It worsened to the extent that AFAIK those repeated mumbles of frustration had even teared the Announcement pages on jawp into two different pages: foreign tray (WMF issued) and domestic tray (any_project/ja issued). Naturally, domestic delivery is more reader friendly as they know their palms, regardless of your wiki life history/months staying.
We translators owe part of it since FY2022, being flooded with energetic inclusiveness endeavors at Foundation teams, aka almost tripled volume of issues as more teams releasing variable letters of news items. Some of them go overdue/shelf rot before they are put onto mother tongues.
A nickel for thoughts. How about putting up a very crisp eye catching message and link to universal news page, an option subscribers can choose from? As Growth team covers very dynamic levels a d structured info/data, I imagine users sometimes give up to read or comprehend feeling the door us too tall/heavy to pull open.
Well, I am not sure if a bulletin board will be placed somewhere, maybe local, maybe cross-Wikimedia/per project, like hotel concierge desk. All the headlines. Or for the time being to get consent, Growth will gain a lot adopting a similar format to Edu-wiki newsletter. In fact, fewer translation on each topic, that readers need to self serve and do some off-wiki machine translation, if the topic triggers them to invest.
FYI, I remember those announcements I scanned at supermarket coupon fountains way back before cellular phones: you stop and scan when you have time. Or old fashioned flyers at bus stops that you tear off a piece of contact info at the bottom, which the poster had made into narrow slips with same data.
Kindly make a workable cross point of infos that will meet the eligible participants to the level of training/meetups/peers. Cheers,
Interesting! I don't think the Growth team has considered a separate universal news page, but I love the idea of having more modules available on the homepage, including some sort of "news" or "events" module. We've discussed this sort of option in the past: T230475, and I know we'll be considering it again in the future as we hope to partner more with the Campaigns team.
I would love to develop more modules for the Homepage (T229865) and then allow editors to customize which modules they see (as every editor has unique interests and tasks that they want surfaced on their homepage).
That being said, we don't have this work planned out yet, and our next project will likely be influenced by the high-level WMF strategic plan, so I'm not sure if this work will be prioritized, but I hope we can fit it in eventually!
I knew I had enabled something in the mentor dashboard to allow newcomers to find me, but Special:MentorDashboard did not have any links to "What is mentor dashboard" or "Where to give feedback" or similar. So I had to basically search for this page across different interwikis anyway. So that's a problem.
But even at the project level itself, I feel like it's badly designed.
Anecdotally, if you look at my talk page and the last three archives on enwiki, I have about 10ish editors asking me a "question" through this feature. To them the dashboard is appearing like I have sent a personalised welcome to them, but unlike Twinkle welcome messages or similar, there's no indicator at all to me (or any bystander) what is going on. It just says "Question from X", and includes whatever the users say, which is often them trying to reply to a non-existent message that nobody knows what it is.
Even once you fix that, I think the dashboard has been applied too broadly. All the users I got assigned just made 1 edit (Asking that question), often not even about editing the encyclopedia, and then never checked again. You're wasting volunteer time by directing 1-edit-accounts to experienced users, because a significant percentage of those accounts, probably even as high as 90-95%, will never check Wikipedia again. There needs to be a minimum activity threshold applied of some sort at minimum.
And lastly, I don't believe this project uses good enough metrics to track if the project itself is designed well. For example, in the August 2023 "preliminary analysis" activitation is defined at the absurdly low state of "one edit", while all the other metrics (retention/productivity/revert rate), it showed no effect at all. I think the threshold for revert rate was still extemely low and noisy, since it included everyone with just 1 edit.
All of this to say, I do not think this experience is very much designed keeping in mind the mentors who are supposed to be assisting via here. And it possibly does not even design keeping the mentees themselves in mind. If I were working on this project, I would at least revisit a lot of core assumptions made here.
As for now, I'm definitely disabling this for myself for the foreseeable future.
(I would have posted this in Talk:Growth/Mentor dashboard but that page seems to be dead.)
Hi @Soni, I want to express my sincere gratitude for your thoughtful and detailed feedback. I truly value the input of experienced users like you, as it plays a crucial role in our ongoing efforts to enhance the Mentorship features provided by the Growth team.
The Mentor Dashboard is a work in progress, and your insights are invaluable in shaping its future. We have several other modules/features in the pipeline, and I see this project as something that we should continue to improve before we can truly measure the success and impact of the feature.
It's interesting that you were receiving so many responses from new editors on your talk page in response to your “Introduction message”. I know this happens occasionally, but it seems like your introduction message seemed to really spark a response. When you registered as a Mentor (Special:EnrollAsMentor), you added an introduction message. That message then displays to your Mentees on their Newcomer homepage. While it might seem unusual to receive messages like “Awesome! Thank you so much" or "How are you?" from new accounts, it presents an opportunity to swiftly engage with budding editors who are navigating the wikis for the first time. A warm and welcoming response can go a long way in making these new account holders feel connected and confident as they take their first (intimidating) steps on wiki.
That being said, your feedback highlights the importance of onboarding mentors effectively after they sign up. We're actively considering ways to enhance this process (T318482), and I think adding a clear link to where Mentors can provide feedback about Mentorship or the Mentor Dashboard is something we should take action on right away (T347361), so thanks for highlighting that need.
Regarding your questions about how we define "activation" and our current broad scope, our approach is rooted in our primary team goals:
- encourage more new account holders to try editing (activation)
- encourage new editors to return to edit again (retention)
Our "Add a link" analysis has a glossary that defines these metrics more precisely.
There is a huge funnel of new accounts created on Wikipedia, and Growth's tools primarily focus on guiding those new account holders through those crucial initial stages after creating an account. While programs like Adopt-a-user cater to relatively new, yet committed Wikipedia editors, our emphasis is more on helping newcomers find their initial footing. Our approach has been guided by various research, including New Editor Experiences, Understanding first day, The Rise and Decline of an Open Collaboration System, and Mentoring in Wikipedia.
Ultimately I think both levels of support are critical to supporting new editors. Effective onboarding and support during the initial stages are vital, but we also acknowledge the value of more personalized mentorship relationships, akin to systems like Adopt-a-user. We're committed to ensuring that Growth's Mentorship tools evolve beyond basic Q & A services and foster meaningful human connections among users with shared interests. Do you have any thoughts on how we could more effectively help connect Mentors and Mentees with shared interests?
We’ll continue to improve and evolve Mentorship and therefore your insights and suggestions are immensely valuable; we'll take them into careful consideration as we continue to refine and expand the Mentor Dashboard. Thank you for your dedication to making Wikipedia a more welcoming and collaborative environment for new editors!
So my first big takeaway, is that it should be clear to either the newcomers that they're interacting on a Talk page/what the talk page is. Or to everyone else what exactly the message they're replying to is (Ideally both, but I understand that you might have other constraints as well).
Other than that, I think it's super important for any onboarding "mentors" to have a clarity on what exactly they're joining up for. I am relatively experienced but also have less time on hand per week lately. It would help me much more to understand "You may get questions from editors with <5 edits" specifically, because then I can adjust my expectations. Like you said about adoption, not every tool will focus on "Newcomers most likely to stick around long term", but that makes it more important for those tools to be clearer about said goals.
I still think it would be significantly better if there was some minimal editing threshold (even 2-3 edits) before mentees were shown a mentor welcome message, just to guarantee them understand the very basics of "This is wikipedia and you can edit it". I think WP:The Wikipedia Adventure or similar were significantly better for brand new newcomers than this, but again, that's for you guys to figure out. Frankly, my last experience in the mentorship sphere was WP:Co-op on enwiki, which ended up nowhere, so I'm not fully up-to-date on things either. I believe adopt-a-user also currently does not work (Pretty sure the last few talk page requests went unanswered. I cant easily check metrics to tell how many editors are currently in adoption) so there's definitely a few things that could be done better about the entire process.
> Do you have any thoughts on how we could more effectively help connect Mentors and Mentees with shared interests?
Not really, simply because it's a hard problem no matter what granularity you attack it from. I've been in this mentorship sphere in some form for a long while, and projects always struggle from a combination of Not enough mentors/Too many editors who will leave wiki/Too much mentor effort-burnout per mentee. Given that you already want to split mentorship into "Committed" versus "brand new" mentees, it'll be an uphill effort to also attach "Put mentees in touch with people with the same interest" as a condition to search through. I'd personally rather focus on trying to fix the core 3 issues of any one project first before trying to add more things it could also do.
So I'd prefer if mentor dashboard was more focused towards those and also try to keep an eye on existing onwiki resources and tools. I think not using talk pages is a problem because it's not clear to anyone (other than mentees+growth team folk) what exactly newcomers can see. Even with your explanations, I am unsure if (say, on enwiki) resources like Teahouse are linked. I've already expressed why I think there needs to be an enwiki landing page for this tool, even if it's a redirect to this wiki. You don't necessarily need complicated solutions for everything, most experienced editors will happily work with a single detailed page + talk page for all "This is what the project is/this is where to give your thoughts" needs.
I still think it would be significantly better if there was some minimal editing threshold (even 2-3 edits) before mentees were shown a mentor welcome message
As a mentor, many of the questions I get are along the lines “How can I start editing?”, “Can I really edit this article?” etc. An editing threshold would make it impossible for newcomers to ask these questions, and depending on how this threshold works (e.g. whether they get a hint that they need to edit before asking), it could lead to test edits in addition to making newcomers not stay.
Even with your explanations, I am unsure if (say, on enwiki) resources like Teahouse are linked.
You can see en:Special:Homepage yourself, regardless of not being a newcomer (it asks you to enable a preference, if I remember correctly, but that’s it). I see no Teahouse link there.
It's true, we aren't linking to Teahouse from enwiki Homepage currently. Currently these are the main resources that display:
- How to write a good article
- How to edit a page
- How to add an image
- How to edit a citation
- How to create a new article
- View more help articles
However, English admins can customize those links via Special:EditGrowthConfig to whatever they think is most helpful to new editors. One of those links could be swapped out for a Teahouse link if that makes sense.
I'll discuss this feedback further with the Growth team, so thanks again for spending the time to leave it and reply to my questions!
The Wikipedia:Welcoming committee—among other things—maintains a set of a set of welcome templates aimed at new users. Many of these templates include a list of helpful links. A proposal to drop the link to en:Help:Your first article from en-wiki welcome templates has been opened; your feedback would be welcome at en:WT:Welcoming committee/Welcome templates#Proposal: drop 'first article' link from all templates. In addition, please see the proposal discussion subtopic at § What evidence can we bring to bear?. Thanks, Mathglot (talk) 20:29, 1 July 2023 (UTC)
Is "no infoboxes politics" still sustained? Right now we have a validation problem at plwiki (discussion) after NS_TEMPLATE had been removed as GEInfoboxTemplates default. However, I realised that some wikis, like french, german or portugal, have no GEInfoboxTemplates set at all. So, my question is: is "no infoboxes" aim cancelled or maybe there is just some new method of determination of "has infobox" scope? thanks in advance for your answer, regards!
The change is only about how the string Biogram infobox
is interpreted: previously it meant pl:Szablon:Biogram infobox, now it means pl:Biogram infobox (i.e. an article). Martin Urbanec (WMF) updated the configuration today, so it should work again.
Hello @Archiwald,
Thank you for the message! The "no articles with infoboxes" rule should still continue to work on all Wikipedias where Add an image is deployed to.
Unfortunately, due to a change of the configuration format (GEInfoboxTemplates
now requires the namespace to be explicit, while previously, NS_TEMPLATE
was presumed), this filtering temporarily stopped working on several projects (where the namespace prefix was not added after the config format changed). To fix this issue, I updated the configuration on those projects (see and other similar edits I made). Special:EditGrowthConfig should now correctly validate at plwiki (and infobox filtering should work). Can you have a look please?
There were also other validation errors in place on plwiki. Several infoboxes changed their name over the time, resulting in Community configuration (Special:EditGrowthConfig) being unable to find them, resulting in a validation error. I fixed those errors manually as part of adding the namespace prefix.
This is caused by GrowthExperiments relying too much on page titles to identify the infoboxes. In the future, the internal page ID should be used, which is stable even with a page changing its name. I filled this improvement in Wikimedia Phabricator as task T340581.
A list of infoboxes is missing on French, Farsi, Portugal and Turkish Wikipedias because of an oversight when deploying the feature to those projects. I filled this issue as task T340585 and it will be fixed within the next few days. On German Wikipedia, the list of infoboxes is missing, because Add an image was not yet deployed to the German Wikipedia. If interested, the list of features by deployment is available as Growth#Deployment_table.
Thank you for bringing this issue to our attention!
Big thanks for your quick and comprehensive answers, and for your fixes too! The group of articles with infoboxes is now avoided. Validation problem is probably gone too (can't try it out since i'm not a sys-op); "page ID solution" seems to be better way in future indeed; once again thank you for your help, cheers
No problem -- glad I could help. To follow up on this: I've added infobox configuration to the Add Image-enabled wikis where it was missing so far (phab:T340585#8971162 has more information).
Really glad to read we're taking positive reinforcement into account. I read that gamifying aspects were being thought of as not-compatible with Wikipedia's seriousness and maybe that could be true but I'd say that in general the features of talk pages and homepage do look rather lighthearted in their essence so maybe a gamifying aspect wouldn't be be too far from what we currently have. Anyway, I wanted to share my excitement about the whole thing in general. Unfortunately, as far as I know, my homewiki (SqWiki) doesn't have those features enabled yet but I'm looking forward to them. (Trizek may remember I've been looking forward for such features for a while now.)
Keep up the good work! :)
Thank you for your feedback and for the encouragement as well. :)
How can we help your wiki getting mentorship being activated?
Oh, we do have mentorship active. We don't have the new features of it yet active (positive reinforcement, etc.).
We are currently testing positive reinforcement at our pilot wikis. If the results are promising, we might consider to deploy them to a few more wikis. I'm keeping yours as a potential candidate! :)
Yes, that's what I meant. Thank you! :)
@Trizek (WMF) and KStoller-WMF: have you considered creating additional content options for the newcomer homepage?
At some point (certain edit count and/or account age) a newcomer doesn't need suggested edits, mentoring or the help panel any longer.
But the homepage could still be useful for former newbies, if it were possible to display different content, e.g. current requests for comment, requests for adminship or other information which enables users to participate at important discussions.
Hello!
We are currently working on annual planning, and a homepage for ex-newcomers is one of the possibilities we consider.
It is competing with other options though, so any plea in favor of it is welcomed!
I would really love that, I see great potential in the homepage, especially for supporting engagement in community discussions and elections.
A possible test any community could start is around the Homepage banner. Using the local message Mediawiki:growth-homepage-banner
and possibly some javascript, it could be possible to display this banner to users who reached a certain number of edits.
Another project would be to have a Notification to encourage experienced users who reach a certain number of edits to apply to mentorship. T271317
Thanks, I've thought about using the banner already but not found a use case yet which fits my goal to increase general engagement in important community discussions. I will give it a try if there are discussions specifically important to (ex-)newbies.
en:Template:Centralized discussion (or its equivalent at my homewiki de:Vorlage:Beteiligen) is a great example of what I imagine for the homepage. Experienced user often transclude such templates to their own user page (like this ) to be aware of new discussions.
But this requires knowing about the existence of such templates. As soon as users are eligible to vote (at dewiki: 2+ months account age & 200+ article edits) it would be great if the template was automatically transcluded to the homepage.
Have you considered to make a test, displaying this template (or a lighter version) to some users though de:Mediawiki:growth-homepage-banner?
Not sure if a banner is well suited for displaying so many options to participate, but I will give it a try soon :)
Keep me posted! I'm curious to know what would be your findings, because it could help us improving the page.
Is it possible to reformat the date and time that are automatically added into the topic title when a user posts a comment from the Help panel to a Village pump page? Currently the time and date formats are very long for the Finnish page, and I would like to keep them to only numbers and not spell out the month, for example.
Hello and thank you for your message.
A message looks like this:
Neuvontapaneelin kautta lähetetty kysymys sivusta China airlinesin lento 140 (2. maaliskuuta 2023 kello 17.20)
The length of the message can be changed at https://translatewiki.net/wiki/MediaWiki:Growthexperiments-help-panel-question-subject-template-with-title/fi.
If you have an account at translatewiki, you can make the change, or I can do on your behalf. For the latter, I'd need a new wording, ideally one decided by your community.
It is not yet possible to change the date format as we use the same as in signatures. I'll check of it is possible to improve this.
Out of curiosity, how things are going with newcomers at Finnish Wikipedia?
Hey, thanks for the reply. Actually, if you look at the history of that translation, you can see that I did the translation almost two years ago. :) I translated the Newcomer homepage into Finnish and I've kept the feature on for myself so I can monitor if there are any changes that need to be translated. I could try to trim the text, but it would be great if the time & date were shorter, too.
Unfortunately I don't really have an answer to your question, though, because I don't do much RC patrolling and I also don't watch the discussion page where the newbie questions are posted. I've been meaning to go through the Edit Growth configuration to see if things need changing for a more helpful newbie experience, but haven't gotten around to doing it. Maybe I'll try to do it sooner rather than later. :)
As you noticed, I didn't checked, sorry! :) To be honest, most requests I got regarding translations are not coming from messages translators. Hence my default answer!
I documented the request regarding the date, the team will discuss it soon.
Thank you for the translations, and whenever you have time to share your feedback (or others' feedback), it will be more than welcomed!
No worries, I could've been clearer with my question. Thanks for the help!