Editor retention/Essay by Gryllida

You may be looking for: Research:Editor retention.

(English) This is an essay. It expresses the opinions and ideas of some Wikimedians but may not have wide support. This is not policy on Meta, but it may be a policy or guideline on other Wikimedia projects. Feel free to update this page as needed, or use the discussion page to propose major changes.

Pre-contribution stage

A contribution was rejected...

• ...my article was deleted.
• ...my edit was reverted.
• ...I lack orientation [and am too lazy to edit, I want you to do it for me].

Caused by

• Excessive stratification of contributors into "reviewers"/"mentors" and newcomers. Newcomers should be assumed to have come to share knowledge — they are the very first asset of the wiki They should not be asked to wait for their contribution to be accepted. (Part of this is too much rewards of “patrolling” recent changes and new pages by Wikipedia contributors).
• Lack of reviewers participation in further expanding the article (if it's worth it) or providing topic-specific help (if it's not something they can write themselves about).
• Excessive use of templates at contributors’ talk pages, caused by the above — people routinely patrolling things without being interested in reaching a strong contact with the new article author through hard content work.
• Occasional usage of edit summaries to talk instead of talking at talk pages themselves.
• Subsequent not very human (or humane) interaction with newcomers.

I would like to stress that help with article creation may be desirable, but, instead of pleasing the people whose work gets "unfairly" deleted, I would put more effort into making it easier for people to gain orientation and only get help when they ask. The "assume good faith" and hand-walking becomes a trouble when too much effort is put into curating inherent spam at the cost of slowing the article creation process.

• Make deletion messages more readable. Tell people what to do! And do not use the notability concept which is a permanent useless label on the subject -- it doesn't tell what was lacking.
• A framework for semi-automated tools could unleash per-project potential of resolving common routine work.
• Encourage WikiProjects growth by sorting many new changes and new article helpers into topical teams. (Some would still remain to process uncategorized submissions.) Then they'll engage into expanding articles and providing verbose feedback more efficiently than those unfamiliar with the topic. :)

Current or past WMF Engineering projects on this topic:

• Draft review — while prevents contribution deletion, also makes getting a contribution accepted harder, especially anonymously. People have to register and wait for "review" even with perfectly valid intentions. This is a royal pain to the point of outright assuming bad faith.
• Page curation (a tool for new pages patrol) — inherently discriminates against unregistered contributors by showing their username and edit count in the list of new pages. Also is routine work which makes the new page patrollers more isolated from topics and from collaboration with contributors.
• Echo — a not very unhealthy project, although one of minor importance; it also nags quite a bit, even if I already read the relevant page or message. Seems to be a consequence of sidebars and jiggles making own contributions a bit too difficult to find (no user dashboard, like so, with such buttons as own contribs, own prefs, own watchlist — big fat buttons).

Contribution stage

A contribution was accepted, but ...

• ...it's hard to grasp how this works.
• ...I did something, but it looks messy.
• ...I did something, but it took too long time to understand.
• ...I did something, but I did it wrong and someone had to correct.

Cause: lack of documentation or lack of tools to do every small thing users may have trouble with, due to

• excessive focus on handling pre-contribution stage of editor retention;
• excessive desire to shove everything into extensions for the sake of proper code review and support;
• overcomplicated and weak sharing of code (weak modularity) of gadgets, one of the more editable means of enabling additional functionality by default;
• weak understanding and appreciation of the need for such tools.

Current WMF Engineering projects to this point:

• VisualEditor — a GUI editing tool without markup.
• Flow — a discussion page thingie (in embryonic design and features development stage).