User talk:DannyH (WMF)

Only warning

If you continue to disrupt Wikipedia and deliberately ignore all community input, you will be blocked. Please see WT:Flow to get an idea of the backlash you are creating. Your actions wrt Flow only have a negative impact on Wikipedia. If you want to be active here, you'll have to respect the community input and wishes a lot more than you have done until now. Willful provocation, like the enabling o Flow on more pages on enwiki or the activation of an already widely criticized Echo change, is not acceptable any longer. Fram (talk) 12:00, 5 September 2014 (UTC)[reply]

There are things the community agrees are appropriate occasions for the issuing of "only warning"s, and this isn't one of them. If you're genuinely keen to lead user opinion at the Teahouse, Fram, then you should start by reading up on the Teahouse mentality with regard to how to treat new editors. --Demiurge1000 (talk) 20:42, 5 September 2014 (UTC)[reply]

Hi Fram, this is a deeply inappropriate overreaction and threat. I've left a note on WP:ANI to this effect.--Erik Moeller (WMF) (talk) 22:33, 5 September 2014 (UTC)[reply]

Comment. Software development is really a complex process, specially when it has to deal with UX (user experience) and UI. I haven't followed development of Flow earlier, but it looks like in a very early stage of development. The talk page and other ways of taking user feedback is a good and important part of the development. Not to mention, a talk page is not in any way suitable for discussing development of a software. Generally, lot of face to face (in-person or tele) conversations between different stakeholders is helpful. In the case of Wikipedia and WMF, it is not possible. Nevertheless, only affective way of getting user feedback for a new product/feature is by getting users to use it. A important thing to note that, when users like new changes and features they go along with it without saying much (no appreciation for software engineers :() but those amongst the users who do not like much, would definitely complain. So, ratio of -ve/+ve feedback seen in talk pages is not always an indication of how users are liking them. Danny is a product manager. His task is to communicate between different stakeholders. Banning him is not probably a good idea. In many scenario, product managers have to perform actions based on decision made by not him, but other stakeholders. Also note that, threats like this may actually frustrate software engineers/developers and they might end up developing crappy tools.

It is true that, testing during development of a product would disrupt natural flow of Wikipedia. Nonetheless, they have to test. Keep in mind that, though Wikipedia projects are functioning great with their current software platform, it requires changes to scale with its increasing amount of data and users; besides, ways of accessing and interacting on websites are changing with advancement of many new types of devices and technologies. So I suppose, the community should let WMF software team to test and allow a little disruption so we can benefit from a better new platform. -- nafSadh did say 05:06, 6 September 2014 (UTC)[reply]

Erik, where is your warning to DannyH to no longer implement new Flow pages against the wishes of the community and (in the case of the Teahouse, not so much the WMF-granted Co-Op) the users directly affected? What was the actual purpose of starting that Teahouse test page without any approval and against serious and obvious disproval? Never mind the very poor roll out of the new Echo version for Flow, and all the other problems. Perhaps you should spend more time getting things right at the WMF, and less in keeping the gap between the WMF and the editors as wide as possible. Fram (talk) 08:32, 6 September 2014 (UTC)[reply]

Discussing the essence of Flow

Hello, Danny. As the product manager for Flow, you may be interested in this philosophical exchange of perspectives about the nature of the tool, in particular my reply to Erik. Diego (talk) 09:53, 6 September 2014 (UTC)[reply]

Can I work on flow?

Hi, I have heard about your new project flow which provides UI rich interface for editing discussion and talk pages. I am skilled in various web based programming laguages such as javascript, PHP etc. I was just wondering if you needed any help with the development of flow, as I am eager to help.

Thank you in advance

NetworkOP (talk) 19:51, 27 December 2014 (UTC)[reply]

Talkback

Hello, DannyH (WMF). You have new messages at Northamerica1000's talk page.
Message added 16:35, 23 February 2015 (UTC). You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.[reply]

On my talk page, a user has requested help with errors that have occurred on the Wikipedia talk:WikiProject Breakfast talk page per using Flow. I am unable to fix the matter on the project's talk page. Please see the discussion. Thanks. NORTH AMERICA¹⁰⁰⁰ 16:35, 23 February 2015 (UTC)[reply]

Suggestion

For God's sake please stop referring to Flow pages as "boards." Rightly or wrongly, it reinforces the perception that WMF is trying to convert talk pages into freeform discussion fora. I know you mean well, but words matter. Short Brigade Harvester Boris (talk) 00:11, 7 April 2015 (UTC)[reply]

Core community member?

Hi Danny. I received the notice for the Tech support satisfaction survey on my talk, but my account is less than one year old, so I shouldn't have been on the list based on the criteria listed. I noticed you edited the message, so figured you might be the best person to ask about this. Do you happen to know what happened here? Should I respond to the survey or would you prefer I not because I'm not within the target group? ~ Rob^Talk 05:53, 20 October 2015 (UTC)[reply]

Hi Rob, Looking at your contributions, I'd say that you're definitely qualified for the survey. You haven't been around for long, but you've made a ton of edits, and that's the more important part. Please do respond, if you've got a minute. Thank you for asking about it! DannyH (WMF) (talk) 16:44, 20 October 2015 (UTC)[reply]

Checking in

Hi Danny, just checking in with you and Kaldari as to what the technical progress was on the code for ACTRIAL. Is there a phab task available to follow? The consensus at WT:NPPAFC seems to have settled on option 3 with the blacklist being a viable alternative. Kudpung had pointed out on my talk page that it had been All Quiet on the San Francisco Front, so just checking in. Hope all is well. TonyBallioni (talk) 16:29, 17 July 2017 (UTC)[reply]

Hi TonyBallioni, thanks for checking in. Ryan and I are going to write a post for the NPP page this morning. The current ticket is phab:T170354, and we talked to the analyst on Friday. More coming a little later today. :) -- DannyH (WMF) (talk) 17:03, 17 July 2017 (UTC)[reply]

Thanks, I've added the tracked template to Wikipedia:Autoconfirmed_article_creation_trial#For_article_creation_flow_implementation. If there is another one for the article creation permission/restriction, would you mind adding it to the above section? I'm not overly tech savvy, so the text I placed there was more of a placeholder so the tracked template would have a home on the ACTRIAL page. TonyBallioni (talk) 17:18, 17 July 2017 (UTC)[reply]

@TonyBallioni: See Wikipedia talk:The future of NPP and AfC for update. Kaldari (talk) 18:34, 17 July 2017 (UTC)[reply]

Curation on other projects

There is a question here regarding the Spanish Wiki which you may wish to answer. Kudpung กุดผึ้ง (talk) 09:10, 5 August 2017 (UTC)[reply]

Wikipedia talk:Article alerts#Updates from Wikimania

Hi Danny, it was very nice to meet you at Wikimania. I've started a follow-up discussion to what we've discussed concerning the future of Article Alerts (link above). Please comment there. Headbomb {t · c · p · b} 10:58, 16 August 2017 (UTC)[reply]

ACTRIAL

As I mentioned on the talk page, the Foundation's needs for the data have different goals from those of the volunteer community that creates and maintains en.Wiki. It would be good if the Foundation staff and/or contractors could collaborate with us in a manner that is helpfull and without telling us to finish their paid-for work for them before we can use it. Otherwise there is no need for them to post on the English Wikipedia talk pages at all, and such comments and or illustrations could be best kept at on the WMF project page where they belong. I'm not criticising anyone but IMO there should be a more clearly defined distribution of roles and where the work takes place. Kudpung กุดผึ้ง (talk) 23:49, 28 August 2017 (UTC)[reply]

Kudpung: I can see how you're not the target audience for Morten's offer of datasets. He's in the middle of gathering more preliminary data -- we talked today, and agreed that his immediate priority is figuring out how to measure article quality -- so he doesn't have time right now to run trend lines on the graphs he's posted so far. He'll definitely get back to that later, once we've got an idea of where all the measurements are coming from. I think his offer was good-faith, especially because people have expressed concerns that they won't have access to the data. -- DannyH (WMF) (talk) 00:19, 29 August 2017 (UTC)[reply]

