Talk:Growth

Jump to navigation Jump to search

About this board

Discussion related to the old Growth team is archived at Talk:Growth/Growth 2014.

Keeping in touch with projects

12
Ottawahitech (talkcontribs)

I see this:

  • We keep in close communication with the communities our team affects, so that our work remains grounded in reality.

and am just curious how one can be in touch with, say, Korean wikipedia community


MMiller (WMF) (talkcontribs)

Hi @Ottawahitech -- thank you for your question. There are several ways that we keep in close communication with communities:

  • We have four "target" wikis, which are the wikis to which we first deploy features to try them out. In each of those target wikis, we have a part-time ambassador drawn from the experienced editor community. We meet weekly with the ambassadors, and they are able to communicate to their communities about our work in the local language, and tell our team about the opinions and preferences of their communities.
  • We distribute a regular newsletter that gets posted to the talk pages of anyone who is interested. Those newsletters are translated into many languages. You can view past newsletters and sign up to receive them here.
  • We post weekly short updates on this page.
  • Community members can also follow along on our work in Phabricator. For instance, on this Phabricator task where we are working on "guidance" for newcomer tasks, our current project.

Does this answer your question?

Ottawahitech (talkcontribs)

Sure is nice to get a reply so quickly!


i guess what i am mostly curious about is how to communicate with people who speak a different language such as Korean. I know one can use google translate, but i find it very time consuming. Thanks

MMiller (WMF) (talkcontribs)

@Ottawahitech -- our approach is to work with people who are multilingual. Our ambassadors, for instance, speak English and their native language (and others!), and so they are able to talk with the Growth team in English and with their communities in the local language. They also use these skills to translate newsletters and other communications. You may be able to find people who speak multiple languages by using categories. For instance, this page lists users on mediawiki.org who speak certain languages. Working with multilingual people solves most of our issues, but we also do use Google Translate from time to time, which helps us get a sense of a local conversation.

Ottawahitech (talkcontribs)

<grin>Wow a second response in a few minutes is a first for me, i think. </grin>

i guess i am kind of wasting everyones time by posting here without organizing my thoughts. What i was getting at was the general difficulty of communicating with others who dont use our language. The reason i mentioned Korean was because i recently participated in a discussion proposing the deletion of a Korean wmf project . The discussion is in english.


Ottawahitech (talkcontribs)

Oops forgot tomention, i must logoff now

Trizek (WMF) (talkcontribs)

Unfortunately, not all projects have an ambassador to do the translation work. And English is the common language over the Wikimedia movement.

We are always looking for people who speak multiple languages to facilitate conversations.

Ottawahitech (talkcontribs)
Trizek (WMF) (talkcontribs)

Other compagnies provide translation engines. That's a first tool to use when you are facing a text you don't understand. Have a magic button that roughly translate a text directly when you are reading the wikis would be a nice technical wish.

Until then, we will have to rely on volunteer translators.

Ottawahitech (talkcontribs)

Thanks again Trizek (WMF) ,

Is there a list somewhere of translation engines provided by other (free/ ad supprted) companies? I find google translate very cumbersome.


Thanks in advance,

Trizek (WMF) (talkcontribs)

I would say "on Wikipedia". :)

I use google Translate, because of the number of languages covered. I'm more and more moving to https://www.deepl.com/translator; still proprietary, but less Google, fastest and more precise (at least on the EN <-> FR translations I use).

Ottawahitech (talkcontribs)

thanks for the link I will try it out when I get a chance. I just hope it does not collapse when the wiki-herds discover it :-)

Reply to "Keeping in touch with projects"
Alsee (talkcontribs)

I am looking for information on how the team plans to deal with the fact that we have dual editors. This includes, but is not limited to, things such as Newcomer tasks.

Does the team intend to design in an editor-agnostic fashion? Do you intend to funnel users into the Primary editor? The community may reject or disable a product if it attempts to funnel new users into the Secondary editor.

MMiller (WMF) (talkcontribs)

