Talk:Growth/Personalized first day/Newcomer tasks

About this board

Use of maintenance templates

11
Izno (talkcontribs)

I think it's a good idea to use maintenance templates in the general case.

I am concerned that there may be some maintenance templates that are unsuited. For example, the templates in en:Category:Wikipedia copyright maintenance templates usually require some delicacy/care to ensure that that fix has been implemented correctly, and usually require administrator effort to remove the copyright violation copy from the page history.

Martin Urbanec (WMF) (talkcontribs)

Hello, the Growth team has asked ambassadors for each target wiki to provide a list of maintenance templates, and we're not using _all_ maintenance templates, just some of them, which we deem to provide reliable results.

MMiller (WMF) (talkcontribs)

@Izno -- thanks for reading the newsletter and weighing in! Yes, like @Martin Urbanec (WMF) said, we are being careful to use maintenance templates that actually make sense for newcomers to work on. We did that work in this Phabricator task and its subtask, if you're interested in seeing the details. Which maintenance templates do you think are the best ones for newcomers to work on?

Izno (talkcontribs)

I think the lists I see in that task are pretty reasonable. I would be concerned about image-related ones since we immediately get into complex questions of non-free media and possibly biting new users who naively upload a non-free image which is immediately deleted.

MMiller (WMF) (talkcontribs)

Got it -- thanks. That makes sense about images. We were also talking about images in this other thread: Topic:V8fug8k6weg1p4ua

John Broughton (talkcontribs)

There seems to be a belief - among new and inexperienced editors, at least - that adding a maintenance template is going to lead to (relatively) quick action by other editors. This is false. For example, the category https://en.wikipedia.org/wiki/Category:Articles_lacking_sources (generated by maintenance templates) has 186,000 articles in it. There are several hundred thousand articles in the https://en.wikipedia.org/wiki/Category:Articles_needing_additional_references category, and many articles that have that template were marked as such in 2006.

In other words, the value of adding a maintenance template that asks other editors to improve an article is somewhere between very small and zero. If the Growth Team succeeds in teaching lots of editors how to place these templates, they will have contributed very little to the project. And, in fact, editors who spend a lot of time placing these templates could, in a more perfect world, be actually improving Wikipedia articles, instead.

MMiller (WMF) (talkcontribs)

Thanks for checking out the project pages and for your thorough comments, @John Broughton! I've learned a lot already from your input. I wanted to answer this one first before getting into the ones specifically about "structured tasks".

First, I just want to make sure it was clear that with newcomer tasks (which has been live on several wikis since November), we are not asking newcomers to place maintenance templates on articles -- rather, we are drawing on the existing maintenance templates to surface articles needing attention to newcomers. So hopefully this feature is a force for drawing down the backlog of maintenance templates, as opposed to increasing it. Indeed, I think a great potential outcome would be if enough newcomers were working through maintenance templates that it did make sense for more to be added by other users, starting a virtuous cycle.

One of the biggest problems with using maintenance templates for this project, though, is how open-ended they are -- we've seen newcomers who want to know which words should be links, or which sentences should be copyedited. That's why we're now talking about structured tasks on the other project page.

Another big problem with maintenance templates is removing them after the work is completed. The issue is that if a newcomer makes edits on an article after being prompted by a maintenance template, they probably don't yet have the wiki skills to understand templates and how to remove them. They also may not have the judgment necessary to tell if the template's need is entirely, or only partially, resolved. We don't yet have a solution for this -- perhaps we could encourage patrollers to look out for edits via this feature, and take a look at whether the template should be removed? Can you think of anything that would help here? Thank you!

Sundar (talkcontribs)

@MMiller (WMF), I'm looking at this from the point of view of Tamil Wikipedia. I have a similar concern as @Izno. Many tasks like adding references or even illustrations from the commons require a familiarity with Wiki editing as well as policies sometimes, which is hard to expect in newcomers. Is the plan to guide them through the entire process? If not, it's better to stick with simpler tasks, I think. -- ~~~~

Trizek (WMF) (talkcontribs)