Thank you for the explanation and also that ACTRIAL is not actually your priority or the reason you hired him. Article 'quality' per se is not within the remit of New Page Review. Our work there is for quickly recognising what is apt for the encyclopedia and what is not, how to more easily identify the often subtle signs of what is not, and how to best process all new pages. PR is a triage, it's not a field hospital. I'm writing here to void cluttering the other talk pages, but I'll ping TonyBallioni in case he would like to comment. Kudpung กุดผึ้ง (talk) 00:32, 29 August 2017 (UTC)[reply]

Kudpung, I think there must be a misunderstanding. There are three main areas of inquiry on the ACTRIAL research page: the impact on new accounts, the impact on the quality assurance process (NPP), and the impact on content quality as a whole. We want to know if making this change results in fewer bad articles and more good ones. I know that you've seen the three areas, because you commented on all the hypotheses here: meta:Research_talk:Autoconfirmed_article_creation_trial#Comments_from_Kudpung. Figuring out how to measure content quality is difficult; it'll take Morten a couple days to get his head around it. Does that make anything clearer? -- DannyH (WMF) (talk) 00:39, 29 August 2017 (UTC)[reply]

(edit conflict)I think article quality is an important thing to measure, and I appreciate the resources being spent on that. I haven't been following the work on meta exceptionally closely. I liked the initial questions, but I should probably look again. I'll be busy for most of the day tomorrow so will probably look Wednesday. As I've said publicly plenty of times: I appreciate the work the Foundation is putting in here and always try to give the benefit of the doubt. I also don't have Kudpung's background here, and I understand why he is suspicious. I'm in general agreement with Kudpung's broader point that this is a community effort that the Foundation is working with us to implement, not vice versa. Hopefully the trial will go well and it'll be a great building block for future collaboration between the community and the WMF. TonyBallioni (talk) 00:47, 29 August 2017 (UTC)[reply]

(edit conflict)::::I don't think there is a misunderstanding. We already know that there is going to be an impact on new accounts. We already know that less than 0.1% of accounts have ever edited. We already know that a significant number of accounts are deliberately created for the sole purpose of making mischief. We do not believe for a moment that ACTRIAL will increase the number of good articles - that would be simple wishful thinking and is not a serious expectation. But these are the empirical conclusions that a) the Foundation does not wish to entertain, probably because it has no practical experience in these areas, and b) are difficult to explain anyway with pure math. That said, ACTRIAL is designed as a measure to protect Wikipedia's content, integrity, and reputation (which is rapidly deterorating) for quality. 'Quality' per se however, is no within the mandate of New Page Review, and at the end of the day, that's what it all about - and getting he Foundation to produce the software enhancements that are needed to do it efficiently. Kudpung กุดผึ้ง (talk) 00:57, 29 August 2017 (UTC)[reply]

Please refrain

Sorry to say this Danny, but WHY are you butting in here? You should either have helped shape the RfC, or have left a single post with a link to a separate statement of the foundation and just left it at that. You know you are not going to convince Fram, and every word you utter is just another stick for him to fight with and the community will just cheer him on. I know you intend well, but when people don't want to hear you/foundation, this will only result in more trouble (don't feed the troll-effects). Please just let the community run with .. well whatever this total clusterfuck is. —TheDJ (talk • contribs) 14:56, 13 December 2017 (UTC)[reply]

Hi TheDJ, I've been part of the conversation about short descriptions for a few months now. We're going to be building the feature that we're talking about, and I think that means we should be part of the consensus decisions. I was originally going to be part of the RfC creation -- Alsee had asked me if I would, and I was just waiting for him to get it started so I could add to it. I'm not actually seeing this as a t.cf. right now, I think we're a lot closer to a decent compromise than we were a month ago. Pretty much everybody agrees that we want to do a magic word override, and that Wikipedia editors should make the decisions about how to use it. The only real sticking point at the moment is about whether we should have a blank description by default, and Fram suggested a potential compromise there -- a transitional period where WP fills in a good chunk of the descriptions before we make a big change. I need to talk to a few people internally, and then I'll have more to say about that.

But I appreciate you reaching out, and I know that you give good advice. What do you think about that compromise as a direction? -- DannyH (WMF) (talk) 15:21, 13 December 2017 (UTC)[reply]

I think that by continuing to shift the goals posts every time someone asks, and by seeking compromise in response, we are maximising the period of antagonism towards the foundation and developers, causing the most harm possible between them and this community and allowing people to reinforce their story of WMF as the bad guy while no one notices the purpose nor the results of the compromise. —TheDJ (talk • contribs) 16:24, 13 December 2017 (UTC)[reply]

I think the moving goalpost you're talking about is disambiguation phrases, and I've been thinking about that; I think people have been making good points. That's the kind of thing that gets worked out through discussion. Big picture, there's a familiar outcome that I'm trying to avoid -- the Foundation stays out of a discussion/RfC about a Foundation-built feature, the RfC comes to a conclusion that the Foundation team feels very strongly about (in this case, that would be blanking all descriptions now and starting over), and then the question is why isn't the Foundation abiding by this RfC? -- DannyH (WMF) (talk) 17:00, 13 December 2017 (UTC)[reply]

TheDJ: Thanks very much for your thoughts about moving the goalposts; that helped me to rethink our approach. I just posted a new proposal on Wikipedia:Village pump (proposals)#WMF two-stage proposal for Wikipedia-hosted descriptions. I'm interested in knowing what you think. -- DannyH (WMF) (talk) 00:35, 22 December 2017 (UTC)[reply]

Your other account

I recently pinged this account on village pump, and I was wondering where is your normal/non WMF a/c? I also didnt know you are founder of muppetwiki, neither that you have a photo of yourself. You remind me of Luke Wilson for some unknown reason. —usernamekiran(talk) 18:26, 19 December 2017 (UTC)[reply]

Hi Usernamekiran, my volunteer account is User:Toughpigs. I thought that was on my user page, I'm really glad that you pointed out that it's not! I'll fix that. :) -- DannyH (WMF) (talk) 19:18, 19 December 2017 (UTC)[reply]

List of previous creators

Can you please ping/notify the correct folks at WMF to chime in at Wikipedia:Village pump (proposals)#List of previous creators of an article.Regards:)Winged Blades^Godric 11:09, 22 December 2017 (UTC)[reply]

Hi Godric: As far as I can tell, that's a feature request, and not something that currently exists. Am I correct? I think the most appropriate thing to do is propose it on the Community Wishlist Survey. The annual survey just ended, unfortunately, but the next one will start in mid-November 2018. -- DannyH (WMF) (talk) 19:13, 22 December 2017 (UTC)[reply]

Kind of sad, that we are practically limited to 10 feature requests/improvements over an entire year, out of which there is no guarantee that all may eventually happen.Winged Blades^Godric 07:59, 23 December 2017 (UTC)[reply]

Yeah, it's hard -- people have lots of requests. There were more than 200 proposals this year, and the one you're pinging me about wasn't even on the list. :) I hope you can add a proposal in next year's survey. -- DannyH (WMF) (talk) 22:36, 23 December 2017 (UTC)[reply]

A bowl of strawberries for you!

Always a pleasure to see you take on community discussions respectfully and constructively. Thanks! effeietsanders 19:37, 2 January 2018 (UTC)[reply]

Oh, thank you, effeiets! I appreciate it. :) -- DannyH (WMF) (talk) 19:38, 2 January 2018 (UTC)[reply]

Chime in

Is there any problems (legal, technical et al) from WMF's side to not extend storing IP data etc. at the CU logs beyond the current 90 days.You may wish to chime in at User talk:Kudpung/PE - things to do#CU time-span.Regards:)Winged Blades^Godric 05:57, 14 January 2018 (UTC)[reply]

Page Curation updates long overdue.

Any chance that you could have someone look into the massive list of requested improvement to the page curation tools at Wikipedia:Page_Curation/Suggested_improvements? Either that, or tell us that it is never going to happen so we can tell people that they are going to be more successful pissing into the wind. In all seriousness though, the page curation tools might be useful, but they are far from perfect and we have no way to improve them ourselves. If they had been written as a user script, this wouldn't be an issue, but clearly some very shortsighted people over in your neck of the woods decided that we couldn't be trusted with the levers and gears of our own tool set. You had one job, but apparently it is too much for y'all, so either rewrite them as a user script so that we can update and improve them ourselves, or if the tools have indeed been abandoned, please release the code to us so that we can build our own user script version that we will actually have the capacity to update as times and needs change.

