Hi, we've just started a new project on the Hungarian Wikipedia for editor retention. The Hungarian Wikipedia fits perfectly to your target wikis, and I was wondering whether we could join to the Growth program?
Jump to navigation Jump to search
Reply to "Hungarian Wikipedia"
Perhaps I should have said "conflicting views"; obviously calling someone a numbskull will not improve content.
Reply to "Conflict and editor retention"
Reply to "A good start"
Reply to "Community Wishlist Survey"
Reply to "Notification of request for incremental grant funding"
About this board
Discussion related to the old Growth team is archived at Talk:Growth/Growth 2014.
Hello Samat, and thank you for your interest on Growth projects.
We are going to discuss it within the team and keep you informed.
Thank you, I am looking forward to the result :)
We have discussed a bit about involving your community and we think it is a good community. We need to work on some details before we start the process.
In the meantime, can you confirm that someone will be able to do the following: translate messages, translate newsletters, provide links, motivate people to reply to newcomers questions, and to have meetings sometimes (maybe every two weeks)?
Dear Trizek, thank you for reply. I don't know exactly, what are the needs of the project (for example how long are these newsletters :)), but I am glad to participate and help. It would be useful if you could inform me about the details of the planned activities, necessary tasks etc. Since beginning of April I am the project manager of our retention program, and the Growth program fits very well what we would like to try and achieve, and I would like to use the synergy between the two programs.
We can separate the work to do in two parts:
First, setting-up the tools.
Growth tools require configuration and translations. Setting them up would require your community to provide a lot of things (like links to some help contents, explain the context of your community dynamics, translate the interfaces and some help contents...). We are working on setting up a document to recap all of that.
Then, when the tools are deployed, the community needs to make a great effort to reply to newcomers on the help desk. Your retention program will very likely cover those needs.
So it is a question of how much time your community can spend on preparing the tools for deployment, and then to maintain an effort around newcomers. That effort is important: some communities are surprised by the number of requests they have to face.
Newsletters are posted once a month .You can find exemples on Growth/Newsletters. We recently changed our format and now the newsletter is translatable.
We also have some community ressources Growth/Communities that are translatable and, of course, open for discussion to be improved.
As I said, we have some work to do on our side. I'll keep you posted about the next steps. :)
Dear Trizek, I would go forward. Let me know what is the best way setting-up the tools, what is the priority order for the tasks? I've talked in the community, and we would try to join the program. I will do my best to make it smooth, and there will surely be a few editors who will help.
As you know, at the moment, we have a short list of wikis we work with and monitor. Adding yours requires a bit of work. since you've the first wiki to ask for those tools.
We definitely want to deploy the help panel for you (that require no monitoring), but we're deciding about the other components.
You can start translating the Growth pages on mediawiki.org, so as our community ressource for help desk, and figure out if community members are ready to reply to newcomers following those best practices. You can also ask from volunteers to translate the interfaces.
I'll keep you posted with updates soon.
Hi @Samat -- our team is now ready to bring Growth features to Hungarian Wikipedia. We've published a checklist here of what communities need to do in order to be ready. Please take a look and let us know if you have any questions, or if you want to discuss! We are excited to be working with your community.
Dear Marshall, thank you for your and for your team's help. We will go through the checklist to prepare the Growth features for the Hungarian Wikipedia. I will let you know if we have any question.
Conflict and editor retention
I'd like to post an interesting article about Wikipedia interactions (preprint):
"The Wisdom of Polarized Crowds" (29 November 2017). arXiv:1712.06414 [cs, stat].
In summary, it says that conflict is unpleasant and drives editors away, but it makes article content better. The authors welcome feedback.
I'm wondering if telling editors that conflict is productive might make it less unpleasant, especially as "I'm wasting my time here" is a frequent reaction to conflict. It would be interesting to do some experiments with different messages and see if they affect retention or productivity. HLHJ (talk) 22:32, 20 January 2019 (UTC)
I don't think "conflict" by itself makes the article better. Rather, conflict as an accessory to shared goals ''can'' (but not always) make an article better.
Perhaps I should have said "conflicting views"; obviously calling someone a numbskull will not improve content.
Well, consider conflict as the default path to improve articles is not really the best one. We should avoid conflicts.
Thanks for the link, @HLHJ. I'll check the article out. One question I would have right off the bat is what percent of newcomers actually are around long enough to experience what this article would call "conflict".
Depends on what the first article you edit is, I guess. "Donald Trump" will probably run you straight into conflict, even if you are a really competent editor, while (hitting the random article button) "Alastair Macdonald" would probably not. HLHJ (talk) 04:01, 23 February 2019 (UTC)
A good start
@MMiller (WMF): this page in its present condition looks to me like it is a good starting point. I have two suggestions and a question.
- Could you explain the preference to start with mid-sized wikis instead of small wikis?
- I suggest that you create a sidebar or other prominent placeholder on the page to display the table of contents of your current newsletter and a link to archived newsletter issues.
- A book that I read awhile ago at the suggestion of Benjamin Mako Hill is Building Successful Online Communities. I suggest that you at least skim though the potions that seem to be the most relevant to your work.
@Pine: thank you for the comments, and I'm sorry for not replying sooner. I didn't have my notifications set up correctly on Mediawiki.org, and didn't see your comments until now.
- We are starting with mid-size instead of small wikis because our team is a software engineering team that will make changes or additions to the Mediawiki software to attempt to increase retention. We'll need a sufficient volume of new editors coming into the wikis in order to be able to detect and learn from the changes we're making. We'll also need a sufficient volume of experience editors, since our features will likely involve mentorship from experienced editors to new editors. For those reasons, we think mid-size wikis will have enough volume, but are still small enough that new editors retention is an important priority for them. When we find changes that make an impact in the mid-size wikis, we can absolutely work with small wikis to deploy them there, also.
- Thanks for the idea about the newsletter. (Please do sign up to receive it here!) I'm also tagging our Community Engagement Specialist, Trizek (WMF), since he works on our newsletter.
- Thank you for the book suggestion. I'll check it out! It sounds really relevant.
This project 'Growth Team' obviously has the makings of the very best intentions,. However: "The Growth Team's objective is to work on software changes that help retain new contributors in New Editor Experiences/Midsize Wikipedias|mid-size Wikimedia projects. We will be starting with Wikipedias, but we hope these changes will benefit every community" , ignores, or appears to ignore, the need for new and improved tools to enhance the work and experience of the volunteers who do the grunt work of keeping the content of our major projects clean and appropriate. ~~~~
@Kudpung: thanks for checking out the page. While our objective for this team will be to increase retention on mid-size Wikipedias, one of the things we're definitely planning on taking into account is what the engagement with new editors will mean for the experienced editors. We'll need to keep in mind that when new editors ask questions and make edits, that will fall to experienced editors to receive and respond to.
That is correct, but the main place where new editors get lost or retained is at New Page Review. Although only Reviewer rights holders can actually mark new pages as accepted, ''any'' editor can tag new pages for deletion and/or other issues whether experienced or not. Maintenance tasks are a magnet to new and inexperienced users. This is an issue that needs to be addressed. Also, right now, reviewing of new pages by authorised reviewers has almost come to a standstill. Somehow, the use of the New Pages Feed and its Curation tool need to be made more attractive. Kudpung (talk) 01:12, 28 August 2018 (UTC)
@Kudpung: for what it's worth, the project for which I am currently requesting funding has English Wikipedia as its first (but definitely not exclusive; I am hoping for translations!) audience, and I hope that the videos and other materials that I create and/or organize in the scope of my project will be helpful for new editors who are creating their first articles. I'm also hoping that the materials will be helpful for new article reviewers and for the Teahouse hosts in the sense that I hope that the reviewers and helpers can refer to the videos and materials for explanations that they won't need to repeat and are more understandable to newbies than walls of text would be. :)
@I have mentoned you on another thread on Wikipedia that you may be interested in recasting a video for NPP if the WMF is not in a position to do so. ~~~~
Thanks Kudpung. I will take a look.
Community Wishlist Survey
Yesterday I posted a Community Wishlist Survey proposal that had to be archived because (1) I went over the maximum of three proposals per user and (2) the proposal wasn't really suited to what Community Tech was doing.
I was, of course, told that "we have a whole team - Growth - that work on this [editor retention?] full time". I knew that this WMF team existed but I wasn't aware that their/your work would encompass all the things I was suggesting, which are, broadly speaking,
- targeted advertising outside the Wikimedia projects to recruit new editors, and analysis to improve that process
- allowing users to post and reply to tweets with the WMF-owned Twitter accounts through a consensus mechanism (or doing something else with the Twitter accounts to increase engagement)
- notifications for new users, asking them to come back and make more edits (if they're inactive), and suggesting new ways to edit
Are these things within the purview of the Growth team? I hope they're useful suggestions, if anything.
Hi @Jc86035 -- thanks for posting here and for caring about new editor retention. The Audiences department here at the foundation has thought a lot about this topic over the last year, and we actually have several things ongoing that address it. You're right that the engagement of new editors has been decreasing or being stagnant since about 2007. This paper discusses exactly how and why.
One of the things we noticed, however, is that a lot of people attempt editing, but very few stick around and keep editing. Therefore, we have thought less about recruiting new editors, and more about retaining the ones who do show up. For instance, about 2,000 new users create accounts in Korean Wikipedia every month, but only about 160 of those will come back to edit more than once. That's what our team is focused on: new editor retention (specifically in mid-size Wikipedias, who have challenges with "getting over the hump" of having enough content to be reliable sources of knowledge in their societies). You referenced that concept of a "funnel" in your proposal (e.g. maybe people don't know they can edit), and this paper talks about that specifically. And the foundation's research on new editors also digs into retention.
There are also a couple other teams working on retention of editors, such as the three teams working on mobile editing. That became a priority because we learned that newer generations and cultures coming online would much prefer to edit on mobile than desktop, and therefore having that option available would help retain new editors.
So with respect to the ideas you listed, I think the first two are "higher up in the funnel" than we are focused, because they are about informing people that editing is possible. (The New Readers team, however, did advertising last year in a couple countries to inform people that Wikipedia even exists). But the third idea is actually one that our team is thinking of prioritizing. When we discussed potential retention ideas with the broader community a few months ago, the idea of contacting new users to bring them back is one that we discussed positively. We ultimately decided not to work on it first, but it is on our short list for the future. I encourage you to go ahead and add things to that discussion page if you have thoughts on that (or any other idea).
Categories for images
I have uploaded several hundred images, including dozens of original designs (e.g. flowcharts, concept diagrams, etc). Many of my original designs have been rejected on the basis that they are not original which after labouring for hours to produce them, I find extraordinary! But my most perplexing issue relates to a series of artwork images that I uploaded recently - the majority were by Iraqi artists. I searched Commons to ascertain whether the image already existed with an Arabic caption. If so, I provided English information about the work and categorised it by artist, geographic location and other relevant information such as subject matter. Next, I searched for important artworks that might be useful to the collection and uploaded them, with details and where necessary, a rationale for limited use. These were also categorised by artist, geographic location (for sculptures and monuments) and other relevant information such as subject matter. Within 24-48 hours, the majority of the categories had been deleted by an editor, who then created new superordinate categories and assigned them to that. Apparently this editor would only allow ONE category per artwork. Now, this is problematic for several monuments which were started by one sculptor who died before the work was compeleted, requiring a different sulptor to finalise the work. In other cases, the work may have had both and architect or engineer as well as a sculptor working on the project. I had categorised the work according to all principal persons associated with its execution - but apparently this editor would not allow that. The editor in question deleted all the work that had engaged me for almost a week on a full-time basis. It's very easy to press the delete button - but much harder to go through a serious process of researching a work, learning about its history and locating suitable images. At that point, I decided to more or less give up on adding images to Wiki Commons. ~~~~
To upload works of art, the work has to be in the public domain in the United States (either 75 years from the death of the creator for unpublished works, or 95 years for published works). Or if the creator has given permission for their work to be freely distributed. Essentially, this means that you won't be able to upload any work that was created after 1922.
You will have more details if you post that question on Wikimedia Commons' Help desk.
Notification of request for incremental grant funding
Hello Growth Team, I would like to notify you of the creation of my request at:meta:Grants:Project/Rapid/Pine/Continuation of educational video and website project for incremental grant funding . I would appreciate hearing any questions or comments from you on the talk page of that grant request. Thank you, --Pine✉ 00:43, 14 August 2018 (UTC)
Thanks for letting us know, Pine. I will check it out and get back to you!
@Pine: I read your proposal; thank you for letting me know about it. I've definitely heard from multiple communities that videos can be useful, and I remember at Wikimania hearing that videos had had particular success in the Arabic community. Why do you think there have not yet been successful videos in English? Are there particular approaches that you're going to take in your videos that you think will make yours strong? Our team is interested in figuring out how best to communicate the difficult-to-understand concepts behind the wiki.
Hi @MMiller (WMF):, I have been somewhat surprised that no one else (that I know of) has produced videos for English Wikipedia or Commons in recent years. I can make a few guesses about why others have not done so. Generally, English Wikimedians in particular seem not to spend a lot of time writing help documentation (although the Teahouse and IRC get plenty of use for live help) and my guess is that whatever factors result in so few English Wikipedians working on documentation are closely related to the factors that result in lack of volunteer time spent developing help videos. One factor could be that because ENWP and Commons have extensively developed policies and procedures, therefore significant thoughtful effort is required to write and present information about them in an organized, coherent, and accurate manner. Developing high quality videos from start to finish is an activity that requires a lot of time for both planning and execution, and my guess is that many Wikimedians prefer to spend their time on objectives that are achievable with much less time spent on planning. Another factor is that videos are often linear while the nature of workflows often involves tree-like decision structures, so significant thought is required to decide which workflows to depict in videos and how to address the decision points in the workflows.
Two of my hopes for the videos that I produce are that (1) videos will be easier and faster for new contributors to understand than text explanations, especially when those text explanations are spread across multiple pages or require detailed examination of documentation, and (2) that experienced Wikimedians who volunteer their time with helping newbies and doing quality control will find that the videos save time because the experienced Wikimedians can refer newbies to my videos instead of writing text explanations, or can write shorter text explanations if those explanations are accompanied by my videos.
Hope this edit was OK.
That's great, thank you!
There are no older topics