A couple of points I forgot to mention.

emselves 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&gt;gt;; 'Wikimedia & GLAM collaboration [Public]' &lt;glam(a)lists.wikimedia.org&gt;rg>; 'North American Cultural Partnerships' &lt;glam-us(a)lists.wikimedia.org&gt; *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 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 &lt;cultural-partners-bounces(a)wikimedia.ch&gt;] *On Behalf Of *Alex Stinson *Sent:* Wednesday, 12 July 2017 6:34 AM *To:* Wikimedia Chapters cultural partners coordination < cultural-partners(a)wikimedia.ch&gt;gt;; Wikimedia & GLAM collaboration [Public] < glam(a)lists.wikimedia.org&gt;gt;; North American Cultural Partnerships < glam-us(a)lists.wikimedia.org&gt; *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 . 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 _______________________________________________ Cultural-Partners mailing list Cultural-Partners(a)wikimedia.ch https://intern.wikimedia.ch/lists/listinfo/cultural-partners Please treat emails sent to this list as confidential.Ask senders for permission before forwarding emails off-list.

Have you seen the new https://www.mediawiki.org/wiki/Hackathons/Handbook ? On Tue, Jul 11, 2017 at 1:34 PM Alex Stinson &lt;astinson(a)wikimedia.org&gt; wrote: -- Sherry Snyder (WhatamIdoing) Community Liaison, Wikimedia Foundation _______________________________________________ Cultural-Partners mailing list Cultural-Partners(a)wikimedia.ch https://intern.wikimedia.ch/lists/listinfo/cultural-partners Please treat emails sent to this list as confidential.Ask senders for permission before forwarding emails off-list.