@Sundar, we have set difficulty levels for each task we cover (adding images is not included).

Task Difficulty level
Copyedit article Easy
Add Links Easy
Update article Medium
Add References Medium
Expand article Hard

This way, users aren't encouraged to take more advanced tasks. Sure they can start with an hard task if they are fearless, but that's at their own risks.

Each task we cover has guidance. When one selects an article with a given task, they receive specific guidance on how to achieve this task. This covers editing basics; going deeper into policies is something we expect users to discover as time goes by, or by interacting with other users (especially their mentor).

Hope this helps! :)

Sundar (talkcontribs)
John Broughton (talkcontribs)

(1) The word "copyedit" may not mean what you think it does. Per https://en.wikipedia.org/wiki/Copy_editing , it "encompasses any or all of the tasks along a continuum from simple mechanical corrections (mechanical editing) through sentence-level interventions (line, or stylistic, editing) to substantial remedial work on literary style and clarity, disorganized passages, baggy prose, muddled tables and figures, and the like." In other words, at minimum one should distinguish between the extremes of grammatical corrections and rewording of sentences, and reorganizing and revising an article, both of which fall under the label of "copyediting".

(2) There are two different types of links, external (rarely used in the English Wikipedia) and wikilinks (internal). It might be helpful to treat the two as separate things.

(3) Adding a citation using Citoid isn't particularly difficult.

Reply to "Use of maintenance templates"

SuggestBot and Newcomer tasks

14
Iniquity (talkcontribs)

I correctly understand that this is an analogue of the en:User:SuggestBot but only for beginners? :)

MMiller (WMF) (talkcontribs)

Hi @Iniquity -- thank you for getting in touch! It is true that our work is inspired by SuggestBot -- in fact, one of the maintainers of SuggestBot is a member of the Growth team: @MWang (WMF). The most important thing we learned from SuggestBot is that suggestions that match the interests of a user are more likely to get edited by them (per this paper). A big difference between Newcomer Tasks and SuggestBot is that Newcomer Tasks is available for users to browse through, whereas SuggestBot pushes suggestions to the user.

Regarding your question about it being "only for beginners" -- our team focuses on beginners, but there's no reason that this feature, which is essentially a feed of editing tasks that need doing, couldn't be used by experienced editors, too. One day, we may be able to proactively expand it for those users, but in the meantime, any user (in the wikis that have the feature set) can turn it on in their preferences.

Are you a user of SuggestBot? Do you think we're heading in the right direction?

Iniquity (talkcontribs)

> but in the meantime, any user (in the wikis that have the feature set) can turn it on in their preferences.

@MMiller (WMF) where? :)

Iniquity (talkcontribs)

Hello, @MMiller (WMF)! Thanks for the detailed answer. I did not know that Nettrom is one of the Grown team. This is cool :)

> A big difference between Newcomer Tasks and SuggestBot is that Newcomer Tasks is available for users to browse through, whereas SuggestBot pushes suggestions to the user.

I'm not quite sure, but the bot seems to have such a function: w:Wikipedia:Community_portal/Opentask.

> Are you a user of SuggestBot? Do you think we're heading in the right direction?

No, I don't use the bot, as I solve other problems. But I brought open task to Russian Wikipedia. And yes, it seems to me that you are on the right direction, this is a very cool thing that allows you to gently guide participants to improve Wikipedia. And for beginners, it helps to understand Wikipedia, since it is very difficult to know where to start your contribution. Keep it going! :)

MMiller (WMF) (talkcontribs)

@Iniquity -- we are actually looking for more wikis that want to try the Growth features. Do you think there would be interest from Russian Wikipedia? If so, our team's community relations specialist, @Trizek (WMF), can help start a discussion about it.

Iniquity (talkcontribs)

@MMiller (WMF), Yes, I think it will be interesting. I'm generally surprised that you work with so few projects.

By the way, I immediately want to suggest improving the documentation, and add a description of the project with a screenshot in the first paragraph. Otherwise, you can understand what the main projects are about, only at the end of the page:

MMiller (WMF) (talkcontribs)

@Iniquity -- I went through and made sure all the pages you listed have up-to-date screenshots. Thanks for pointing this out!

Trizek (WMF) (talkcontribs)

If you have any questions about the deployment of Growth team features on Russian Wikipedia, let me know!

We have a page where all work needed is listed.

Iniquity (talkcontribs)

Well, thanks, then I'll start the discussion in the community.

Iniquity (talkcontribs)
Trizek (WMF) (talkcontribs)

Great!

Have you created a Phabricator task? You don't really need one for now, but it will be mandatory for the deployment. Let me know if you need assistance. :)

Iniquity (talkcontribs)

I just created it, I will supplement it with information later :) phab:T257490.

Trizek (WMF) (talkcontribs)

Yay! Great!

Out of curiosity, how have you heard about the Growth features?

Iniquity (talkcontribs)

On the Phabricator, I noticed activity in the tasks that interest me :)

Reply to "SuggestBot and Newcomer tasks"

UX feedback to the version 1.2 prototypes

5
Thiemo Kreuz (WMDE) (talkcontribs)

I was made aware of what's called "version 1.2" here and started playing around with the two prototypes. I would love to give some feedback. Overall, I think the prototypes are very well designed. All guidance, what to do where, when, and how, all this is very well picked. I'm looking forward to see how this performs! However, I might have a few nitpicks. Please forgive me if I'm poking at details that are specific to the prototype and not meant to be like this in the later product.

  • There is the sentence "Help make English Wikipedia better for its ~8B readers each month" at the bottom of the list of suggested edits. Not only is this corporate speech I personally do not like. It's misleading. The edits we ask these newcomers to do are not going to reach "~8B readers each month". It's not fair to suggest this.
  • For some reason the cards in the "suggested edits" list do have an ✕ button in the upper right corner. I believe this is a mistake.
  • I love that the cards resemble how PagePreviews already look like.
  • Having an actual page view count is a superb idea. However, I wonder why you decided to use a "60 days" period? I find this surprising. In my experience it's more common to talk about 30 days periods, or a year.
  • There is a little sequence of 3 "quick start tips". These panels advance automatically after (I believe) 10 seconds. I find this quite distracting. It's the largest animated element on the page, way larger than the flashing dot on the edit button. Chances are high it advances either to early or to late. I'm just trying to read the text – and get interrupted. I'm just trying to find a button to advance to the next tip – and get interrupted.
  • It's not obvious the 3 little numbers are meant to be buttons. Later, there is another UI element that looks like "← 1 / 5 →". I feel this would not only fit better, it would also help reducing the number of different UI elements. There is quite a lot going on in these prototypes.
  • There is one detail in the "← 1 / 5 →" UI I find distracting: When I click, the button I just clicked scrolls away along with the content, and another pair of buttons scrolls into view. Not only is this conceptually confusing. It should behave like one pair of buttons. The channel buttons on my TV's remote also don't scroll away when I switch channels. The current animation also makes it impossible to fast-forward.
  • On mobile, there is a screen with the sentence "Ready? Click the edit pencil icon to start" at the very bottom. But since this is mobile, the edit UI is not visible the same time. What's visible is this icon, which also shows an "edit pencil", but can not be clicked. I guess the sentence after "Ready?" needs to be rephrase on mobile, or the icon be changed or removed.

I hope this helps.

RHo (WMF) (talkcontribs)