Hi @Alsee -- thanks for looking in detail at our projects and thinking ahead. You're asking an important question that the team is actually starting to discuss. So far, the features that we've built have been editor-agnostic. Specifically, the help panel opens no matter what editor the user chooses; and newcomer tasks lets the user use whichever editor they choose (for wikis that have two edit buttons), or whichever editor is the wiki's default (for wikis that have one edit button). And so the features fall back on the user's or community's choices around editors.

The reason your question is relevant now is because one of the things we're thinking about for newcomer tasks is guidance -- using the help panel to explain to newcomers how to complete the task. The guidance in the panel has to be pursuant to the editor the user is in, of course. So we're looking at what the default editor is on the Wikipedias we're working with (Arabic, Czech, Korean, and Vietnamese), and talking about what preferences those communities have for the editor that newcomers use (in those languages, we have dedicated community contact points that we call "ambassadors"). Interestingly, the different communities that we're working with think about the editors in different ways, which we're learning about.

I'd like to get back to you in the next couple weeks with some more details as we get farther along in design guidance. How does that sound?

Alsee (talkcontribs)

Thanks. The definition of which editor is primary/default has been a recurring point of conflict, so I was a little jumpy when mention of guidance for how to add links appeared to imply or assume the minority editor.

MMiller (WMF) (talkcontribs)

Hi @Alsee -- I’m getting back to you with some more information and next steps around guidance.  We have talked to our community contacts in the four Wikipedias to which we have deployed newcomers tasks (Arabic, Korean, Czech, Vietnamese).  Their recommendation for their own wikis has been to encourage newcomers to use visual editor when doing suggested edits through this feature’s workflow.  Specifically, what this will mean in those four wikis is:

  • In wikis that only have one edit tab, and on mobile devices, users in the newcomers tasks workflow who click edit will see the visual editor.  This is already the default behavior in some wikis. The users will be able to switch to the source editor afterward if they choose.
  • In wikis that have two edit tabs (one for the visual editor and one for the source editor), there will be a blue dot on the visual editor tab that nudges the user to choose the visual editor.  They will still be able to choose the source editor instead, if they wish.
  • Given the two points above, the written guidance that the newcomer sees will explain how to complete the editing tasks via the visual editor.

You made a good point that other communities may have different preferences around which editor the newcomers should be using.  Our plan for that is to build the software so that communities we work with in the future can opt to prefer the source editor for newcomers -- by including guidance around wikitext instead of VE, and by nudging users toward the source editor instead of toward VE.

I’m hoping that this plan respects the interests of communities, and that we can keep an eye on results to make sure that good edits are being made.  Please leave any thoughts you might have.

Alsee (talkcontribs)

@MMiller (WMF) thanks for getting back to me.

Single Edit Tab: I am painfully aware of the situation. I had to escalate this exact issue to the Executive Director. She had to summon the Product Manger to answer me on it.

Six months before the product was even announced, I asked the manager how he was going to handle the question of default editor. He gave me explicit assurance that he would not deploy the product with a VisualEditor default without asking the community first. Six months later it was deployed to several wikis. It was set to VE default. That nearly provoked another Superprotect-level crisis. The largest of affected communities wrote hacks for the sitewide javascript to overrule/override the deployment. The manager eventually relented and reversed it on three wikis. The other affected wikis were smaller. They were likely unaware of the problem, and if they were aware they likely felt unable to battle the Foundation about it. I let the Single Edit Tab issue slide, as the conflict effectively terminated the project. It looks like I'm going to have to return to the issue and get the Single Edit Tab default fixed globally.

It's generally not acknowledged within the WMF, but the data collected by the MWF shows that VE has a negative impact.

Could you provide me with links to the ArabicWiki, KoreanWiki, CzechWiki, and VietnameseWiki discussions deciding to go with VE? I can use machine translation. I'd like to see whether it was a unilateral decision by your contacts, or whether there was a community consensus. If it was a community consensus, I might try to reach out and provide those communities with the data that the Foundation has gathered on VE.

MMiller (WMF) (talkcontribs)

Hi @Alsee — I first want to make sure the scope of what we’re working on is clear. The Growth team is talking just about the newcomer tasks workflow, which won’t affect the editor seen by newcomers who are not participating in the workflow. This work also won’t alter the experience of non-newcomers.

