Talk:Train the trainers - how can we make it perfect?

Please share your thoughts.

What resources do you need?

• An important resource that I've never had access to is some kind of systematically gather feedback from participants of previous sessions. Reading feedback is one of the best ways of finding new ideas for improvements, and I feel like this feedback isn't being provided to the trainers (if it's gathered at all). Mark L MacDonald (talk) 08:56, 17 July 2014 (BST)

Each event should have evaluation information on this wiki. That's what I try to do with all my events, and when I use evaluation forms I copy all responses onto the wiki. See for example Wellcome_Library_editathon MartinPoulter (talk) 21:00, 29 August 2014 (BST)

How can we ensure consistency? Do we need to?

• I have a few ideas regarding this:

1. Host the editathon (or other event) pages on en.wiki, rather than on wikimedia.org.uk. Firstly, users probably won't have accounts on the Wikimedia UK, and it might cause unnecessary confusion. Secondly, and more importantly, you can't see red links from the WMUK site. Redirects to the event pages could easily be created on wikimedia.org.uk, for categorization purposes, if that's what's desired.
2. On the event page, have sections set up that list 1) attendees, 2) target list, and 3) articles created / expanded during the events. If it's on en.wiki, then the page itself can more easily be modified during the event itself.

I suppose if consistency is what's desired, then having a consistent event template (not necessarily a "Template:", of course) would be good. Indeed, there is probably a template around somewhere, since most event pages look pretty similar. I suppose one might ask where is appropriate to host the event page on en.wiki, but I think an appropriate WikiProject wouldn't mind having a new subpage created for that purpose. Mark L MacDonald (talk) 14:41, 15 July 2014 (BST)

• Detailed comments in the thread below. Wikipedia training is actually tricky - all sorts of heffalump traps arise, particularly when you try to adopt someone else's practice without understanding quite how you lay the ground. It's the sort of area where a short booklet for trainers could be clarifying. Charles Matthews (talk) 15:26, 31 July 2014 (BST)

• Professionalism (as in professional quality) is one of the core goals of the training programme, and I see two ways to ensure this.
  • One is continual informal peer review, as in many professions. This has two components: 1) trainers need to observe each other at work, and 2) there needs to be agreed channels to give and receive feedback and trainers should take feedback into account.
    • Training sessions should have a mix of trainers of different experience/ assessment level: not necessarily with the most 'senior' trainers taking a lead role. After the training session, the trainers should have a private conversation about how well it went, reflecting on both good and bad aspects (as we were taught at the TfT workshops in great detail). Ideally the trainers should write a private reflective diary about what they are glad to have done and what they would have done differently. Experienced trainers should be willing to listen to feedback from newcomers just as much as vice versa. If a trainer seems to be letting WMUK down in any respect (see my definition of a good trainer), the other trainers should raise their observations tactfully and privately with the person concerned. If the person takes the criticism on board, then fine, but if the others are worried that the person has not learnt and will make the same mistakes again, they should approach either the Lead Trainers or the Chief Executive.
  • The other process is soliciting and recording anonymous feedback from attendees. In some kinds of session it's very difficult to do this, but in a training session or other extended workshop it should be possible: see what I've done with my workshops in universities. For a short presentation where you're hurried out of the room at the end, it's still possible to poll the audience by raised arms as to whether they have learnt anything useful, whether they intend to contribute to Wikipedia, and so on. Feedback should not just be "rate this workshop from 1 to 5" but should actively solicit suggestions for improvement.
    • All feedback so received should go on this wiki, with very rare exceptions. I put all feedback from my sessions on-wiki, especially any negative feedback. My experience is that audiences are grateful and courteous to WMUK volunteers even when anonymously expressing dissatisfaction, but let's think about the possibility of upsetting feedback. If people have written something homophobic/sexist/etc. about you then of course you've no obligation to share that. If feedback is about the trainee's experience but is nonetheless upsetting to be public ("Trainer needs to get rid of body odour"; "Trainer seems lost like a fish out of water"; "Trainer has spotty bum-cleavage") you should still be reflecting on it and preferably discussing it with another trainer.

MartinPoulter (talk) 21:34, 29 August 2014 (BST)

Do we need more teaching materials?

• Yes; while the cheatsheet is good, it does a poor job regarding citations (see also w:Wikipedia:Referencing for beginners). I would like to see a better range of cheatsheets, in particular one that is specifically for first-time editors, who are trying to create their first article. Such a cheatsheet might include:

1. Emphasis on the easy-to-use refToolbar features, rather than directly typing in <ref>{{cite web|url=...}}</ref>.
2. An example with <ref>{{cite web|url=...}}</ref>.
3. An example of naming a ref tag, so it can be used multiple times (this often comes up in editathons, and would be good to have the syntax handy)
4. I think lists and images are not that crucial for first time editors, so those bits of the cheatsheet could be dropped; even the multiple section headings are unnecessary.. ===Section=== is often all they will need. Citations are difficult, and important, so they should be given more respect on any cheatsheet that we give them.

Thanks, Mark L MacDonald (talk) 14:41, 15 July 2014 (BST)

• Definitely. The development of handouts seemed to get caught up in the doldrums around the time that the Visual Editor was first introduced (i.e. a year ago). I wouldn't change the existing cheatsheet. I think a one-page discussion of how you start an article would meet a long-felt want. Charles Matthews (talk) 15:21, 31 July 2014 (BST)

User:Mark L MacDonald: Please feel welcome to look at the example syllabi at For_trainers#Syllabi_and_resources and comment/alter/extend. MartinPoulter (talk) 21:00, 29 August 2014 (BST)

Refresher

I was on the recent refresher for "Train the Trainers" in London. I thought it was a worthwhile day, but it left me wondering how we make sure editathons continue to follow the recommended lines. I welcome the discussion that is beginning on this page.

One thing that has intrigued me after editathons is the number of people who seemed interested, but don't continue to edit. I have been told that this attrition is pretty normal, as people may be interested to find out how Wikipedia works without wanting a new hobby. On the other hand, if feedback was passed to trainers, perhaps people who would appreciate a helping hand after editathons could be identified. -Thoughtfortheday (talk) 10:39, 30 July 2014 (BST)

This is a consistent issue for all the chapters - training and all the enthusiasm associated with it and then.....nothing much, at least not in terms of edits. Let me recount a personal experience. A few years ago my wife and I visited a hotel which we really liked. They asked us to post a review on Trip Advisor . I had never heard of the site but did so. I then received a 'thanks' email from Trip Advisor. This made me feel appreciated even though I knew it was some sort of bot. Over the last few years I have continued to post reviews and each time I get a 'thanks' plus every so often an email saying things like '50 people read your review' etc. I have a feeling we need to do more of this encouragement and validation and staff are looking at how we can use our CiviCRM database to generate encouraging and celebratory emails to new contributors. Thoughts? Jon Davies (WMUK) (talk) 10:50, 30 July 2014 (BST)

It's good to hear that staff are working on this sort of thing. -Thoughtfortheday (talk) 16:00, 1 August 2014 (BST)

Getting new users aware of the Wikipedia Teahouse seems to create that kind of positive feedback that keeps them engaged longer, in my very unscientific experience. MartinPoulter (talk) 21:00, 29 August 2014 (BST)

User:Thoughtfortheday: a simple step we can take (and are taking) is collecting all the WP usernames of participants in an editing event. This usually means passing round a sign-up sheet, or sending a supporting trainer round to politely ask for usernames. These usernames should be listed on the event page on Wikipedia (or whichever project): see any of my past workshops. Then you can send encouraging user-talk messages post-event or just check that they haven't got into some kind of trouble. I say this yet I'm guilty of not doing enough follow-up. User-talk stuff like wiki-love or pictures of cookies etc. goes down well with new users, even serious academics, in my experience. It gets across that Wikipedia isn't an application you enter data into but a community you interact with. MartinPoulter (talk) 21:42, 29 August 2014 (BST)

Focus less on the technical aspects, more on the content?

A couple of recent experiences have made me wonder whether we focus too much on the technical details when doing training, and not enough on getting people writing content. Namely:

• A training event that lasted about 3 hours on an afternoon, where we ended up using all the time to teach attendees the technical aspects of Wikipedia editing but didn't get the chance for attendees to actually do any editing
• I currently have two summer students who have been writing Wikipedia articles. I was expecting to spend a fair amount of time teaching them the technicalities of how to do the editing, but it turned out that pointing them towards the introduction and help pages did most of that work, and instead most of my time supervising them has been focused more on the content they're working on instead (with occasional sojourns into specific formatting issues as they came up).

I wonder if a) there should be a standard template available for what to cover in a training event and how long to spend on each topic, which could be weighted towards giving attendees the time to do more editing and less listening to trainers, and b) it would be worth talking about this issue during Train the Trainers courses and refreshers to figure out what the best way (and the tested/potential variations that could be made) would be. Thanks. Mike Peel (talk) 20:27, 30 July 2014 (BST)