Thanks for taking time to review and leave comments on the prototypes @Thiemo Kreuz (WMDE). Apologies it has taken so long to reply, but please see my responses below.

  • There is the sentence "Help make English Wikipedia better for its ~8B readers each month" at the bottom of the list of suggested edits. Not only is this corporate speech I personally do not like. It's misleading. The edits we ask these newcomers to do are not going to reach "~8B readers each month". It's not fair to suggest this.
    • We wanted this to express the sentiment to users that every small improvement helps to make their Wikipedia language better. I understand this may come across slightly as pandering to commercial appeal, but we do use real page view counts (with rounding) for the specific projects so as not to mislead with enwiki numbers. So for example, on cswiki right now, it shows the number as 1M daily users. Also the period was changed to daily due to the pageview extension not supporting counts of monthly or hourly. Here's the phab task detailing how we included the figures if you'd like to know more: https://phabricator.wikimedia.org/T236050
  • For some reason the cards in the "suggested edits" list do have an ✕ button in the upper right corner. I believe this is a mistake.
    • Ah yes, thanks for noticing. The idea for the ✕ button is to allow users to remove suggestions they don't like, but we are not yet doing this on Suggested edits right now.
  • I love that the cards resemble how PagePreviews already look like.
    • Thanks :D
  • Having an actual page view count is a superb idea. However, I wonder why you decided to use a "60 days" period? I find this surprising. In my experience it's more common to talk about 30 days periods, or a year.
    • Agree and I've filed this task T248636 to amend the period from 60 to 30 days.
  • There is a little sequence of 3 "quick start tips". These panels advance automatically after (I believe) 10 seconds. I find this quite distracting. It's the largest animated element on the page, way larger than the flashing dot on the edit button. Chances are high it advances either to early or to late. I'm just trying to read the text – and get interrupted. I'm just trying to find a button to advance to the next tip – and get interrupted.
    • This may be a limitation of the prototype as I think the actual auto-advance behaviour designed addresses your concerns. The intention (detailed in T244541) is that the tips auto-advance every five seconds, but only until the user interacts with the panel in some way. Once the user interacts with the panel, the tips stay on whichever one they were on when the user interacted.
  • It's not obvious the 3 little numbers are meant to be buttons. Later, there is another UI element that looks like "← 1 / 5 →". I feel this would not only fit better, it would also help reducing the number of different UI elements. There is quite a lot going on in these prototypes.
    • We decided to go with numbered tabs in the end instead of previous/back arrows mainly as the hypothesis is that people can navigate faster across the different tips without having to tap prev/next multiple times. It is also a visual signal that there are only a limited number of tips so as to not overwhelm users with too much detail.
  • On mobile, there is a screen with the sentence "Ready? Click the edit pencil icon to start" at the very bottom. But since this is mobile, the edit UI is not visible the same time. What's visible is this icon, which also shows an "edit pencil", but can not be clicked. I guess the sentence after "Ready?" needs to be rephrase on mobile, or the icon be changed or removed.
    • Yes, the mobile copy is different and asks the users to tap on the edit pencil instead.

Thank you again for taking time to give feedback! And please consider subscribing to our team's newsletter to keep updated on when we work on other new experimental features, including the release of the first version of this guidance panel.

Thiemo Kreuz (WMDE) (talkcontribs)

Thanks a lot for the detailed response! This sounds really good. Very much appreciated! However, I do have a few minor points I would like to bring up again:

  • […] every small improvement helps to make their Wikipedia language better.
    Than why not just say that? My point was not how exact the number is. Every wording that uses accumulated page impressions of thousands of pages to justify an edit on a single page is misleading. It's not fair to suggest that the edit the user is going to make will reach thousands of users.
  • We decided to go with numbered tabs […] hypothesis is that people can navigate faster across the different tips […]
    How is this relevant? All I see are numbers. I don't know what these numbered tabs contain. How is it relevant to be able to quickly navigate to a specific number?
RHo (WMF) (talkcontribs)