If you have noticed a lack of respect in my words, you aren't mistaken, I've been helping to keep New Page Patrol running for a few months now, and I have to wonder what the hell you guys are doing all day? Why would you write a program for NPP to use and then drop it from active development? You team's job is "supporting the most active Wikimedia contributors with the features and fixes that they need" and I am here to inform you that You Are Failing. Wikipedia only keeps running because we develop our own tools to keep our efficiency up in the face of a never ending onslaught of adverts and promotional garbage. Maybe next time when developing something intended to help us, you could actually contact us and ask a few questions? Any numbskull would have said that it should have been written as a script so that it could be updated rather than being entirely backend. — Insertcleverphrasehere ^{(or here)} 03:51, 5 February 2018 (UTC)[reply]

Hi Insertcleverphrasehere, the Community Tech team runs a Community Wishlist Survey every year to find out what the most active Wikimedia contributors want, and the top wishes get guaranteed development time from a WMF development team. We held the third Wishlist Survey in November and December, and you can see the results here. This year, the folks who care about maps voted for Kartographer improvements, and the people who work on editathon programs voted for more development of the Programs and Events Dashboard; they're both going to get some serious work from WMF dev teams. It's a good system that works, and nobody has to be disrespectful to anyone. The next one will start in November. -- DannyH (WMF) (talk) 04:20, 5 February 2018 (UTC)[reply]

Sorry but no. You don't get to pull a "vote for it if you want it". The WMF made a program for us and refuse to update it as required. As a result your page curation tools are becoming more and more out of date. I refuse to vote for basic improvements to the page curation tools in the 'wishlist'. These aren't wishes, they are basic and fundamental tools that are needed to maintain the wiki. Do your job and maintain what you built or give us the code so that we can build our own version that we can maintain ourselves. — Insertcleverphrasehere ^{(or here)} 09:18, 5 February 2018 (UTC)[reply]

Okay, I understand. If you change your mind, the next survey's in November. -- DannyH (WMF) (talk) 15:14, 5 February 2018 (UTC)[reply]

What about the code? Can you please provide us with a link to the code for the Page Curation tools (under a suitable free licence) so that we can make our own community maintainable version of the tools? — Insertcleverphrasehere ^{(or here)} 03:14, 12 February 2018 (UTC)[reply]

Insertcleverphrasehere, here are links to the extension's page on Github and Phabricator. I can help to connect you with people who could answer questions about the code, if you need it. -- DannyH (WMF) (talk) 22:37, 12 February 2018 (UTC)[reply]

I have no idea if I will find anyone to volunteer to do this work, but it is good to have it at the very least should it arise. Why is the maintenance of essential tools like this not a priority for the WMF? — Insertcleverphrasehere ^{(or here)} 09:28, 14 February 2018 (UTC)[reply]

Insertcleverphrasehere: The tricky thing is that everybody thinks that the tools they use are essential; the even more tricky thing is that everybody is right. There are a lot of important tools. The Foundation set up the Community Tech team, and the Community Wishlist Survey, so that active people from all projects could prioritize which of the many important tools should have dedicated resources to fix them. We openly encourage people to canvass during the survey, because we're measuring the enthusiasm that people have for the tools that they care about. If only ten people care enough about a specific tool, then those ten people need to make the case to other contributors that support for that tool is essential. If those ten people can't convince other contributors that their tool is important, then maybe it's not actually that important. I agree with you that PageCuration is important, so I'm encouraging you to add it to the survey next year.

In 2016, there was a proposal for "New User Landing Page - Article Creation Workflow", which got 63 votes, and reached #14 on the survey. Community Tech's mandate is to work on the top 10, but the team did put in a lot of work with New Page Patrollers in 2017, leading to the ACTRIAL experiment, which we are currently running and evaluating as a research project. Two developers from Community Tech -- Kaldari and MusikAnimal -- also did some work in their spare time to fix some PageCuration bugs. Unfortunately, that wasn't a great experience for them or for the team, because we had to spend a good deal of our allotted time responding to people who were informing us that We Were Failing.

If the PageCuration proposal gets into the top 10 in the next Wishlist Survey, then the Community Tech team will be happy to investigate, and make substantial fixes. That's the team's job, it's not optional. The team does have some discretionary time that they can spend on projects that aren't in the top 10, but that's at the team's discretion, and obviously there are many possible projects they could give a little time to. The best way to approach that is to engage in respectful and productive conversations with members of the team. -- DannyH (WMF) (talk) 19:42, 14 February 2018 (UTC)[reply]

If you wish to deserve respect, maybe, you need to spend more time into avoiding acute dumbassery like developing a system, which you folks clearly don't bother about and which can't be maintained by the volunteers, without going through a lot of hoops.As, ICPH said, I wonder how folks can be so shortsighted. ~ Winged Blades^Godric 07:09, 7 April 2018 (UTC)[reply]

Hi Winged Blades of Godric, I agree with you that we need to avoid that kind of outcome. Unfortunately, some hoops are necessary, because there are a lot of possible projects and a limited amount of people and time to work on them. But I know that it's frustrating to feel like you're going through the same hoop over and over. -- DannyH (WMF) (talk) 20:51, 9 April 2018 (UTC)[reply]

One of the very reasons we pushed hard for ACTRIAL is because the folks at the WMF refuse to upgrade the tools they made to the standards we require now. There is one tool: Page Curation/New Pages feed. One tool - one project, supposed to be being used by the reviewers coping with an influx of anything up to 1,000 new pages per day and not only is Page Curation/New Pages feed still incomplete after 6 years, it's now full of bugs. There is only one hoop, and that's the person responsible for software development. Anyone in charge of WMF policy would know how important these things are. Being told that the WMF doesn't have money or resources is the kind of nonsense we were fed by a junior contractor until his bosses told us none it was true. This isn't something for an Xmas stocking filler - Page Curation is big stuff, it's our only firewall against unwanted content. Respect is required for the 1000s of volunteers who provide the basis for the WMF's salaries - imagine a world where all the reviewers suddenly downed tools... Kudpung กุดผึ้ง (talk) 07:34, 13 April 2018 (UTC)[reply]

Kudpung: You and I are currently having a discussion on the same topic on the Wikimedia Foundation Annual Plan/2018-2019/Draft talk page, so I'll keep this brief. I don't know the situation that you're referring to with the junior contractor, so I'm not sure how to comment on that. But, big picture -- the Community Wishlist Survey is a place where you can demonstrate to the Foundation and the world at large that this is an urgent need, and there'll be another survey coming up in November. It's a direct line to a Foundation product team, and I encourage you to participate in the survey this year. -- DannyH (WMF) (talk) 15:54, 13 April 2018 (UTC)[reply]

Barnstar

		The Original Barnstar
		For bringing ACPERM live. --Dlohcierekim (talk) 01:59, 27 April 2018 (UTC)[reply]

Short description everywhere?

I got head bitten off for reverting an edit that removed a short description. Was I wrong to revert this edit? I don't expect you to interject yourself in the dispute with the other editor but I would like a definitive answer on whether we should or should not be adding short descriptions to every page.

Please respond over here.---Coffeeandcrumbs 08:30, 31 May 2018 (UTC)[reply]

Hi Coffeeandcrumbs: I think the wiki is going through some growing pains with the short descriptions; lots of people aren't aware of them, and the best practices are still being thought through. I think it's a good idea in general for you to add short descriptions, but as Pbsouthwood said about this specific article, it's okay to let this one go if it's annoying someone and the Wikidata description is the same. -- DannyH (WMF) (talk) 13:54, 31 May 2018 (UTC)[reply]

I have just taken the page of my watchlist. Questions: where are we on this project? Stage 1 or Stage 2? I was under the impression we were in Stage 2.---Coffeeandcrumbs 23:19, 31 May 2018 (UTC)[reply]