With respect to your question, we did not go through a community discussion process around the decision to nudge newcomers in the suggested edits workflow toward VE — rather, we relied on our ambassadors in those wikis to represent what they think would work best for their communities. Working this way helps us both iterate quickly while also taking community thoughts into account. In this case, our ambassadors have experience mentoring and teaching newcomers to edit, and think that the visual editor will help those users make their first edits and stick around the wiki, so that one day they can move on to more advanced edits. I think they have built up good trust and judgment with their communities by communicating about Growth team work through newsletters and on-wiki conversations in their native languages, and then taking community concerns to our team so that we can adjust.

In that vein, I think it’s a good idea to make sure that communities are aware of these specific plans around VE, and so we’ll make sure to include this aspect of the newcomer tasks workflow in our team’s next newsletter, so that communities can think about and react to it.

Alsee (talkcontribs)

@MMiller (WMF) yes, I understand.

The tension is the pattern of the Foundation pushing the secondary editor as the default. Wikitext is de facto the primary editor, used by the large majority of editors for the large majority of edits. Within the Foundation there is a sincere and widespread belief that VE is beneficial. However out in actual use on wikis the adoption rate for VE have been dismal, there is broad experience that VE is a poor tool for the job, and there is a strong view by many that it's harmful to push new users into VE by default.

Ideally we need a global answer to avoid rehashing the issue on a wiki-by-wiki and product-by-product basis. However I do not anticipate reaching to that point soon enough to apply here.


I think it’s a good idea to make sure that communities are aware of these specific plans around VE, and so we’ll make sure to include this aspect of the newcomer tasks workflow in our team’s next newsletter, so that communities can think about and react to it.

While that would be an improvement, it is difficult enough for large communities to oppose WMF announcements. Smaller wikis rarely speak up because of the language barrier, and because they may feel powerless to challenge the WMF.

My view on software deployment is that the Foundation should either:

  • make a good faith assumption that silent wikis probably agree with the larger wikis that have spoken up; or
  • ask them.

Would you be willing to post the question on their central management page? (Village Pump or equivalent.) It's also good practice to make a good faith effort to help people make an informed decision. I could dig up the link for the VE-favorable usertesting the Foundation did with non-editor lab test subjects. There's this graph showing VE has half the interface retention rate as the wikitext editor - for the VE interface users quickly either quit editing completely or they switch to the wikitext interface. There's also a new A/B test on the effect a mobile VE default. The team hasn't made the results public yet but a sub-task makes it clear the results were bad for VE.

MMiller (WMF) (talkcontribs)

Hi @Alsee -- I agree that the story of where and how VE is valuable for users is certainly nuanced, and I don't have the expertise to be able to dig into the data here. I do know that our ambassadors, who are very active in their communities, recommend that we use VE for this workflow and believe that decision aligns with their communities' preferences. We’ve been working with these ambassadors on Growth projects for over a year, and we’re going to continue to trust them to represent their communities as we do our work, and keep communities informed so that they can speak up when they have concerns.  We're not going to post specifically about this issue on those wikis, because our ambassadors don't believe it will be a contentious issue.

As we continue to expand to more wikis, we will likewise make sure that those communities are informed about the feature set before we deploy, including this part about encouraging newcomers to use VE in newcomer tasks.  Our current plan is to inform about this decision in our upcoming newsletter, which goes to many community members and management pages on our target wikis.

Alsee (talkcontribs)

For a moment there I thought things were going well. Not only did you decline the simple request to ask those communities, you escalated declaring you've decided you're going to try to shove out a VE-default on this globally.

If you are unwilling to ask the community, I'll do it. I'll start with English Wikipedia - it represents nearly half of our global community. If necessary I'll organize additional wikis into an effective Global Community Consensus.

I find it painful and baffling that the Foundation keep insisting on making this into a battle. It just contributes to the already-substantial community distrust or even hostility against the Foundation.

Reply to "Wikiext and Visual editors"
HLHJ (talkcontribs)

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)

Trizek (WMF) (talkcontribs)

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:

MMiller (WMF) (talkcontribs)

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."

HLHJ (talkcontribs)

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)

HLHJ (talkcontribs)
MMiller (WMF) (talkcontribs)

@HLHJ -- thanks for pointing it out! I put some thoughts there.

Reply to "Encourage the newcomers feedback"
Summary by Samat

The anchor template can solve the multi-language section linking.

Samat (talkcontribs)
Trizek (WMF) (talkcontribs)

Thank you for noticing it. I've changed it.

Samat (talkcontribs)
Trizek (WMF) (talkcontribs)
Samat (talkcontribs)
Trizek (WMF) (talkcontribs)

It may take a couple of dummy edits to have everything being fixed. Thank you for your help!

Newcomer homepage on fr_wikipedia

6
AirSThib (talkcontribs)
Trizek (WMF) (talkcontribs)

Thank you for this message, and happy to see you motivated.

I just replied on the Bistro about it. :) If you community is okay, please create the Phabricator task.

(Today, I learnt that "cordially" is an English word, thank you! 👍)

Nemo Le Poisson (talkcontribs)

@AirSThib C'est pas compliqué de se faire un compte Phabricator, il suffit d'aller sur ce lien, et tu peux te créer ton compte grâce à ton compte Wikimedia existant ! Si tu veux, je peux t'aider mais mon anglais à l'air moins bon que toi !

AirSThib (talkcontribs)

Oui je sais mais j'ai 13 ans donc je souhaite pas pour l'instant en créer un à cause de l'adresse mail. On ne serait pas obligé d'indiquer notre e-mail je l'aurais fait depuis longtemps !

Nemo Le Poisson (talkcontribs)
AirSThib (talkcontribs)

Oui.

Reply to "Newcomer homepage on fr_wikipedia"
Acamicamacaraca (talkcontribs)

Choosing a mentor: It may make sense to make it possible for a newcomer to select a mentor from the list of suggested mentors himself. I started enabling experiments on sr.wiki, and one user suggested this idea to me, so here's it.

Martin Urbanec (WMF) (talkcontribs)

Hi, I'm a Growth ambassador at Czech Wikipedia. Thanks for suggesting this feature! I'm currently working on a new feature that allows mentors to claim a newbie, if they know them off-wiki, for instance. See (draft) help page at Growth/Personalized first day/Newcomer homepage/How to claim a mentee. Maybe that's something you would like? Feel free to give comments on that!

I'm honestly not sure if displaying a list of usernames to the newbie is worth it? How would be a newbie supposed to thoughtfully choose their mentor? It would be nice if you could explain how would you like the newbies to use the proposed feature, so we can make a better image of it.

Trizek (WMF) (talkcontribs)

Hi, and thank you for this message, Acamicamacaraca!

I think that a newcomer can claim a mentor only after a few interactions with Wikipedia. When I work with newcomers as a volunteer on French Wikipedia, I very rarely have someone who asks for a specialist about a particular topic. Newcomers very often need help about basic things, like adding a source or an image, or understanding some rules. So I don't think that they need to pick a mentor from a list.

If they want to change their mentir, than can do so by simply agreeing with the new mentor who could claim the newcomer. :)

Acamicamacaraca (talkcontribs)

The idea was that e.g. the newcomer can choose the mentor himself based on his description. For example, if a newcomer wants to deal with football topics, he would prefer to choose a mentor who also deals with football topics instead of historical ones.

Reply to "New Feature"
156.213.191.123 (talkcontribs)

مرحباً اريد المشاركة في فريق النمو

Dyolf77 (WMF) (talkcontribs)

أهلا وسهلا ومرحبا، هل يمكننا أن نتعرف على اسم حسابك على ويكيبيديا؟ شكرا.

Reply to "مشاركة"
Jeblad (talkcontribs)

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.

MMiller (WMF) (talkcontribs)