Hi again! Let me try to address your additional points as best as I can.

  • Than why not just say that? My point was not how exact the number is. Every wording that uses accumulated page impressions of thousands of pages to justify an edit on a single page is misleading. It's not fair to suggest that the edit the user is going to make will reach thousands of users.
    • It sounds like your objection is this number misleads users to thinking their single edit will be seen at the magnitude of the project level views – do I understand that correctly? If so, I want to stress that is really not the intention. This is why we are showing the page views on each suggested edit article (see example at F31736797), and also showing them the views on the any article page with their contributions after they've contributed (see example at F31736801).
    • As for why include the project-level views in that sentence at all? Besides it giving users an impression of the overall audience size for each project; including a specific number in my opinion gives more resonance to the generic sentiment of "every little bit counts". That said, we could consider changing this in future to another number such as number of articles on the wiki (similar to the portal page). This would be a product consideration for @MMiller_(WMF) to weigh in on.
  • How is this relevant? All I see are numbers. I don't know what these numbered tabs contain. How is it relevant to be able to quickly navigate to a specific number?
    • There are two main scenarios that this design is meant to help with users more efficiently navigate across tips. The first is when a user has read through some tips, say 1-5 of 7 tips. Using these tabs, they can then easily go back to tip 1 without having to tap a previous arrow to go back through 4,3, and 2. The second scenario is if users do not touch the panel but see the auto-advancing tips. Here, having the tabs change to active state helps draw user attention to the different tips being shown, and again allows the user who has been auto-advanced to tip #5 (perhaps they had not noticed the panel until then) to quickly go back to review the tips from #1 in one tap. While I hope this helps explain the decision to go with tabs over arrows in this first iteration of guidance, I want to stress that we will keep your points in mind when we review user feedback on both the auto-advance behaviour and tabs, in case either are a source of annoyance or confusion.
MMiller (WMF) (talkcontribs)

Thank you so much for these detailed thoughts, @Thiemo Kreuz (WMDE). They are coming at just the right time, because our designer, @RHo (WMF), is in the middle of finalizing this work. We're going into a week of intensive meetings, and she'll get back to you after that.

Reply to "UX feedback to the version 1.2 prototypes"
Misibacsi (talkcontribs)

It is a big mistake to expect newcomers will edit as experienced editors, when the newcomers know nothing about creating a new WP-article.

I suggest encouriging them to correct small mistakes, typos and such in existing articles to gain experience first, and much-much later they will start a new article by themselves.

Maybe also would be good if they would point to mistakes in articles, or suggest corrections.

Many times we notice that they leave a message somewhere in Help forums with a suggestion about an article (which contains errors), but they do not know how to correct this and ask editors for help. Maybe this is also not an easy task for a newcomer.


Wargo (talkcontribs)

This is for newcomers to learn and make first steps to "edit as experienced editors". "Maybe this is also not an easy task for a newcomer" - so there is need for resources for them. This project can help.

Trizek (WMF) (talkcontribs)

We encourage newcomers to make small tasks. That's the entire principle of the newcomer tasks. Maybe we haven't explained it well.

Difficulty filters

Difficulty filters are selected by default for Easy tasks, and creating an article is locked (because too difficult for a first experience) until newcomers have tried to edit.

We also plan to use the help panel to explain what to do to achieve the suggested edit.

MMiller (WMF) (talkcontribs)

Thanks for explaining, @Trizek (WMF). @Misibacsi -- does this make more sense now? The project uses maintenance templates to surface articles that need copyediting, links, references, etc. Newcomers will be encouraged like "Just add one link to this article and save it!" In this way, we hope they learn to edit in small steps. Do you have additional ideas?

Misibacsi (talkcontribs)

This makes more sense. Thanks for the explanation.

Reply to "Big mistake"
Samat (talkcontribs)

Which part of the page is recommended to translate? The note at the bottom of the Summary section says, that "The sections below may be changed significantly in the coming weeks, are too technical or less relevant for the understanding of the project. We have decided not to have them translated.", but the whole User testing section is selected for translation at the bottom of the page.

Martin Urbanec (WMF) (talkcontribs)

Yes, it was included mainly to inform communities about the user testing results. However, you should feel free to translate it or leave it out - it's up to you.

Reply to "Localization"

Deploy Newcomer tasks and other growth features to Wikimedia Commons?

9
Ainz Ooal Gown (talkcontribs)

I think Newcomer tasks and other growth features would be helpful on Wikimedia Commons. Commons probably has the largest backlog of all Wikimedia sites. It would encourage newcomers to clean up file pages, vectorise existing raster images, perform cleanup on Files, some necessary cropping, and other maintenance tasks. Before I propose this to Wikimedia Commons Village pump, any thoughts on the matter?

