User:WereSpielChequers/Submissions/Edit Conflicts - our test of IT competence

Submission no. 3043 - TC

Title of the submission: Edit Conflicts - our test of IT competence

Type of submission - Lecture

Author of the submission: WereSpielChequers (talk)

Language of presentation: English

E-mail address: WereSpielChequersGmail.com

Username: WereSpielChequers (talk)

Country of origin: UK

Affiliation, if any (organisation, company etc.)

Personal homepage or blog

Abstract (up to 300 words to describe your proposal)

Wikipedia is famously the encyclopaedia that anyone can edit, and that millions have edited at least once. But very very few who make that first edit go on to become regular editors. Of course some of this is our long tail - we don't or shouldn't expect many of our editors to adopt editing as a major hobby. Most are likely to be readers who will just fix the odd error, and the better we get the fewer they'll find. But we have various barriers against people moving from their first edit to the 100th, and one of the oldest and crudest is the technical test of the edit conflict.

Talking to established Wikipedians there are many differences between us, many different wiki philosophies, a huge range of ages, in London a fairly even split between bearded and non bearded. But almost by definition we are internet users who have earned to handle edit conflicts on Wikipedia. Some use citation templates, some abhor twinkle some swear by AWB, some use Mac some Lynux and some Windows, but we all know how to handle edit conflicts. This reminds me of the WWII engineers who went to all the repair records looking at what parts of a particular aircraft design had been damaged, and then improved the protection of the bits that always came back intact and never needed repair. The logic being that the planes where that was damaged weren't making it home for repair. My assumption is that the editors who don't learn to handle or avoid edit conflicts are the ones who don't stay and become regulars.

What will attendees take away from this session?

Some thoughts for possible changes to the way we use edit conflicts to drive away new editors.

Some practical things we can do to reduce the risk of edit conflicts, and make them less upsetting to newbies.

Starting all new articles with ==References== at the end would end edit conflicts between categorisers and the newbies who create uncategorised articles. Conflicts that wielders of Hotcat et al will almost always be wining because of their speed. Something similar at the top would make template bombers less damaging as they wouldn't couldn't cause edit conflicts either.

Amending newbie advice by including something in welcome templates and the sign up process to the effect of "don't trust the software, save frequently and only edit one section at a time". and "when you get an edit conflict, open a new tab, edit the article in that tab and copy and paste your edit from the tab where you had an edit conflict".

Theme of presentation: WikiCulture & Community (with implications for Technology, Interface & Infrastructure)

For workshops and discussions, what level is the intended audience?

Length of session (if other than 25 minutes, specify how long): 25 minutes

Will you attend Wikimania if your submission is not accepted?: I hope so

Slides or further information (optional)

Special requests

Internet access would be helpful

Is this Submission a Draft or Final? {{Completed Submission}}

Interested attendees

If you are interested in attending this session, please sign with your username below. This will help reviewers to decide which sessions are of high interest. Sign with a hash and four tildes. (# ~~~~).

Amir É. Aharoni (talk) 09:56, 9 April 2017 (UTC)

Edit Conflicts - our test of IT competence Category:Lecture submissions