We're in Stage 1. The override works, and people are populating the descriptions. Once there's ~2 million good-quality descriptions, then we'll switch off the Wikidata fallback, and just use the local descriptions. That'll be stage 2. -- DannyH (WMF) (talk) 23:37, 31 May 2018 (UTC)[reply]

Using short descriptions in Wikipedia

{{Annotated link}} is up and running. This template can be used to automatically annotate a link in a list using the associated short description, making short descriptions actually useful in Wikipedia. This can be used in outline and index lists, and in shorter lists in articles which will be automatically populated with annotations using the associated short descriptions, or any other place where disambiguation is needed. These will remain up to date when the short description is edited. · · · Peter (Southwood) ^(talk): 12:41, 13 September 2018 (UTC)[reply]

Hi Pbsouthwood, thanks for telling me about it. I'm not sure I understand where that annotation is visible -- I'm looking at Outline of underwater diving#Diving activity, by type where there are three annotated links, but I don't see any difference when I look at the page. What does the new template do? -- DannyH (WMF) (talk) 17:51, 13 September 2018 (UTC)[reply]

It transcludes the short description as an annotaton to the link. Previously the link had to be manually annotated.

The annotation remains up to date as the page description on the target page changes.

As an example, if a page has a ==See also== section, and the wikilinks to the related pages are enclosed in {{Annotated link}}, the links will be followed by – "the current version of the short description from the linked page".

Where it will save a lot of time is in Wikipedia:Indexes and Wikipedia:Outlines. Both of these article types relied on manual annotation, which is labour intensive, and could go out of date.

Adding short descriptions as annotations to category lists would also be useful, as it would be much easier to see why an article is in a category, and spot the ones that should not be in the category if you have more than just the title to judge by, but I have no idea of how this could be done. · · · Peter (Southwood) ^(talk): 03:22, 14 September 2018 (UTC)[reply]

Oh, I see. That's very interesting, thank you for telling me about it. -- DannyH (WMF) (talk) 19:39, 14 September 2018 (UTC)[reply]

Editor retention

Hello DannyH (WMF), I was one of those "most active Wikimedia contributors" that you are supporting "with the features and fixes that they need". I have lost faith the WMF's ability and willingness to support NPP. I have relinquished my new page reviewer right. My decision to quit NPP is a direct consequence of your contributions at meta:Community Wishlist Survey 2019/Miscellaneous/Page Curation and New Pages Feed improvements. I thought you should know that. With regret, Vexations (talk) 21:37, 3 November 2018 (UTC)[reply]

Hi Vexations, I'm sorry to hear that I upset you so much; that certainly wasn't my intention. I'm afraid that I don't understand what I said in that discussion that caused you distress -- for me, it looks like an amicable discussion about expectations. We want folks to know that there might be a few of those 17 tickets that we won't be able to do during this year, but if the proposal gets into the top 10, then I'm sure the great majority of them will be done, and Page Curation will get significant improvements. I'm not sure why that's upsetting. If you'd like to tell me more about it, then I'm very interested to know. -- DannyH (WMF) (talk) 21:55, 3 November 2018 (UTC)[reply]

DannyH (WMF), And if we don’t get in the top ten? Do we just get hung out to dry forever? NPP isn’t sexy or popular (sewage treatment usually isn’t). But it is a core process of the wiki that needs to continue running smoothly. When the WMF treats us like we don’t matter you can expect more people walking away from the job. — Insertcleverphrasehere ^{(or here)} 22:13, 3 November 2018 (UTC)[reply]

Hi Insertcleverphrasehere: You're on the right track with the Survey; you posted a good proposal, and now you've got some time to prepare for the voting phase, which is Nov 16th-30th. Last year, the #1 proposal got 154 votes, and #10 got 91 votes, so that's the area you need to aim for. You don't need to convince me that NPP is important; you need to convince other editors. You're encouraged to canvass, advertise and promote any way that you want, to get people to vote for your proposal. I agree that NPP matters, and I expect your proposal will do very well. -- DannyH (WMF) (talk) 23:04, 3 November 2018 (UTC)[reply]

With the persistent resistance for years to do anything about it, the WMF has inferred many times that they do not agree on the importance of better control over new pages . As you've been told many times before, your wishlist is not the place for begging for urgently needed improvements to core software which is used by Wikipedia's only process for preventing the ingress of unwanted pages into the encyclopedia. This demands the creation of a team of devs to work full time until it's done. Shortages of personpower or funds are not acceptable as excuses - they would be blatant untruths.

More than 90% of the patrolling is being done by less than 10% of the reviewers, and you've just lost not only one of the most prolific, but caused a total retirement from Wikipedia. If this NPP entry at the wishlist fails, as Insertcleverphrasehere states above, When the WMF treats us like we don’t matter you can expect more people walking away from the job,, it's happening already - just look at the rising graph pf the backlog, what will you do when no one is left to patrol new pages? Until then, the volunteer workforce will continue to lay down their tools. Kudpung กุดผึ้ง (talk) 00:28, 4 November 2018 (UTC)[reply]

Well, try to stick around until the voting starts, at least. It would be a shame to miss the top 10 because you all decided to retire. -- DannyH (WMF) (talk) 00:59, 4 November 2018 (UTC)[reply]

Or because you've driven them away, don't you mean? Kudpung กุดผึ้ง (talk) 02:57, 4 November 2018 (UTC)[reply]

DannyH (WMF) to be perfectly honest, I don't think we have asked for too much in the wishlist and should be able to be completed by competent coders in a reasonably short timeframe. Repeating that we 'might have' asked for too much and that you 'might' not be able to deliver is a pretty big problem, especially if it ends up dissuading people from voting on the proposal. Moreover suggesting that even if we get in the top 10 that you might not actually do the stuff, even after putting us off for so long and forcing us to come to the wishlist, is concerning for reviewers to be reading and certainly indicates that you don't really think that NPP is important. — Insertcleverphrasehere ^{(or here)} 09:53, 4 November 2018 (UTC)[reply]

Apparently my efforts to manage expectations have caused this group a lot of worry and distress. I'll try to be more clear, because this really is a very positive message, and my intention is for you to feel excited, not stressed out.

I'm talking about "managing expectations" because there have been problems in the past with the Community Tech team allowing huge "improve X system" proposals into the voting phase, doing a lot of work on the wish, and having people still unhappy because we aren't putting an entire team on that wish for an indefinite period of time. The best example is the Maps wish from last year's survey.

The Maps wish was voted #1 on the survey, and we worked on a Map improvements project that took about five months for the Collaboration team (now the Growth team). We delivered significant progress that made it possible for Wikipedia editors to add tens of thousands of maps to wiki articles, in every language.

However, the folks who care about maps are still expecting us to create a full-time Maps team for the next two years, and that's the proposal that they posted this year. As you can see in the discussion on that page, I'm currently having the same kind of "managing expectations" conversation that I'm having with you. We're happy to do more work on maps tools, but we can't promise to work on a huge list of tickets that we haven't evaluated and estimated yet. For that proposal, I've asked them to take out the line about having a team work for 1-2 years on the project, and to scale down their list of requests to the things that they really need this year.

That's what we do for every proposal in the Community Wishlist Survey -- make sure that the proposals are feasible and appropriately scaled before they go to the voting phase. There's an archive of proposals that have been rejected for various reasons: the proposal asks for a social or policy change rather than a technical one, it would open up security or legal risks, or it requires more work than the team can provide in a year. It's important for us that we don't allow people to vote on wishes that we know we can't work on.

Now, to be extra clear -- the NPP proposal is in no danger of being rejected and archived. That's why I posted earlier this week, to reassure you that the current proposal is fine, and it's definitely going to be included in the voting phase. I'm pointing out the archive right now just to give you more context about how the process works.

The voting phase ends at the end of November, and in December/January, the team will investigate all of the tickets involved in the top 10 wishes, and estimate how long they'll take. At this stage, it's possible that the team discovers that the wish as written involves more work than the team can provide in a year. Sometimes a wish needs to be scaled back, or an alternate solution can be found. This is a normal part of the process that applies to every wish. We don't do that estimation in advance because there are probably going to be 300+ wishes posted in two weeks; all we can give them right now is a quick look to see if a wish is obviously going to be unfeasible.