Martin Urbanec (WMF) (talkcontribs)
Ainz Ooal Gown (talkcontribs)

I embarrassed to say that I hadn't read it then. But I have now and it looks like I should first ask this on Talk:Growth. Thanks for showing me the correct procedure!

Martin Urbanec (WMF) (talkcontribs)

You're welcome. Please note that newcomer tasks aren't yet developed, and the Growth team probably wouldn't be confident to deploy them elsewhere for some time. Thanks for your interest in the features!

Trizek (WMF) (talkcontribs)

A quick side note: the current prototypes are designed for Wikipedias, first. It may be a bit difficult to have the current prototypes working on Commons, but who knows! :)

Ainz Ooal Gown (talkcontribs)

Can prototypes be designed for Commons? If so, Commons can be the testing ground (after a community discussion of course) for these unreleased features until they are implemented. What do you think?

Trizek (WMF) (talkcontribs)

They can't, for now.

The Growth team's objective is "to address this problem through software changes that help retain new contributors in mid-size Wikimedia projects, starting with Wikipedias". It is possible for other wikis to get the feature, but "as they are".

But the different features may be useful as they are:

  • the welcome survey may help the community to know what are newcomers' goals
  • the help panel can help any user to have access to the most important help pages when they edit an image, and post messages to an help desk
  • the homepage can gather useful informations, like newcomers impact and a direct access to a mentor.

I'm not active enough on Commons to know how to articulate these features to this wiki.

Ainz Ooal Gown (talkcontribs)

Yes, I think the features you mentioned above can be customized without making extra changes. So can I ask the Commons community for their approval for adding these basic Growth features? A discussion there will sort out all pros and cons and what features can be implemented.

Trizek (WMF) (talkcontribs)

You can. Please share the link! :)

Any Wikimedia projects can start this process. However, for Commons, this wiki would get the features as they are, all of them, and the Growth team will not have time to prioritize improvements specific to those wikis.

This, plus some other useful information are listed on the recommendation page. You should read it first, if not already done.

Reply to "Deploy Newcomer tasks and other growth features to Wikimedia Commons?"
JAn Dudík (talkcontribs)

I am not sure, if this is good task. There are articles that have images in some language Wikipedias but not in others. Typical example: article about some music album, newbie looks to en.wikipedia and "voila, there is cover image, lets add it to my wiki's article".

But this image is not on Commons. So part of newbies give it up. But second part will try to upload image to Commons or to home wiki, where will be problem because of en.wiki's fair use.

If there is item with commons category and this task will be active only for these articles, it's better, but also here are many categories without images (e.g. author with book scan in his category).

Sadads (talkcontribs)

+1 Also deducing this from "Depicts" statements on Wikidata is super useful.

MMiller (WMF) (talkcontribs)

Thanks for reading the newsletter and posting your opinions, @JAn Dudík and @Sadads! That's a good point about fair use being different in different wikis. It sounds like you're saying that if such an activity were restricted only to images that are in Commons, then this is more likely to work well. That said, I also imagine there are cultural considerations. For instance, an article about "bread" in Czech Wikipedia might show a kind of Czech bread, but the article about "bread" in Indonesian Wikipedia might need an imagine of a kind of Indonesian bread.

The reason we thought of this task idea is because a lot of newcomers want to add images to Wikipedia articles and think that it will be an easy thing to do. We know that it is actually quite a complicated thing to do: you have to understand licensing, use the right templates, navigate to a completely different website (Commons), etc. So we are trying to think of an easy task that would help a newcomer learn how to add an image so that they will be more likely to succeed when trying to add their own image. Do you have any recommendations of how we could accomplish this?

JAn Dudík (talkcontribs)

Is possible to have list of articles, which

  • are connected to wikidata item
  • have commons sitelink or P373
  • have no image
  • commons category or its subcategories contains image files (.jpg, .gif,...)

When newbie wants to help with images, he should got gallery from this category.

