Learning patterns/Working with developers who are not Wikimedians
What problem does this solve?
[edit]You may want to involve developers who are not Wikimedians (as in they don't have months of first hand experience in Wikimedia world). In our case, we had great, smartest developers, who write clean and efficient code solving complicated problems, win one competition after another, and publish scientific papers in most rated journals. And that's the catch (for someone inexperienced in managing team of developers). You assume that as they are so smart and professional, the best thing you can do is leave them alone and not interrupt them. The reality is that you and your team become victim of Curse of knowledge - you assume things which are obvious to you, as you've spent years here, will be obvious enough for them too. That's not the case, and while avoiding demotivating them, with frequent meetings/check-in and things which may be perceived as micro-managment you may run into opposite problem. They may spend their time solving non-existent problems and at same time obvious workflow scenarios maybe something which never crossed their mind. Should be that case, you will really waste your team time and resources that way, and risk to still demotivate people, after they realized they were moving in wrong direction.
What is the solution?
[edit]- Explain and write down things even if you think they are obvious.
- You won't be able to foresee everything they may run in, so be in touch and encourage them to ask you questions whenever in slightest doubt.
- Once again, encourage them to ask you questions.
- Have frequent call-in, make short Agile/SCRUM style meetings.
- Write down things, even if it seems everyone understand everything doing verbal communication.
- Expose the developer to hands-on Wikimedia editing experience, and/or get them in touch with Wikimedians who demonstrate their workflows
- Suggest spending some time as a Wikimedia editor. You can help the developer get started by giving them specific assignments (e.g. improve certain Wikidata items; upload a few photographs of their environment to Wikimedia Commons, etc)
- Demonstrate your own Wikimedia editing in a video call, and/or ask other Wikimedians to give them a short demo. Especially if the developer will be building user-facing software features, it will be extremely helpful for them to see and understand how users will interact with 'their' code.
- A structured onboarding checklist may be very helpful. For the first week of work, provide the developer with a checklist of things to read, videos to watch, code bases to get acquainted with... and make sure these include good Wikimedia-related tutorials. You can see an example of such a checklist here.
Things to consider
[edit]This problem often arises when you avoid managing people too much, as you basically see no need in so. Solution suggests not being afraid of it, you will feel when it's too much of getting into their business. But naturally there's still way to overdo it.
When to use
[edit]Working with developers who have no first hand Wikimedian experience. Pay special attention to parts of software which are in "close contact" with MediaWiki, its content or workflow. That's where you can help your developers a lot.
Related patterns
[edit]Endorsements
[edit]- This is similar to what happened to StrepHit, during the first phase of its renewal (see the scope). The team dived into the MediaWiki extensions and Wikidata gadgets worlds, both with a steep learning curve. Hjfocs (talk) 16:41, 30 November 2017 (UTC)
- In the Wikimedia grants-funded project to extend OpenRefine with Structured Data on Wikimedia Commons functionalities, we hired one external developer. We onboarded her with a guided checklist that included quite a few instructional videos to watch (for instance the three-hour introduction to Wikidata for absolute beginners by Asaf Bartov) and also asked her to create a Wikimedia account and to do a few first edits. SFauconnier (talk) 12:01, 12 January 2022 (UTC)