I generally use the phone to talk to the organisers. You really need to know what they are
thinking about doing (or, worse still, have already advertised doing) in order to advise
them correctly. The things I strongly recommend are all about risk management. Events are
just full of “Wikipedia risk” (there’s normal event risk, but I’ll assume everyone knows
that).
If there are likely to be a lot of new people (almost always the case), you will have a
number of problems. First, try to get them to create accounts in advance because of the
restriction on new accounts from the same IP address in one day. However, a lot of people
won’t have created the user account beforehand (didn’t read that email, too busy, didn’t
know how) and half of the others who did will have forgotten their username and/or
password and need to do it again. So, in advance, get one of your more experienced users
to get themselves the account creator privilege to bypass this problem (it has saved the
situation for me a number of times). Other ways around it are to get people to sign up on
their phones (not using the wifi in the room but through their ISP).
If planning to create new articles (almost always the case), there can be problems with
notability and conflict-of-interest topics. Do not say to a room of newbies “write about
whatever you like” as it ends badly. It is generally better if the organisers draw up a
list of topics that are likely to be notable in the chosen topic space (ideally with two
citations to demonstrate notability) and ask the participants to pick one of those topics
rather than say “write about whatever you want”. Also newbies are very poor at finding
existing articles so they may write a 2nd article on the same topic (again, doesn’t end
well). In my experience, most newcomers go blank at the thought of picking their own
topic, which is then leads to picking some topic with which they have CoI or lacks
notability. I find newbies actually prefer to be given a topic (I often get them to draw
the topics from a lucky dip box sometimes interspersed with a few fun ones like “you win
a chocolate, draw again” just to lighten the mood).
If planning to create new articles and there are new (or newish) people, then remember
that the first new article is often an unpleasant experience, doubly so if they end up in
Article for Creation (a pit of doom from which few emerge alive as contributors). If I
have that situation (almost always the case), I will have created stubs in advance
(usually just 2 sentences and 2 citations for notability), so newer users don’t have to
create any article, just expand it. Is this a lot of work? Yes. Does it avoid problems?
Absolutely.
The other thing with freshly minted stubs is that they are not on anyone’s watchlist.
While alerting other editors via watchlist may bring helpful assistance, it more often
brings reverts, nasty talk page messages and other newbie-discouraging things. If you are
not creating new articles but expanding existing articles, I would suggest sticking with
smaller and less-read articles as this reduces the likelihood of active pagewatchers.
Also, it is easier for a newcomer to add content to an under-developed article than to a
better article article (there is just more scope). Remember, your participants want to be
able to go home and show the family a Wikipedia article and say “look, I added this!” so
it needs to survive long enough for bragging rights!
If the theme of the event is likely to involve Living People or medical topics, I am
tempted to say re-consider the event. Seriously, you have to hammer home the citation
requirements in these areas. Note that there are other WikiProjects whose standards are
very high but perhaps in different ways (what is or isn’t a reliable source etc). Try to
ensure you do have an experienced editor in that topic space at least available to give
advice in advance unless you want a session of revert pain.
You may also have paid editing if the people are employees/contracters/board members etc
of the organisation hosting/organising the event or if the themes for the content creation
relate to the organisation. Paid editing MUST be declared under the Terms of Service and
don’t make exceptions for “it’s the weekend” or “I’m on leave this week”. The easiest way
to disclose is to put it on their user page “I am an employee of Foo Inc”.
https://en.wikipedia.org/wiki/Wikipedia:Paid-contribution_disclosure
When in doubt (e.g. interns, volunteers and one contract finishing and another starting in
a week), I advise to err in favour of disclosing the relationship. This isn’t a pillar, a
policy, a guideline, or an essay or something for the community to decide. It’s the Terms
of Service for contributing laid down by WMF. Non-negotiable! If people do not like it
(and there will be some who won’t, mentioning privacy etc), they are free to leave.
I also have the CoI discussion. If people have drawn a topic that they might have CoI
with, they should redraw. Given the set of topics, the theme of the event, and any
organisation involved, you may have to explain the CoI line differently with some concrete
examples. With academics, I usually say no immediate colleagues in their own institution,
no collaborators at other institutions, not their own PhD supervisor/students. But to say
“no to anyone in your field” when the theme is the field makes it impossible to run the
event; this is why you have to understand the situation in advance to work out a
reasonable position on what it/isn’t CoI given the nature of the event.
Next is CopyVio. Many people think anything on the web is fair game (which is obviously
not the case) but even among people who do have a basic grasp of copyright, you get lines
like “my university won’t mind” (which is often quite true in practice, but if the webpage
doesn’t have a suitable license, sorry!). Similarly people in organisations like
historical societies view the collection of the society as communal property and happily
say it can be reused but in fact they have a bundle of material with no known providence
so you can’t even assess its likely copyright status. Ugh!
Latecomers. Yep, some people won’t arrive on time. The problem if they arrive late is that
they won’t have heard what you just said about Paid Editing, Conflict of Interest and
CopyVio. In an ideal universe, you have plenty of other volunteers to assist you with
getting the late comers up to speed. If you don’t have plenty of volunteers (almost always
the case), I don’t have a good solution for you (apart from having everything you’ve just
told everyone else written on a bit of paper to hand to them) and you should expect some
issues to arise from that as they won’t read it. I don’t know if it relates to some
inherent aspect of latecomers, but their subsequent editing is often more problematic than
those who arrive on time (whether it be dangerous over-enthusiasm “I’ll just delete all
this content and start again” or a complete lack of any observable IT skills “I can’t find
the letter Y on the keyboard”). All you can do is encourage the organisers to urge people
to arrive early to set up their account; you can’t turn away the latecomers (as much as I
would like to at times).
Next. Use the Visual Editor. No “ifs” and “buts”. If you have newbies, teach them the
Visual Editor. You will have to turn on the Visual Editor for them as it is not turned on
by default with new accounts (I have been told it is but I have run enough events to know
it isn’t!). Preferences > Editing > Editing mode: Show both tabs! (as beguiling as
some of the other options may seem, do not be tempted by them, it will lead to them being
“locked out” of the Visual Editor sooner or later – I don’t know if this is a bug or what,
but it happens). What, *you* don’t know how to use the Visual Editor? Well, I didn’t
either once upon a time and so I said “Right, from now on, I will only edit in the VE and
I will persist even though it is different to what I am used to and what my fingers are
“programmed” to do and a slightly different way of thinking about an article, and I will
do it until it is automatic because I can’t teach others if I am not fluent myself”. So I
forced myself to learn it and found that it is actually a much nicer tool to use (with the
exception of doing a lot of template work but even that is getting better). I now use VE
for most of my editing, switching only into source editor for heavy-duty template work, or
fixing broken syntax etc. I am not telling you to use the VE because I prefer it, I am
telling you to use it because people learn it and remember it 10 times more easily than
the source editor syntax. It really is a game-changer for bringing newbies on board.
Once you have the room off and running with their editing, keep stressing two messages.
One: add text with citations. Two: Save frequently. The first is obvious I hope. The
second is because your event is probably stressing the local WiFi and sooner or later some
hiccup leads to someone losing an hour’s work. Generally by the time they have screamed
for help, they’ve pressed random buttons and it’s too late to recover the situation. But
try to Ctrl-A Ctrl-C (or Apple equivalent) whatever’s in their text box if it’s still
on-screen and remember you may be able to get it by using the BACK button on the browser.
From that point, you have some chance of recovery (although you probably should do the
recovery).
Similarly if they get edit conflicts (usually some Manual of Style fanatic wanting to fix
the spacing or the length of a dash), take control and fix it for them. The event is not
the time to explain edit conflicts and what to do about them. This is another good reason
for working on articles with no pagewatchers. Note, event organisers are often not
familiar with edit conflicts so don’t let them ask people to all write on the same project
page with their user name and article. Get them to email it instead. This is something to
sort out in advance with them (they may be thinking that people can work in pairs on an
article or other bad ideas). This is why I say TALK to them rather than point them at some
documentation; you don’t realise just how little event organisers know until you talk to
them.
Again, in my copious spare time during the event (ha ha!) I try to send out the Welcome
messages to the new users and “thank” them for a couple of their more substantive edits.
All good life-affirming stuff to do. If I don’t get time during the event, I do it as soon
as possible after the event. Also, as soon as possible, I also do a check and tidyup of
the articles worked on to remove any really big problems. Again it helps ensure their work
survives for bragging right purposes.
Kerry
From: Cultural-Partners [mailto:cultural-partners-bounces@wikimedia.ch] On Behalf Of Alex
Stinson
Sent: Wednesday, 12 July 2017 6:34 AM
To: Wikimedia Chapters cultural partners coordination
<cultural-partners(a)wikimedia.ch>ch>; Wikimedia & GLAM collaboration [Public]
<glam(a)lists.wikimedia.org>rg>; North American Cultural Partnerships
<glam-us(a)lists.wikimedia.org>
Subject: [cultural-partners] What advice do you connect new editing event organizers
with?
Hi All,
I am hoping to add an Editing Events organizer training to the Programs and Events
Dashboard in the coming months. I know there is a lot of documentation for editathons out
there, including but not limited to what I have listed at:
<https://outreach.wikimedia.org/wiki/GLAM/Sharing_Knowledge#Editathons>
https://outreach.wikimedia.org/wiki/GLAM/Sharing_Knowledge#Editathons . What is your
favorite piece of documentation (any language) for new Editathon runners?
Cheers,
Alex
--
Alex Stinson
GLAM-Wiki Strategist
Wikimedia Foundation
Twitter:@glamwiki/@sadads
Learn more about how the communities behind Wikipedia, Wikidata and other Wikimedia
projects partner with cultural heritage organizations:
http://glamwiki.org