Jump to content

Learning patterns/Working with developers who are not Wikimedians

From Meta, a Wikimedia project coordination wiki
A learning pattern forproject management
Working with developers who are not Wikimedians
problemCoordinating developers who are not Wikimedians
solutionStay closely in touch with developers, explain even things which seem obvious to you, and encouraging them to ask you questions and spend some time editing Wikimedia projects themselves.
created on7 June, 2017

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]