So -- with 17 (now 18) tickets listed in your proposal, it is possible that we'll discover during that estimation process that a small number of them are unfeasible for the team. I know that you all have been thinking and working on these tickets for a long time, and you have a good idea of how much work it might be, but we haven't done that yet, and the team may find a couple of problems that you don't know about. If that's the case, then the team will talk to the NPP group, explain any problems that have come up, and talk to you about possible alternative solutions. That is the only thing that I'm saying in this "managing expectations" message -- that the exact list of 18 tickets as written may have a surprise or two, and you should be aware of that possibility.

If your proposal is voted into the top 10, it is a guarantee that Page Curation will get a significant amount of work from the Community Tech team. I expect that the great majority of tickets listed will get done. This is good news for your group. You're doing the correct thing that will lead you to getting what you want.

I understand that there's a long history of the Foundation not providing you with the support that you needed to do your work, and that you don't trust the people who work at the Foundation to follow through on promises. I don't expect you to suddenly regain trust for me or the Foundation; that's not how trust works. All I can do right now is to act in a trustworthy way. I believe that's what I'm doing in this conversation.

Now, it's true that if your proposal doesn't get the required number of votes to get into the top 10, then the Community Tech team won't work on Page Curation, and you'll have to try again next year. The same is true for every other person participating in the Wishlist Survey. I know that you feel that NPP is more important than Maps and event organizer tools and all of the other projects that the Community Tech team is working on. The most effective way for you to get that message across is to get people to vote for your proposal. I'm happy to keep talking with you about this, but I think your time would be better spent in encouraging editors to vote. -- DannyH (WMF) (talk) 20:06, 4 November 2018 (UTC)[reply]

Hi DannyH (WMF),

I had prepared a lengthy reply that was going to demonstrate that in steering requests for maintenance of the NPP tools to the wish list, you had acted in bad faith. I went over (literally) everything you had ever said on en-wiki, and gathered all the evidence I needed. Then I stumbled upon something you said in September 2014 "It feels like everything that I say will be picked apart, weaponized and then posted in several places as proof that I'm incompetent. That means that I have to watch everything that I say, and say as little as possible". That made me incredibly sad, and I can't bring myself to do what I had planned to do, which was pretty much just that.

You have been on the receiving end of some very unpleasant exchanges. That was awful. I don't know if you care, and it clearly wasn't enough, but I did make a point of saying that some of the language directed at you and your team is absolutely unacceptable. [1] And I want to reiterate that here; it has to stop.

I don't see the current situation working. You have said that you think the wish list works. I don't want to speak for the NNP crowd, but with the exception of WMF staff, I have never met anyone who thinks that it works. NPP has a list of almost a 60 open issues that need addressing. We can log them in phabricator, but to get them prioritized, it seems you still want us to convince a group of voters who know nothing about NPP that what we do is more important than anything else, and they should vote for our proposals. You even encouraged us to canvass.[2] Most Wikipedians find canvassing abhorrent. It is antithetical to our values. You could have anticipated that we would be unable to get the numbers required to pass a proposal. We can't get people to support a proposal that doesn't affect them.

Out of 650 reviewers, only about 150 reviewed something last month, and only half of them reviewed more than 10 articles in a month. 80% of the work last month was done by just 20 reviewers. And yet, in a heroic effort, a small group has managed to reduce the backlog from 22,000 in May 2017 to a few hundred in July of this year. That is less than what enters the queue every single day, so we had effectively eliminated the backlog. Do you still believe that NPP is "a system that we think is fundamentally unsustainable"? [3] I don't recall that you have ever acknowledged that we demonstrated that it does work.

We can't submit our proposals in bulk, but we also couldn't submit them individually, because you have imposed a limit of three proposals per account. We'd need more than 20 editors to each submit three proposals. Or we'd have to whittle down our list to three issues. In all scenarios, those 60 open issues do not get addressed. With odds like that, why would anyone bother to even report an issue anymore? Try next year? It would take 20 years to get through our list. This set-up virtually guarantees that we can never get what we want or need. You may not have meant to do that, but it has that effect.

I don't know if it is possible to move past this. I hope so. I'd like to suggest that a false dichotomy of different interests of NPP and the WMF contributes to the unnecessarily adversarial climate. In 2017 Kaldari wrote: "the WMF and New Page Reviewers have different priorities. New Page Reviewers are more concerned with enforcing Wikipedia standards, while the WMF is more concerned with broadening the content of Wikipedia to include under-represented groups and topics (since those groups are our most rapidly growing audiences)." NPPers are a not bunch of radical deletionists who like to put up impassable barriers for new users. In my experience, the exact opposite is true. Experienced reviewers are less bitey, use fewer and more relevant maintenance tags and nominate fewer acceptable articles for deletion than inexperienced users. That aligns very nicely with your goal of broadening the user base.

I used to work for a very large software company as a liaison between developers and customers. I understand the difficulties of dealing with an amorphous group of sometimes very frustrated users, and the challenges you face in prioritizing their requests. Based on my experience, I would suggest to you that the wish list is not the right tool.

The way that NPP is supported (or not) by the WMF needs to be re-thought. I think we should learn how to write our own code, and the WMF should limit its involvement in NPP to providing a solid API with a commitment to fixing bugs in that API. My experience in software development has taught me that customers are most successful with software that doesn't impose workflows, but has a rich and robust API that lets them implement the workflows themselves. So maybe that's the way forward. You've made it very clear that you intend to continue with the wish list. I urge you to reconsider that approach, and instead think about a way to provide minimal, but essential and on-going support. Do you think that is a conversation we could have?

all the best, Vexations (talk) 14:33, 5 November 2018 (UTC)[reply]

Hi Vexations, I'm happy to see that you may be reconsidering your retirement. I've already written a lot on this subject over the last few days, so I'm just going to touch on a few of your points.

An individual can only post three proposals, but a single proposal can contain more than one Phabricator ticket. The current NPP proposal in the Community Wishlist Survey has 18 tickets listed. If that proposal gets enough votes to make it into the top 10, then as I've said above, the Community Tech team will complete the great majority of those tickets. It won't take 20 years to get all 60 of the NPP tickets done, if the group keeps participating in the Wishlist Survey.

For getting votes: voting on the Wishlist Survey is way easier than reviewing a new article. When the voting period starts, you can cast a support vote by going to the proposal page, clicking a blue button to vote, and clicking another blue button to confirm. It takes less than a minute. As you said, 150 people reviewed an article in the last month, which is more than enough voters to get into the top 10. Last year, 150 votes would have made it the #2 proposal. Obviously, you can't expect to actually wrangle every single one of those 150 people to vote, but there's also the other 500 reviewers, some of whom are probably feeling guilty that they haven't reviewed an article in more than a month and will be happy to help. :) Your group has more than enough people to vote your proposal into the top 10.

If you want to start working on the software yourself, then you could also write a separate proposal asking for a solid API to work from. Community Tech often works with volunteer developers on various projects, and if you get that proposal into the top 10, the team will be able to work with you on that. So there are a number of different things that you can do over the next few weeks to make sure that you get what you want out of this process. -- DannyH (WMF) (talk) 15:21, 5 November 2018 (UTC)[reply]

Re : My proposal

Could you elucidate, why exactly why you have declined my proposal at the meta: Community Wishlist 2019 ? How does making cosmetic changes to MiniveraNeue have anything to do with my proposal which asks for the ability to change skins on the Mobile Frontend ? Timeless/Monobook mobile, supports the Twinkle gadget, something which is absent from MiniveraNeue even in desktop mode, as is the extremely useful RefToolbar — $f r +$ 11:09, 17 November 2018 (UTC)[reply]

Hi FR30799386: We try to keep the Community Tech team out of the way of other Foundation product teams when they're currently working on a project. This looked to us like it was going to interfere with the work they're doing right now, and we don't want to step on other teams' toes. Sorry, I know it's disappointing to have your proposal declined. Supporting Twinkle or RefToolbar in the existing skins would also be a good Wishlist proposal. -- DannyH (WMF) (talk) 19:30, 17 November 2018 (UTC)[reply]

What to do