Here (a) is clearly too prescriptive. Ahead of the event, it is good practice to establish some sort of expectations, and discuss what sort of background the audience have. Trainers have very different teaching styles, also. What I do routinely is to ask, at a flipchart, what sort of topics people are interested in, at the introductions stage, and try to cover most of the topics raised at some level.

A three-hour event is about the minimal length for getting the typical attendee up to the point where they can edit a bit. Good practice is certainly not having the trainer talking all the time, but to have exercises, interactive parts of the event, and some free editing time in which everyone can experiment with simple format and so in, in their sandbox. The cheatsheet can be circulated in relation to that.

There is a delicate balance structured/unstructured to be struck in these events, actually. Any "fixed" programme risks not being to rejig the event on the fly, which is a great virtue. I find I have to prepare at least 50% more material than would be needed, in the knowledge that much of it won't be covered on the day.

It is not the outline that is key, in fact. It is having done homework on specific examples and things to say about them. Over time these tend to bed down into "modules" in which the points are the same, the details differ (I do one on COI, most obviously.) I would say that sharing things at this level of granularity is the right approach (how do you teach X?). The VLE can clearly be used that way.

People who can glean what they need from Wikipedia's manual pages are not the "typical attendee", because WMUK tends to work with institutions where only a small proportion of the audience would come in at that level. So far practice has not been to ask people to study up before coming to a workshop - in fact, rather the opposite, the fashion for editathons means events are rather light on preparation and training, whatever their virtues for networking. That limits what happens on the day. The VLE could be used: I'm doing a suite of videos that get straight to editing right now, for example. They could provide a 30 minute introduction so people wouldn't come in completely cold.

"Train the Trainers" at the entry level does emphasise getting the audience to do work, rather than just listen. (By the way, I have a rooted objection to the terminology confusingly applied to the training programme itself. An uphill battle.)

The Midas refresher recently was very good, I thought. There is no reason that a refresher designed to share good training practice should not also be run, internally. There are points about moderation: from very early on with the VLE I was aware that "the right way to teach" something would probably be a fruitless topic for discussion. I do think we are making progress on the "syllabus" front (for example the page Virtual Learning Environment/Lesson dependencies here I have been working on with explicit prerequisites for topics, from the VLE work). One thing discussed at the Midas refresher was getting an explicit syllabus set out.

Charles Matthews (talk) 11:05, 31 July 2014 (BST)

For an alternate view, pointed out to me today: w:User:Rockpocket/Training is a set of eight pages, outlining a typical workshop aimed at an audience of research scientists. It is nearly all about editing, of course. And "community" aspects hardly enter. That is the thinking from roughly four years ago, so before training in the UK was at all common. Charles Matthews (talk) 15:08, 2 August 2014 (BST)

Mike's examples make me think of a couple of things.

1. Yes. Training that actually focuses on editing is good. I think I managed that in the girl geeks training, the plan for which can be found here. That was for a longer slot that three hours but I think it is a good starting point.
2. I agree that people can teach themsleves. We can help them learn some apects quicker, but maybe the main thing we can teach them is that it is impossible to break Wikipedia and so you should be bold. If we were going to expand on that slightly we could base what we teach around WP:Trifecta, which seems to be designed around how people learn Wikipedia (as opposed to WP:Five pillars which is more off-putting).

Yaris678 (talk) 12:47, 19 August 2014 (BST)

I'm actually no fan of the five pillars for training, and a couple of times have developed the point that it is really a conversion kit for open-source software folk rather than anything else. I doubt that the Trifecta is the best one can do. As well as being off-putting in other ways. Charles Matthews (talk) 12:57, 19 August 2014 (BST)

Go on. I'd be interested to know why you think the trifecta is off-putting. Two aspects that could be a problem are the use of the word "dick" and potential confusion around a rule that says "ignore all rules". Obviously we would be careful how we get these points across. In some situations we wouldn't even mention that terminology. But the ideas are at the centre of how people work on Wikipedia so getting the ideas across is the key, in my view. Yaris678 (talk) 18:00, 19 August 2014 (BST)

Yeah, well, on the former, Phil Sandifer has a lot to answer for. IAR is not so bad: an academic I knew once brought up in a meeting "our old friend normally", which is a different way of saying the same thing. "Normally" is tacitly understood in policy. But I had the experience training with someone who later brought up my having contradicted him with a "not always" about something, as if he didn't really believe all that. It's a matter of saying there can be quibbles, but they should be in the direction of common sense. All to be done in a non-threatening way, or we just lose people's attention.

Anyway, depending on the audience, what they really may not be able to work out for themselves is the social side, and why people may react to some types of editing rather than others. Charles Matthews (talk) 18:32, 19 August 2014 (BST)