Learning patterns/Working with developers who are not Wikimedians

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
A learning pattern forproject management
Working with developers who are not Wikimedians
MechaDuck.png
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.
creatorXelgen
endorse
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.
  • If possible suggest spending a week or 2 as Wikimedia editor.

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.

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)