in a case, when en-wiki editors can't agree on the optimum short-description which ought be used over an article (and atleast, some of the parties vehemently dislike the WD one)? In most of the general cases of content, the particular prose will be left out of the article unless a t/p discussion leads to consensus for any version pending which it's inserted. In other words, how to force the system to display nothing? ∯WBG^converse 18:26, 23 March 2019 (UTC)[reply]

Winged Blades of Godric: You can't, I'm afraid; it's going to show the Wikidata description until there's something in the English WP field. What's the article? -- DannyH (WMF) (talk) 17:16, 25 March 2019 (UTC)[reply]

The article and the discussion. ∯WBG^converse 17:23, 25 March 2019 (UTC)[reply]

Winged Blades of Godric: It looks like you and Galobtter figured how to resolve that issue a couple of days ago, which is good. One option when things like this come up is to go and edit it on Wikidata, while you're still discussing it. -- DannyH (WMF) (talk) 07:37, 26 March 2019 (UTC)[reply]

It's not resolved; I moved on. I don't see any reason as to why the folks over WD will allow me, (who is completely ignorant of the concerned WD policies), to have much of a say as to their fields. You were made aware of these situations back when we held the RFC but chose to ignore the community. ∯WBG^converse 14:07, 28 March 2019 (UTC)[reply]

Winged Blades of Godric: Looking at the article history and the discussion, it looks to me like Galobtter thought "Indian computer scientist" was appropriate, and you were suggesting something closer to "self-styled Hindutva based historical revisionist". On Galobtter's talk page, it looks like a pretty reasonable discussion about which part of the article's first sentence to use. You moved on by posting "Have your way and write or push whatever you seek" at 18:12, and two minutes later, Galobtter said, "No objection to changing the description to "self-styled Hindutva based historical revisionist" or something like that (though if he's primarily notable for that, I'd suggest swapping the lead sentence to have that description first.)" That looks like consensus for your point of view.

Rather than change the short description based on that agreement, you came to my talk page to object to the short description feature. After you posted your last message to me yesterday, you then went and added "Indian American computer scientist" as the short description, which was the source of your original objection.

As far as I can tell, this was a pretty ordinary run-of-the-mill disagreement about a piece of content, which was settled after a brief discussion. This would have wrapped up successfully a week ago -- about 15 minutes before you started this thread on my talk page -- but you haven't implemented the successful agreement that you made with Galobtter yet. It looks to me like the feature is working exactly the way it should -- you have the opportunity to discuss and come to agreement on the short description here on Wikipedia, without going to Wikidata. I don't think changing the feature would have yielded a better result than the one that's already happened. -- DannyH (WMF) (talk) 18:54, 29 March 2019 (UTC)[reply]

Growth Newsletter #19

Welcome to the nineteenth newsletter from the Growth team!

The Growth team's objective is to work on software changes that help retain new contributors in Wikimedia projects.

Structured tasks

"Add a link" is the team's first structured task. It uses machine-learning to suggest wikilinks as easy edits for newcomers. It was deployed in May 2021 on four Wikipedias and then in July on eight more Wikipedias after we evaluated the initial results. So far, we've seen a high level of engagement from newcomers. Communities that have the feature suggested valuable ideas for improvement. We'll work on improvements and then contact more communities to deploy it.
"Add an image" is the team's second structured task, currently in development. It is an editing task that suggests Commons images for unillustrated Wikipedia articles. We have conducted many community discussions and tests. Then, we've decided to build a first prototype. We'll first deploy it only to our pilot Wikipedias, to learn whether newcomers can be successful with the task. The project page contains links to interactive prototypes. We are very interested to hear your thoughts on this idea as we build and test the early versions. These prototypes have already been tested by newcomers, in English and Spanish.

News for mentors

The Mentor dashboard is available at our pilot wikis: Arabic, Czech, and Bengali Wikipedias. It will soon be available at a few more volunteering wikis, as a test. [4]
At wikis where the mentor dashboard is deployed, a new filter is available for mentors. Mentors can monitor their mentees' activity in Watchlist and RecentChanges, so they can help support their mentees' work. For privacy reasons, this filter can't be accessed by someone else than the mentor itself. This filter only filters mentees assigned to the mentor. This filter is not visible for people who are not listed as mentors [5]

Community configuration

Communities now have the ability to configure how Growth features behave on their own wikis. At Special:EditGrowthConfig, community members can add a list of volunteer mentors, alter the templates used for suggested edits, update help links, and more. This special page is editable by administrators and interface admins.

Scaling

We are proud to announce that all Wikipedias now have the Growth features! Thank you to all the community members who helped the team build the features and bring them to their wikis. The only exception is Chinese Wikipedia (zh), for technical reasons. [6]
The wikis that have Growth features deployed have been part of A/B testing since deployment, in which some newcomers did not receive the new features. Now, all of the newcomers on 280 of the smallest of those Wikipedias have the features. [7][8]
A test is undergoing at English Wikipedia: 25% of newcomers receive the Growth features. The results from this test will be part of a discussion of how to proceed on that wiki.
Now that Growth features are available at Wikipedia, the Growth team considers to extend them to other projects. Some Wikisource users have expressed some interest in getting Growth features. There is currently a discussion about implementing them on Wikisource.

News for communities

Do you have questions about the Growth features? This translatable FAQ contains answers to the most common questions about the Growth team work.
The Growth features were recently used in a test amongst Latin American donors to give donors the opportunity to learn to edit. You can see the results here.
Interface translations are important for newcomers. Please help for your language, by translating or copyediting interface translations for the Growth features.
Help:GettingStarted was a feature developed in 2013, which directed newcomers to articles that needed editing. We recently removed this feature from all wikis, because it has been replaced by the Growth features.

Growth team's newsletter prepared by the Growth team and posted by bot • Give feedback • Subscribe or unsubscribe.

18:36, 26 October 2021 (UTC)

Growth Newsletter #20

Welcome to the twentieth newsletter from the Growth team!

The Growth team's objective is to work on software changes that help retain new contributors in Wikimedia projects.

Suggested edits

As of February, 300,000 suggested edits have been completed since the feature was first deployed in December 2019.

Add a link is the team's first structured task, deployed in May 2021. It has improved outcomes for newcomers. The team is now working on a second iteration based on community feedback and data analysis. Improvements will include: improved algorithmic suggestions, guardrails to prevent too many similar links to be added, and clearer encouragement for users to continue making edits. After adding these improvements, we will deploy this task to more Wikipedias.

Add an image is the second structured task built by our team. It was deployed in November 2021 to four pilot Wikipedias. This is a more challenging task for newcomers. However, it adds more value to articles (so far, over 1,000 images have been added). We are currently learning from communities and from the data on what is working well and what needs improvements. The project page contains links to interactive prototypes. We are very interested to hear your thoughts on this idea as we build and test the early versions. We will soon deploy this task to more Wikipedias as a test.

"Add a link" and "Add an image" now both have a limitation on how many of these tasks newcomers can do per day. It is meant to discourage careless newcomers from making too many problematic edits.

Positive reinforcement

Over the last two years, the Growth team has focused on building suggested edits: easy tasks for newcomers to start with. We have learned with this experience that these tasks help many newcomers to make their first edits. Now, the team is starting a new project : "positive reinforcement". Its goal is to make newcomers proud of their editing and to make them want to come back for more of them. With the positive reinforcement project, we are considering three kinds of features:

Impact stats: give newcomers the ability to see how many people read the articles they edit.
Leveling up: encourage newcomers to progress from easier tasks to harder tasks.
Personalized praise: encourage mentors and other editors to "thank" and award newcomers for good work.

This project is just beginning, and we hope for community thoughts on the direction. We know that things can wrong if we offer the wrong incentives to newcomers, so we want to be careful. Please visit the talk page to help guide the project!

News for mentors

