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@wikimedia.ch; Wikimedia & GLAM collaboration [Public] glam@lists.wikimedia.org; North American Cultural Partnerships glam-us@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