I tried inserting image with VE for the first time - and I got gallery of possible images based on pagename, which often depicts completely different thing. So there is possibility that editor can add bad image (e.g. two villages with same name, one with images second without)

MMiller (WMF) (talkcontribs)

Thanks, @JAn Dudík. These are good ideas that we can hang on to for when we want to try this method!

Reply to "Add images from Commons"
Jc86035 (talkcontribs)

@MMiller (WMF): The page indicates that the software won't "get in the way of them accomplishing their goal". I wanted to raise a concern about this; I hope that's appropriate at this stage of development.

It's sometimes the case that newcomers are unaware that they shouldn't do what they want to do, and have to learn the hard way; I believe there has been research indicating that e.g. reverts have a significant impact on whether new editors are retained in the short term (example; DOI/full text). There is probably some noise from advertisers in the linked paper's dataset, but I think it should still be somewhat significant (I think there has been some related research on the topic but I can't find it).

Perhaps rather than not taking measures to prevent this sort of thing from happening, it would be better to somehow tell newcomers that there are certain things that they definitely shouldn't do (e.g. upload copyrighted media to Commons, add song lyrics, write articles about self) and perhaps what they should do instead. It might be possible that this results in unintended consequences (e.g. newcomers leave without doing anything, even though they would otherwise have decided to stay if they had had a negative experience), but I think it might be worthwhile to test whether displaying such advice and/or linking to policies/guidelines has an impact on editor retention. In any case, this would likely have a positive impact on the workload of experienced users.

Furthermore, if reverts in particular are likely to discourage users from continuing editing, perhaps the home page could reflect this by giving users advice after they get reverted (or some other pop-up could try to reassure the user after a revert, rather than putting this in the home page, but I guess that might be a little off-topic).

Martin Urbanec (WMF) (talkcontribs)

Thank you for your comment, @Jc86035. I'm pinging @Trizek (WMF), who is Community Relations Specialist and I think he'll be interested in your comment as well.

MMiller (WMF) (talkcontribs)

@Jc86035 -- thank you so much for reading over the project page and gathering your thoughts. It's definitely appropriate at this stage (and every stage) to raise concerns, so please keep it coming (and I hope others do, too.)

I think we're thinking along similar lines with respect to not wanting to "get in the way of them accomplishing their goal". The idea is that we know for a fact that many newcomers arrive with these difficult tasks in mind, such as creating a new article or adding a photo. Yes, some of those initiatives are self-promotional or otherwise inappropriate, but many of them aren't, and the smaller wikis definitely need that new content. So the question is, how can we help a newcomer who single-mindedly wants to write an article about something like their hometown to eventually be successful in it? Our current hypothesis is that we might find out from the newcomer via the welcome survey that they are trying to write a new article, and their homepage might convey something to them like, "If you're trying to write a new article, you should know that's one of the hardest things to do on Wikipedia. We recommend trying some easier, but relevant, tasks so you can learn to edit and have a better chance at success." And then we would want to recommend tasks that actually help them build the skills they need, such as adding a section to an existing article, or adding a citation.

What we would not want to do is recommend tasks that are irrelevant to their goal, such as translate an image caption. That would be "getting in their way". Does this make sense? What do you think? It would also be interesting to hear from you what kind of tasks might be most relevant and nurturing for newcomers to do.

Jc86035 (talkcontribs)

I think that's probably a sensible way to go about it (and it definitely makes sense not to pressure users into doing things that they wouldn't want to do). I'm not sure what sort of tasks would be appropriate, and users with more experience assisting new editors and patrolling recent changes might be better at answering that.

I think I would probably phrase a warning message more like "there are a lot of things you need to take into consideration" rather than "this is really difficult"; partly to avoid being overly discouraging, and partly since it might not be very difficult to create a given article, at least with the minimum detail needed to avoid the article's deletion. (For example, someone's hometown would probably be inherently notable on the English Wikipedia due to being a legally-recognized populated place, so it would be relatively easy to find one or two sources and create that article.)

Reply to "Specific goals"
There are no older topics
Return to "Growth/Personalized first day/Newcomer tasks" page.