The mentor dashboard is available at all wikis. It helps mentors see who their mentees are and keep track of their activity. It is automatically activated where a list of mentors has been created. If you need assistance to create a list of mentors, please contact us.
The mentor dashboard has a new module: settings. It is now possible for mentors to define their status (active or away). They can specify the volume of questions they want to receive, and they can claim mentees in an easier way. It is also possible for mentors to quit, which will automatically reassign their mentees to other mentors.
We are working on an ability for a mentee to opt-out (and back in) to having a mentor.
Previously, in the table that displays mentees activity, the filters displayed all mentees, even the ones with zero edits or lots of edits. We have changed this so that only mentees with between 1 and 500 edits are visible by default. Mentors can change this value in their filters.
We are currently working on a special page for mentors to sign-up.

Some wikis have created userboxes that mentors can display on the user pages. If your wiki has one, please link it to Wikidata!

Scaling

Previously, at most Wikipedias, only 80% of newcomers were getting the Growth features. This was done for experimentation, to have a control group. We have changed this setting. Now 100% of new accounts at all Wikipedias get the Growth features (except a few, kept as test wikis). We invite communities to update their onboarding documentation and tutorials. Please include the Growth features in it. To help you, we have created an help page that can be translated and adapted to your wiki.

How to help

Do you have questions about the Growth features? This translatable FAQ contains answers to the most common questions about the Growth team work. We regularly update it.

Interface translations are important for newcomers. Please help for your language, by translating or copyediting interface translations for the Growth features.

Growth team's newsletter prepared by the Growth team and posted by bot • Give feedback • Subscribe or unsubscribe.

17:12, 16 March 2022 (UTC)

Growth team newsletter #21

Welcome to the twenty-first newsletter from the Growth team!

New project: Positive reinforcement

The Growth team started a new project: Positive reinforcement. We want newcomers to understand there is an interest in regularly editing Wikipedia, and we want to improve new editor retention.
We asked users from Arabic, Bangla, Czech and French Wikipedia about their feedback. Some people participated at mediawiki.org as well.
We summarized the initial feedback gathered from these community discussions, along with how we plan to iterate based on that feedback.
The first Positive Reinforcement idea is a redesign of the impact module: incorporating stats, graphs, and other contribution information. This idea received the widest support, and we plan to start our work based on the design illustrated on the side.
Please let us know what you think of this project, in any language.

For mentors

We have worked on two new features, to inform them about the mentorship:
- In the Mentor module, we now provide more information about the public nature of the mentors/newcomer relationship and the fact that talk pages are public.
- We now allow newcomers to opt-in and opt-out of mentorship.

Scaling

"Add a link" available at more wikis ― Add a link feature has been deployed to more wikis: Catalan Wikipedia, Hebrew Wikipedia, Hindi Wikipedia, Korean Wikipedia, Norwegian Bokmål Wikipedia, Portuguese Wikipedia, Simple English Wikipedia, Swedish Wikipedia, Ukrainian Wikipedia, Abkhazian Wikipedia, Achinese Wikipedia, Adyghe Wikipedia, Afrikaans Wikipedia, Akan Wikipedia, Alemannisch Wikipedia, Amharic Wikipedia, Aragonese Wikipedia, Old English Wikipedia, Syriac Wikipedia, Egyptian Arabic Wikipedia, Asturian Wikipedia, Atikamekw Wikipedia, Avaric Wikipedia, Aymara Wikipedia, Azerbaijani Wikipedia, South Azerbaijani Wikipedia. This is part of the progressive deployment of this tool to more Wikipedias. The communities can configure locally how this feature works.
"Add an image" available at more wikis ― Add an image feature will be deployed to more wikis: Greek Wikipedia, Indonesian Wikipedia, Polish Wikipedia, Chinese Wikipedia. These communities will be able to configure locally how this feature works. [9]

Suggested edits

Selecting topics ― We have created an "AND" filter to the list of topics at Special:Homepage. This way, newcomers can decide to select very specific topics ("Transportation" AND "Asia") or to have a broader selection ("Transportation" OR "Asia"). At the moment this feature is tested at pilot wikis.
Changes for Add a link ― We have built several improvements that came from community discussion and from data analysis. They will be available soon at the wikis.
- Algorithm improvements ― The algorithm now avoids recommending links in sections that usually don't have links and for first names. Also, it now limits each article to only having three link suggestions by default (limited to the highest accuracy suggestions of all the available ones in the article).
- User experience improvements ― We added a confirmation dialog when a user exits out of suggestion mode prior to making changes. We also improved post-edit dialog experience and allow newcomers to browse through task suggestions from the post-edit dialog.
- Community configuration ― We allow communities to set a maximum number of links per article via Special:EditGrowthConfig.
- Future change for Add a link feature ― We will suggest underlinked articles in priority. [10]
Patrolling suggested edits ― Some users at Arabic Wikipedia, Spanish Wikipedia, and Russian Wikipedia told us that "Add a link" and "Add an image" edits can be challenging to patrol. We are now brainstorming improvements to help address this challenge. We have already some ideas and we started some work to address this challenge. If you have any thoughts to add about the challenges of reviewing these tasks or how we should improve these tasks further, please let us know, in any language.

Community configuration

Communities can configure how the features work, using Special:EditGrowthConfig.

Communities can set the maximum number of "add an image" suggested tasks a newcomer can complete daily. [11]
Future change: allow communities to customize the "add a link" quality gate threshold easily, using Special:EditGrowthConfig. [12]

Growth team's newsletter prepared by the Growth team and posted by bot • Give feedback • Subscribe or unsubscribe.

13:03, 5 July 2022 (UTC)

Growth team newsletter #22

Welcome to the twenty-second newsletter from the Growth team!

Newcomers tasks reach the 500,000 edits milestone — more data publicly available

As of the last week of June 2022, the newcomers of the world have completed over 500,000 newcomer tasks. In other words, newcomers have made over half a million Wikipedia edits via Growth’s “Suggested Edits” module.

About 30% of those edits were completed on mobile devices.
Usage continues to increase; in June 2022 almost 50,000 newcomer tasks were completed.

We have added some new data to Grafana. You can now check the number of edits and reverts by task types, or the number of questions asked to mentors. You can filter the data by wiki.

If you have any questions, or there is more data you want access to, please let us know.

Ongoing projects and explorations

We are continuing our work on our new project, Positive Reinforcement. User testing of initial Positive Reinforcement designs was just completed. Interviews were conducted in Arabic, English, and Spanish. The outcome has been published on the Positive Reinforcement page. We are now utilizing user testing feedback along with prior community feedback to iterate and improve designs.

We are exploring the idea of a Copy Edit structured task. We have tested copy edits in Wikipedia articles for arwiki, bnwiki, cswiki, eswiki (Growth pilot-wikis) and enwiki with two different methods: LanguageTool and Hunspell. We will share more details here and on the associated Copy Edit page once the evaluation is complete.

Add an image was utilized at GLAM events in Argentina, Mexico, and Chile. For an overview of what was learned from these events, read: #1Pic1Article I: how Latin American heritage experts added images to Wikipedia (in English).

Experiments analysis

Add a Link Experiment Analysis has been published. The most important points are:

Newcomers who get the Add a Link structured task are more likely to be activated (i.e. make a constructive first article edit).
They are also more likely to be retained (i.e. come back and make another constructive article edit on a different day).
The feature also increases edit volume (i.e. the number of constructive edits made across the first couple weeks), while at the same time improving edit quality (i.e. the likelihood that the newcomer's edits aren't reverted).

Newcomer task edit type analysis has been published.

Communities had expressed concern that newcomers whose initial edits were structured tasks wouldn’t go on to learn how to complete more difficult tasks. The Growth team data scientist conducted a Newcomer task edit type analysis to see if this was indeed the case.
Results from analysis indicate that this likely isn’t a significant concern. More than 70% of users who start with the easy task "Add a link" also make another task type. Read the full analysis and methodology here.

News for mentors

A new system for the mentors list

The configuration of the mentors list will change over the next weeks. In the future, mentors will sign up, edit their mentor description and quit using Special:MentorDashboard. This new system will make the development of new features for mentors much easier.

At the moment, the mentor list is a simple page anyone can edit, unless it’s protected. With the new page, mentors will be able to edit only their own description, while administrators will be able to edit the entire mentors' list if needed.

The deployment will happen first at the pilot wikis, then at all wikis. Existing lists of mentors will be automatically converted, no action will be needed from the mentors. [13][14]

