Thanks for your insights Kerry. Maybe you could make a Wikipedia userpage for these suggestions in the same way that Andy has done (on his Wikidata userpage linked earlier). I especially like (and recognize!) your comments about the average "wikipotential" of newbies who may be good writers, footnoters, googlers, and so forth. Cut & paste of urls is also something people rarely need to do who share stuff on mobile these days. In fact, the whole concept of having more than 4 or 5 tabs open may be foreign to most people (and in my case, I generally have more than 25 tabs open at any given point in time).
On Wed, Jul 12, 2017 at 10:57 AM, Kerry Raymond <[email protected]> wrote: > 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:[email protected]] *On > Behalf Of *Kerry Raymond > *Sent:* Wednesday, 12 July 2017 5:05 PM > *To:* 'Wikimedia Chapters cultural partners coordination - closed list' < > [email protected]>; 'Wikimedia & GLAM collaboration > [Public]' <[email protected]>; 'North American Cultural > Partnerships' <[email protected]> > *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:[email protected] > <[email protected]>] *On Behalf Of *Alex Stinson > *Sent:* Wednesday, 12 July 2017 6:34 AM > *To:* Wikimedia Chapters cultural partners coordination < > [email protected]>; Wikimedia & GLAM collaboration [Public] < > [email protected]>; North American Cultural Partnerships < > [email protected]> > *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 > [email protected] > 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. >
_______________________________________________ GLAM-US mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/glam-us
