I've been heavily editing Wikipedia:Wikipedia:Encourage the newcomers, trying to give fairly concrete and evidence-based advice, and it occurs to me that there are some experts here, too. I'd appreciate any criticism, commentary, or contributions. HLHJ (talk) 03:00, 7 October 2019 (UTC)
Jump to navigation Jump to search
Reply to "Encourage the newcomers feedback"
Reply to "Tools"
I would propose a few tools to support and give feedback to both newcomers and oldtimers. (Just me trying to write down some ideas, aka ranting…
Reply to "NavWiki project space is in development on the Outreach wiki"
Reply to "Growth/Navbar"
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.
Encourage the newcomers feedback
Thank you for sharing this! I've read it and I think it is a good approach to introduce the work with newcomers.
Here are some ressources you can use to enrich your page, as examples or as inspirations:
- New Editor Experiences - a research program about new users (typologies, what are their motivations...)
- How to interact with newcomers - an help page created by Growth to help mentors interacting with newcomers
- Editing Wikipedia with my parents may be a good reading, to see how newcomers make their first steps
- An analysis of two reports made by French Wikipedia and Hungarian Wikipedia about welcoming new users (in German), published on the Kurier. FYI, the French part was done by volunteer-me.
Hi @HLHJ -- I think it's really cool that you're working on that page. How will other editors find it and read it? One thing that I definitely recommend including is advice on how experienced editors can recommend tasks to newcomers. Many newcomers arrive with something specific and challenging they want to do, such as write a new article. They don't realize that writing a new article is one of the most difficult things to do on Wikipedia, and so they try, fail, and leave. It can be good for an experienced editor to say something like, "It's good that you want to write a new article about a band. That's one of the most challenging things to do on Wikipedia. I bet you'll end up succeeding with your article if you practice some easier edits. Here are some existing articles about bands that could use some copyediting."
Sorry for the slow reply, I have some problems with my use of the notifications system, as you know :).
- An analysis of two reports made by French Wikipedia and Hungarian Wikipedia about welcoming new users (in German), published on the Kurier.] (archived version, as link above now broken)
- I think this is a bit out-of-scope for the essay, which is more about individual actions than community ones (though I'd agree that the latter are important changed my mind, added draft content). I'll add in "How to interact with newcomers", though, it's an excellent collection of traditional knowledge, if I can use that for a community of ca. 1 generation age. It would be really great if that page had citations to empirical evidence, maybe an observational study... I assume you've seen this on de's checked version system?
"Editing Wikipedia with my parents" is fascinating; I tend to see it as confirmation of my preconception that the main good/bad experience determinant is the interactions with other editors. I barely interacted with other editors at all for the first decade or so on en; IP editing, not even revert notifications. I guess that put me in the "Knowledge sharer" profile. On fr and de, though, I've generally had edits reverted for inadequate language skills; the implication that the editors there do not consider my edits worth ten seconds of their translation-polishing time is rather demotivating. I polish translations on en, and while sometimes the English is hard to understand ("velvet municipality"? oh, Samtgemeinde) I find that amusing.
"Encourage the newcomers" gets about 50 views a day these days. I did link it from WP:BITE, which is fairly trafficked, so hopefully anyone interested will find it. I've added some material on recommending tasks and new editors' goals, though it's still pretty rough and poorly-integrated; I'll come back to it when I've thought it over. HLHJ (talk) 05:04, 10 November 2019 (UTC)
I would propose a few tools to support and give feedback to both newcomers and oldtimers. (Just me trying to write down some ideas, aka ranting…
- Random award
People tend to continue doing things where they get a slightly random award. People tend to keep trying to get such rewards, even if the likelihood are pretty small. Compare to casino-like games.
It is rather well-documented how and why this work, and some people use it as an argument for free contributions vs paid contributions. That is probably wrong, but the argument is made anyhow. Its origin could be hunter-gatherers, and a continued quest for food even if they often failed.
That makes me believe there should be a page where new contributions are highlighted. A kind of special page “in the work”. That page can pick pages with larger contributions after they are patrolled or some time after the contributions are uploaded. Because the list should be limited it would be slightly random which page (contributions on that page) reach the special page. It is a feature that only some reach that page, but it could be possible to include more on the page if the reader choose to do so. Imagine the page as a “recent changes” with a lead paragraph with a list of the last contributions, and notify the user when his/her contributions reach the special page.
A practical implementation would pick pages that are above a certain threshold in size, and likewise a threshold on contribution. Above that threshold it would be included with a probability that scale with the accumulated size of the contributions.
- Activity feedback
Users at Wikipedia are very eager on measuring their impact and reach, which makes me wonder if it is possible to create some kind of simple indexes or badges. It could be a kind of “six degrees of wikiholicks” with some funny comment popping up in the notification centre when you reach a higher level. As activity changes, it could be measured over some timespan, with some feedback (badges) early on that is pretty simple to get. Later on it could be logarithmically harder to get badges. Now our only feedback to newcomers seems to be a notification that their edits are rolled back, which gives a negative feedback.
Comparable systems are Khan Academy, Duolingo, and several other.
- Ongoing work
I've been wondering if it would be a good idea to have a note on user pages about what page the user is editing. It would be like an implicit Kanban queue. If a page is open for edit in a tab, we could use a ping to the server and keep track of it in the session, and the user has several recent changes to the page, then it gets posted as “current work” or “work in progress” on the user page. If the user hasn't any contributions to the page, or if the contributions are too old, then it will not be listed. Likewise if the edits are not patrolled. A similar note can be posted on the content page itself, thus giving a positive feedback to the editing user. By limiting the number of listed pages it will give the contributor a sense of what s/he should focus on, ie. finish the current work, yet it allows the user to do random edits on other pages.
Note that “current work” should follow the page, and when another user moves the page to another title the note should keep pointing to the correct page.
NavWiki project space is in development on the Outreach wiki
Participants on this talk page, particularly @MMiller (WMF) and @Kudpung, may remember this video project. I am creating a project space for the videos and associated information on the Outreach wiki at https://outreach.wikimedia.org/wiki/NavWiki. Please post on the project talk page on Outreach if you have questions or comments. I plan to send a newsletter with project status information to all tutorial newsletter subscribers during the next few weeks. Regards.
Hi @Pine -- thanks for letting us know. I'll post a couple questions for you on Outreach.
Would it be possible that the links in the Template:Growth/Navbar point to the localized pages? If somebody reads a localized page with the navbar, and would like to use it to navigate between the projects, arrives always to the English pages instead of the localized ones. This can be confusing even for experienced editors.
I realized, that it works as I wanted, as soon I change the surface language from English to X (Hungarian in this case). Sorry.
I havent found a nice way to add a direct link for translations. If you have an idea, I'm interested! :)
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?
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.