A couple of points I forgot to mention.
It is a good idea to suggest that attendees have experience in word processing or
spreadsheets (e.g. Microsoft Word, Excel). I have had the experience with some older
people who perceive themselves to capable with IT because they can send and receive email
and lookup things in Google. And, for what they normally want to do, their skills are just
fine. But Wikipedia demands higher skills which most of us take for granted as “normal”.
Some examples of assumed knowledge:
* Using when you edit Wikipedia, you often have your edit session in one tab of
your browser and one or more other tabs open with the material you are about cite (or
maybe in a separate browser window if you have the screen real estate available) . Some
people do not understand about multiple tabs or multiple instances of the browser, nor how
you switch between them.
* Copy and paste. You and I probably just CTRL-C/V without a thought. Some people
not only do not know the keyboard accelerators nor the right-click menu way of doing
copy/paste, they just don’t understand what you even mean by copy and paste. They may not
understand about “selecting text” which is the first step for copying. Also worth noting,
some people do understand what copy and paste is, but only within the context of one
application or one document. They do not realise they can copy and paste between documents
or between different applications (but they usually think you are amazing when you show
them that they can do it!). As you can imagine, doing a citation is a very difficult if
you can’t copy and paste the title and the URL etc.
Tip: if you have to teach copy and paste to someone, teach them to select text right to
left (end to start) not left to right (start to end), for some reason I don’t understand
many people find this is easier and more accurate (not sure if it is something to do with
the hand or the brain). I was told this and I experimented and I think it is true (works
better for me anyway). It also has the practical benefit that if you overshoot you will
probably pick up an extra space at the front rather than a punctuation mark at the end and
generally the extra space is less harmful in the copy and paste than the extra
punctuation.
* URLs. Again, when we cite from a web page, we need a URL. Some people don’t know
what you mean by a URL. The event is not the time to explain it stands for Uniform
Resource Locator nor what on earth that means anyway. Try using the “web address” or “web
page address” (sometimes the issue is just vocabulary), sometimes the problem is more
conceptual. A lot of people get to web pages from bookmarks, search engine results or by
navigating along a known sequence of links; they do not realise there is a direct way of
addressing them. It seems some people have either never noticed the URL in the address bar
of their browser or decided it is of no relevance to them. Some browsers also hide parts
of the URL, e.g. http:// which doesn’t help people’s understanding of them and of course
some things displayed in your browser are not persistent web pages and the contents of the
address bar is not a true URL. The event is not the time to attempt to explain any of
this. Try to teach them the absolute minimum they need to do their current task (usually
constructing a citation) and plan to double-check their URLs later in case they didn’t get
it right. If people can’t distinguish between the URL and the name of the web page, use
the analogy of a library catalogue which tells you the name of the book and its location
on the shelf (a URL is the “shelf location” within the Internet).
If you have plenty of volunteers, it may be worthwhile allocating one to ongoing
handholding with a person who don’t understand stuff that we see as “basic IT skills”.
They will probably go very slowly and not achieve a lot in the event but at least if
someone helps them, they will get something small done and let them go home feeling good
about the experience. Be patient and try not to make them feel stupid or inadequate. There
are probably plenty of things they know how to do that we do not. They are at your event
in good faith.
And just before anyone accuses me of ageism, I should point out that I am a retired person
(so obviously well aware of ageism) and the people with these very low IT skills in my
sessions have always been older people. This is not to say every young person is great at
Wikipedia writing, but they generally do possess basic IT skills if they turn up at a
Wikipedia event.
While experience with using word processors and spreadsheets does not necessarily imply
that people will have the skills I mention above, it does suggest they are using a
computer for content production which *tends* to demand more skills than replying to an
email and web browsing.
Don’t use the sandbox or subpages more generally. The “/” thing is very Unix. If people
have prior exposure to DOS, then they will know what “\” means but probably not what “/”
means. Subpages needs a certain conceptual understanding of a hierarchical file system.
Your event is not the time to teach this. You don’t need a “sandbox” for practice, just
let them practice on their user page by adding some material about themselves (home town
they live in, their hobbies, and their paid editing disclosure!). Then get them to
bold/italicise the text, add some headings, put their hobbies in a bullet list, and then
link their hobbies to the relevant Wikipedia articles. The only thing you can’t so easily
teach in the User Page is citations (there’s no reason to cite anything about the
information they have added) but I do a “let’s pretend” citation there anyway because I
don’t want them doing it for the first time in a mainspace article.
Tip: if you are using the Visual Editor for the event (and of course you should be), it is
worth knowing that the Visual Editor is clever when it comes to copying and pasting. So if
people want to develop bits of their article content on their User Page and then copy over
to the real article, that works just fine with the Visual Editor (the source article must
be open in the VE when the copy is done, that’s the main way to get it wrong) as it always
carries the citations across correctly (which isn’t the case in the source editor when
there is reuse of existing citations).
Finally, it is very important to understand that people who attend events are committing
to the duration of the event and not necessarily beyond it. So do not expect that people
will return to their work after leaving the event, other than to show it to other people.
Even if people enjoyed the event, it does not mean they will continue as Wikipedians. Do
not set your expectations to be otherwise. I have bumped into people from time to time
after events and from this I am aware that people do get value from the event in terms of
understanding how Wikipedia is written, how citations are expected, that it isn’t the Wild
West of information where anything goes, etc. Even if they don’t continue to contribute, I
like to think that they will use Wikipedia more realistically because they better
understand how it is created and that they will share that “literacy” with their friends
and hopefully donate as well (I always stress that Wikipedia is the world’s most accessed
not-for-profit website that depends entirely on many small donations from individuals).
Kerry
From: Cultural-Partners [mailto:cultural-partners-bounces@wikimedia.ch] On Behalf Of Kerry
Raymond
Sent: Wednesday, 12 July 2017 5:05 PM
To: 'Wikimedia Chapters cultural partners coordination - closed list'
<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: Re: [cultural-partners] What advice do you connect new editing event organizers
with?
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>
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>
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 <
<mailto:cultural-partners@wikimedia.ch> cultural-partners(a)wikimedia.ch>gt;;
Wikimedia & GLAM collaboration [Public] < <mailto:glam@lists.wikimedia.org>
glam(a)lists.wikimedia.org>gt;; North American Cultural Partnerships <
<mailto:glam-us@lists.wikimedia.org> 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