Mentors will be informed about the next steps soon, by a message posted on the talk page of existing Mentor lists.

Learn more about this new structured page on mediawiki.org.

A tip for mentors

Did you know that mentors can filter their mentees' changes at Special:MentorDashboard (and star the ones that require attention)? This feature helps to keep an eye on newcomers' edits, helping mentors to fix minor details, and encourage them if necessary.

And did you know that mentors have special filters to highlight their mentees' edits at Special:RecentChanges? Look for the following filters in RecentChanges: Your starred mentees, Your unstarred mentees.

Other improvements

Some improvements will be made to the mentor dashboard in the coming weeks:

While we now offer some options for mentors to take a break, the option to quit mentoring was not easy to find. This will be improved. [15]
Mentors at wikis using FlaggedRevisions will have a way to discover their mentees' pending edits. [16]
Dashboard discovery for new mentors will be improved. [17]

Recent changes and fixed bugs

We moved to a new Image Suggestions API. This new API will allow us to deploy Add an Image to more wikis. [18]
Starting September 19, a few more wikis now offer Add an image to newcomers. These wikis are Greek Wikipedia, Polish Wikipedia, Chinese Wikipedia, Indonesian Wikipedia, Romanian Wikipedia. [19]
Add an image has been disabled for a few days due to technical issue. "Add an image" added a blank line instead of an image. This has been fixed. [20]
In order to know if Special:EditGrowthConfig is used by communities, we now instrument page loads and saves of configuration. [21]

Have a question? A suggestion?

Please let us know! You can also read our FAQ page.

Growth team's newsletter prepared by the Growth team and posted by bot • Give feedback • Subscribe or unsubscribe.

17:18, 21 September 2022 (UTC)

Growth team newsletter #23

Welcome to the twenty-third newsletter from the Growth team!

Highlights

Mentorship: We released the new structured mentor list to all wikis. This change makes mentorship easier to setup, manage and use.
Positive reinforcement: An improved impact module is available for testing.

Positive reinforcement: an improved impact module to test

The goal of the Growth team is to encourage newcomers to try editing for the first time, and encourage them to keep editing. We want to increase newcomers' motivation by showing them how impactful their edits are.

Newcomers have access to an impact module; you can find yours at Special:Impact. The revised impact module provides new editors with more context about their impact. It will display the number of edits, the number of thanks received, the last time they edited, the number of consecutive days they edited, and the number of views for the articles they edited.

This module will soon be available at our pilot wikis starting December 1. You can already test this new module at Beta Wikipedia. For safety reasons, do not use your regular account and password at Beta wiki. Create a new, specific account for this wiki, with a different password.

Structured tasks: improvements based on patroller feedback

After the deployment of Structured tasks, we received feedback from various communities regarding how patrollers of recent changes were feeling overwhelmed by an increase in edits to check, and how some edits were poor quality or of poor relevance.

We made several improvements based on the feedback we received. Several points of improvement have already been addressed:

Patroller fatigue:
- By default, newcomers can complete up to 25 "add a link" tasks and 25 "add an image" tasks per day. If patrollers are overburdened, each community can use Special:EditGrowthConfig to lower that limit.

Quality of edits: what constitutes a "quality edit" is not a well defined concept. We initiated a discussion and summarized our findings. We also worked on the following improvements:
- Add a Link
  - Underlinked articles are now prioritized, so it's less likely that newcomers are adding links to articles that are already have a lot of links.
  - The confidence score was increased, so suggestions are more likely to be accurate.
  - The default number of suggested links per article has been lowered to 3. This can be changed at Special:EditGrowthConfig. Communities can also exclude articles containing certain templates or categories from being suggested.
- Add an Image
  - Lists will no longer receive "add an image" suggestions.
  - Disambiguation pages will no longer receive "add an image" suggestions.
  - We have many further improvements we plan to make to "add an image" in early 2023. [22]

The Positive Reinforcement project will also address some of the concerns around encouraging newcomers to progress to higher value edits. The Growth team will soon work on strategies geared at "Leveling up" newcomers so they progress from easy to more difficult tasks.

Recent changes

All Wikipedias now have the same onboarding experience. Previously, at a few wikis, 20% of new accounts didn't get the Growth features when they created their account. These 20% of new accounts were used as a control group, in order to know if the Growth features were changing newcomers' behavior. Experiments have shown that Growth features improve activation and retention, and as we want to provide the same onboarding experience at all Wikipedias, we have decided to remove the control groups. We will utilize control groups when testing new features, and German Wikipedia keeps a control group at their request. [23]
The quality score for "add a link" suggestions will change. We will suggest less links for each article, but they will be more accurate. We will first deploy it at our pilot wikis, and then to all other wikis where this feature is available. [24][25]
Growth's features FAQ has been updated and expanded. This page centralizes all the information about Growth features. We invite you to read it, and, if you can, to translate it.

News for mentors

All Wikipedias can now setup and manage a mentorship program in an easier way.
- We changed the process to make it more reliable, easier to improve and easier to use.
- Wikipedias where mentorship hasn't been enabled yet can turn mentorship on following a new process. When done, mentors can sign-up by visiting Special:MentorDashboard.
- Wikipedias where the list of mentors already existed have been converted to the new system.
- A new special page — Special:ManageMentors — now displays the list of mentors. This page can be transcluded on any other page. There are also new processes to signup as a mentor or to quit mentorship, and we improved community mentorship management.
The Mentor dashboard's "Your mentees" module will have a new footer, called "Recent changes by your mentees". This footer will include a link to Recent changes, where mentors can see only edits made by their own mentees. [26]

Deployments

Add a link has been deployed to a 5th round of wikis. [27]

Improving this newsletter

We plan to have a more regular newsletter, every two months. We also want to know if the current format suits you! Let us know what you like, what you like less and your suggestions of improvements: leave us a comment, in your preferred language.

Growth team's newsletter prepared by the Growth team and posted by bot • Give feedback • Subscribe or unsubscribe.

20:57, 29 November 2022 (UTC)

Growth team newsletter #24

Welcome to the twenty-fourth newsletter from the Growth team!

Newcomer experience projects

The Growth team partnered with other WMF teams to conduct several experiments around increasing account creation and new editor retention. Results from four of these experiments are now available:

Thank you pages & banners - Encourage donors to create accounts through thank you pages and banners.
Marketing experiment - Run ads on-wiki and off-wiki to see how this impacts account activation.
"Add an image" GLAM events - Host GLAM events that focus on using the "Add an image" tool.
Welcome emails - Experiment sending welcome emails to newly created accounts.

Newcomer tasks

Several communities suggested improving "add a link", by suggesting underlinked articles first. We released this change to Growth pilot wikis. We will review the data and collect feedback before considering releasing it to more wikis. [28]
The deployment of the "add a link" to all Wikipedias is still in progress. Suggested links use a prediction model, which has to be trained. The deployments will resume after we finish training all models. [29]

Mentorship

When someone wants to signup as a mentor, they are now informed if they don't meet the defined criteria. [30]
Workshop hosts asked us to have workshop attendees assigned to them. They can soon use a custom URL parameter. This way, workshop hosts will continue mentoring the event's attendees after the workshop. It will be available in February. [31]
Have you considered to help new editors on your wiki, by signing up to be a Mentor?
- Please visit Special:MentorDashboard to check on the conditions to be a mentor, and sign up.
- If your wiki does not have Mentorship enabled, consider setting it up. The Growth team can provide advice and assist as needed. Please ping Trizek (WMF) for assistance.

Other news

In Special:SpecialPages, Growth experiments now have their own section. [32]
This newsletter will have a new publication period, 6 times a year: January, March, May, July, September, November.

Translations

Newsletter translation: We are looking for translators for this newsletter. If you are interested and have the needed English language proficiency to assist, then please add your name to this list. You will receive an invite on your talk page to translate the newsletter when it is ready.
Interface translation: You can also help by translating the interface, or reviewing translations to make them more inclusive. Interface translations are hosted at translatewiki.net.

Growth team's newsletter prepared by the Growth team and posted by bot • Give feedback • Subscribe or unsubscribe.• Help with translations

14:44, 31 January 2023 (UTC)