[Koha-devel] Carrots or sticks

Thu Jul 27 03:24:56 CEST 2017

Personally, I find neither the carrot nor the stick to be motivating. While I don’t have a great link to point to at the moment, the following may do for now:  <http://coaching-journey.com/carrot-and-stick-intrinsic-extrinsic-motivation/> http://coaching-journey.com/carrot-and-stick-intrinsic-extrinsic-motivation/

Autonomy, mastery, and purpose are listed as “three essential elements of motivation”, and I think that probably describes my motivation pretty well, especially at work. With autonomy, I’m given the choice to make my own priorities (for the most part) and carry out my own labour in the pursuit of my own goals. With mastery, I’m on a constant quest to improve my own skills and I do so by building enhancements and fixing bugs. With purpose, I feel a desire to contribute to a group or community for the sake of our shared experience and camaraderie.

I think, in the past, the Koha community has appealed to this sense of purpose for myself and others. We’ll sacrifice ourselves and our own work and time for the betterment of the community. However, I’m not sure that’s always sustainable, and I think that’s probably contributed to a few people burning out over the years. I know if I tried to contribute now as much as I did a couple of years ago, I’d just burn out. I have more responsibilities and paid work to do now, so I can’t justify doing unpaid work in that same time. If I try to sacrifice my personal life for that unpaid work, then I’m sacrificing my family and that’s just not going to happen. No to workaholism for me. So maybe I’m a bit disillusioned when it comes to open source communities. Or maybe I realise that we’re all just human and have different things going on in our lives at any given time. I still believe in the community, but as a community of humans.

I’ve said before that I think Koha could use more cohesion in terms of pushing patches. That is, rather than pushing everything that comes through, that patches could be pushed based on some end goals like improving stability or adding support for X protocol or adding Y feature. However, I think it was Kyle Hall that said part of the great thing about Koha is that everyone is free to work on whatever they want (ie they have autonomy). Whatever their interest may be or wherever their skills may be. You can’t necessarily force people to do what you want them to do. Not if you want them to be motivated at least. You can try to coerce them using extrinsic rewards (like money or recognition), but that’s only ever going to get you so far I think.

That said… I think it’s fair that you ‘do not plan to push anything “big” until we have a solution’. If I were RM, I would probably impose a policy where bug fixes are given priority and enhancements come last in the queue, and even then bug fixes would be ranked in terms of severity. Stability is one of my top priorities as a developer and manager of my local Koha instances. 

So what motivates me to do paid support? Typically, I prioritize based on need/severity of bugs. I like to clear the decks of bugs or things affecting stability. After that, it depends on whether my boss requests that I do something, whether I can finish a few small tasks rather than getting part way through one big task, whether I will need to wait for someone else after doing some work, etc. There’s lots of factors. 

What motivates me to do unpaid support? If it’s on IRC or the listserv, I share advice based on autonomy/mastery. That is, if I know the answer, I’ll generally share it. If it’s testing a bug, I probably will only test it if it’s relating to something that impacts me locally right now. Unless it’s something that will impact me in the future and I will do myself a favour by acting now. I may also test the bug if it’s something I’m genuinely interested in personally (ie I exercise my autonomy). If it’s in terms of contributing patches… I typically write patches locally and then upstream them. But these generally don’t tend to be for “big red warning button” type bugs.

So how do you motivate people to work on things that don’t appeal to their sense of autonomy, mastery, or purpose? I have no idea. Clearly, Jonathan, you’ve observed that there are a number of bugs that people aren’t working on, even though they are very important. I think maybe you’re already down the right path with shutting down the shop until people work on the important stuff. While autonomy, mastery, and purpose are great… there comes a time when some things just need to get done. 

But… as a developer who doesn’t contribute very often these days, shutting down the shop won’t really affect me in the short-term. I’ll just continue doing my local paid work oblivious to the Koha community train stopping. So I suppose you’d need to identify the people who would be affected… and tell them that nothing is going to be pushed until they do some work on critical immediate issues. 

I suppose that could cause regular contributors to stop contributing, but… if regular contributors are your only real workforce, I’m not sure what other options you have. Pot holes need to be filled, cracked glass needs to be replaced. 

Who is responsible for Koha? As RM, maybe fixing the critical bugs should fall to you. But I suppose your role is about “releases” rather than development per se. Is there anyone on the release team who should be responsible for critical fixes? Maybe we need something like the “DSpace Committers” ( <http://www.dspace.org/contributors> http://www.dspace.org/contributors). Recently, I’ve done a bit of work with Archivematica, and they’re backed by the company Artefactual Systems. While it’s an open source project and they take community contributions, they have paid staff who are ultimately responsible for the project. Of course, I think everyone would want to avoid another Liblime situation, so maybe being backed by a single company isn’t the great idea. But having a core committer group could be a good idea. If you’re still interested in extrinsic rewards, you could provide priority to patches written by core committers. Folk like me would be code contributors, but they wouldn’t be core committers. We don’t produce a frequent enough volume to be core. But there are some people who do. Maybe those core contributors should be offered more responsibility in exchange for prioritization of their work. I suppose that’s going back to the carrot :p. Likewise, in terms of the stick, if core contributors aren’t clearing critical bugs, maybe there does need to be a natural consequence[0]. With that consequence being that nothing gets pushed until those critical bugs are resolved. 

I don’t know the answer. This is just my understanding/analysis of the situation. If you do gather a team of core committers, you may also find it easier to manage these situations. Instead of pinging all Koha developers, you could ping the core Koha developers. That being said… I’m glad you did ping all of us in regards to Bug 18966 and ancestors, since that is a bug that really does motivate me to contribute, even as an irregular code contributor. 

So I was just writing a criticism of  <http://dashboard.koha-community.org/> http://dashboard.koha-community.org/ when I noticed that clicking on “Overall bug tracker health status: 1 blockers 3 criticals, 18 majors.” Brings up information about those bugs! Does everyone know that works that way? I’d suggest adding some clues to users that they can expand that section! At a glance, I see Bug 18987, and I think I know what the problem is and now I’m keen to see the solution. I’m going to go click on it and check it out!

[0] http://www.webmd.com/parenting/natural-and-logical-consequences-for-behavior

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

Office: 02 9212 0899

Direct: 02 8005 0595

From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Jonathan Druart
Sent: Thursday, 27 July 2017 6:03 AM
To: koha-devel at lists.koha-community.org
Subject: [Koha-devel] Carrots or sticks

Hi devs,

There is something I tried to think about at the beginning of the release cycle but put it aside as I did not manage to formulate it in a clear way.
I would like not to start a "carrot or stick approach", but would prefer a "only carrots on the stick" approach :)
First I was thinking about it more for new contributors, but that could be extended to regular contributors as well.

I have opened a card on the kanban and listed the few ideas I wrote down 2 months ago. Feel free to continue the list if you like the idea.

https://tree.taiga.io/project/joubu-koha-rm-1711/us/130

Any suggestions?

Cheers,

Jonathan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20170727/cd2b36be/attachment-0001.html>