Hi @Jeblad -- thank you for thinking about our work and for writing out these ideas. I'm sorry that it has taken a little while to get back to you. I have some notes and questions about each of your points:

  • Random award: our team has talked many times about how to use awards to help motivate newcomers. Some of our notes are here. There is definitely evidence that awards can work, such as this paper about an experiment in German Wikipedia. In that experiment, a random set of newcomers was given an award for completing their first edit. They were then listed in public as one of the recipients of the award. This increased their retention by 10%. It's notable that in the experiment, the award came from a group of people (a WikiProject), as opposed to from "the system". Our team wants to extend the impact module on the newcomer homepage to give users awards that make sense for them, and we know we'll have a lot of thinking to do with our communities to make sure the awards are appropriate and incentivize healthy behavior.
  • Activity feedback: I see this as related to the "awards" concept, because it's all about recognizing people for the work they have done. If you take a look at the homepage's impact module (shown in these designs), how good of a job do you think we're doing here? What should be different?
  • Ongoing work: this reminds me of conversations our team has around a concept we call "neighborhoods". We think that it would help newcomers for them to be able to clearly say that there is activity happening in the wiki, so that they can join in (we have some notes on that here). Right now, it's hard to see activity unless you go to Recent Changes. So we think newcomers could have some kind of "activity feed" on their homepage, that could be tailored to topics that they care about, e.g. "Music", "History", etc. But it sounds like you're also saying that recent edits could be clearly listed on a user page. That would fit in well with some of our ideas around a potential structured user profile (some notes on that here, and I've added your idea to the bottom).

How does this sound? What do you think?

Jeblad (talkcontribs)

Random award is a bit weird. You tend to be more enthusiastic over a random award when you expect none, compared to a situation where you expect the award and get none. Even if the overall level of awards are the same. If people are giving the award, and you are expecting an award, then it quickly turn into a grudge toward the users that did not give you the expected award. Either the award should be really unexpected, that is statistically random, or it should be deterministic. A deterministic award is an activity feedback. It should also be given by a non-human, so to avoid disgruntled users. In the mean two different users at the same level should be given the same amount of random award, even if they have been given different awards at any given moment.

Activity feedback is a deterministic awards. You should be able to expect an activity feedback, but a random award should be unexpected. All users doing the same amount of work should be given the same activity feedback. Call it “activity award” and “random award” if it is easier to understand.

Ongoing work is the users “own work”, and limited to the users present major work. It makes him focus on his own work, possibly triggering a higher completenessrate. You could create interest groups, by collecting over a group of users from the categories where the user are editing. Note the difference between the users own activity, users interests, and articles where there are activity. Some user editing a random article does not imply he has a profound interest in neither the article nor the category. Only after accumulating edits over some time you know the users actual interest. The users interest could be modelled as the categories from the articles where (s)he contributes, weighted by the amount of work invested in each article. The categories should probably be simplified somewhat. You can make a metric for group activity both from users contributions and from recent changes. It depends on the level of granularity you want.

I'm not sure about the present standing on paid editing (Gneezy U; Rustichini A; (2000) Pay enough or don’t pay at all. Quart.J. Econom. 115(3):791–810.) I tend to believe the communities have made up their mind on a fairly weak (or even non-factual) basis. That could have implications for what kind of awards that can be used, and it makes it virtually impossible to use the most effective means for content production – payment. It seems like Wikipedia has at the same standing on corporate contributions as Linux in in the late 90s.

Note that awards in a system like Wikipedia relates more to cultural capital than social capital. Facebook and Twitter are more about social capital. LinkedIn tend to be social capital, but with a twist on educational and commercial capital. This has impact on what kind of awards will be regarded as important, and what kind is simply fun.

Reply to "Tools"

NavWiki project space is in development on the Outreach wiki

2
Pine (talkcontribs)
MMiller (WMF) (talkcontribs)

Hi @Pine -- thanks for letting us know. I'll post a couple questions for you on Outreach.

Reply to "NavWiki project space is in development on the Outreach wiki"
Samat (talkcontribs)

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.

Samat (talkcontribs)

I realized, that it works as I wanted, as soon I change the surface language from English to X (Hungarian in this case). Sorry.

Trizek (WMF) (talkcontribs)

I havent found a nice way to add a direct link for translations. If you have an idea, I'm interested! :)

Reply to "Growth/Navbar"