Carrots or sticks

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Carrots or sticks

Jonathan Druart
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

_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Carrots or sticks

David Cook

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/

 

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). 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/ 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: [hidden email] [mailto:[hidden email]] On Behalf Of Jonathan Druart
Sent: Thursday, 27 July 2017 6:03 AM
To: [hidden email]
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


_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Carrots or sticks

David Cook
In reply to this post by Jonathan Druart

As per my last email, my interest in Bug 18987 relates again to my autonomy and mastery. I was dealing with a related problem just the other day and it was really annoying! So I’m choosing this bug rather than it being assigned to me. I’m asserting my free will. And I’m choosing this one, because I have some experience with that bug and wish to share that experience.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: David Cook [mailto:[hidden email]]
Sent: Thursday, 27 July 2017 11:25 AM
To: 'Jonathan Druart' <[hidden email]>; '[hidden email]' <[hidden email]>
Subject: RE: [Koha-devel] Carrots or sticks

 

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/

 

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). 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/ 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: [hidden email] [[hidden email]] On Behalf Of Jonathan Druart
Sent: Thursday, 27 July 2017 6:03 AM
To: [hidden email]
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


_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Carrots or sticks

Michael Cabus
In reply to this post by David Cook
Hi
 I am fairly new to the community, and I would say my "carrot" is really a desire to learn new things, which is an obsession of mine.  So, the drawback I guess is I am still learning, so not perfect at working things out, but I am persistent and self motivated.

I think doing something for the intrinsic is often the best motivator, for me at least...I just need to ramp up to being able to do some of the moves needed.

Michael Cabus

On Wed, Jul 26, 2017 at 9:24 PM, David Cook <[hidden email]> wrote:

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/

 

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). 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/ 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: [hidden email] [mailto:[hidden email]] On Behalf Of Jonathan Druart
Sent: Thursday, 27 July 2017 6:03 AM
To: [hidden email]
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


_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/


_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Carrots or sticks

Jonathan Druart
In reply to this post by David Cook
Hi David,

Thank you for your answer. I do not have your prose and I would prefer to discuss about all of this around a beer, so I will answer shortly.

I was not talking about carrot+stick, but carrots only. We are all different and the idea was that receiving something from the whole community for the work they provided could encourage some people.

I am not burning out, no worries. I am still motivated, more than ever. But it costs me a lot of energy to try and keep people involved and motivated :) It is also tiresome to repeat and repeat again the same things to each of you because not everybody reads their emails.

I have never forced anybody to do something (well, rarely). I think I did what I could to understand and collect the needs and expectation of everybody at the beginning of the release cycle (results of the poll are coming very soon) in order to prioritize and coordinate a plan for the next 6 months (well, 4 from now). So yes everybody is free to work on whatever they want, but communication and dialogue before the dev tunnel is always better (especially to get early feedback and avoid duplication of work).

Most of the work I provide for Koha is paid. My clients are not libraries but support companies that provide Koha support to libraries. I do not think people should provide unpaid work, especially if they work for a support company. As previously, we are all different, and the support companies are too. A boss can decide to contribute to the community or not, to reverse the internal devs or not, to thank the community to provide a great software that make their company great too. Koha is a free software and all companies have the right to behave how they want, but they all need to understand that without people working at code level (open bug report + write patch + signoff + QA) they would not have the quality they provide to their customer. And... they would receive more complains from their customers and they would need to pay guys to provide support.
I do not force anyone but only try to make you focus on important things. If you are working in a support company which hosts Koha instances with a version having a known critical bug, I do not understand why you would not invest time to help us. If you do not, you will certainly face the bug soon, with 20 customers contacting the support at the same time because they lost circulation data or whatever.

I do no talk about performance (memcached + plack) and security issues we have fixed in the last releases. Customers do not pay for that, but somebody has to work on it. Hopefully it's not only unpaid work - if your boss understand than helping/contributing upstream is helping the company too.

"Who is responsible for Koha? As RM, maybe fixing the critical bugs should fall to you."
Heh, funny. Before being RM I was already "responsible for Koha", as a dev and a member of the QA team.
For the last 5 years I backed the RM in all the different tasks (fix tests, bug fix, address critical bugs quickly, process QA queue, etc.)
100% of my working time is dedicated to Koha community, and I am (I think) the only person in that case. What I feel is that I have been filling a gap over the last years and people have got used to me doing the urgent fixes. I personally think that it is dangerous for the community not to have more people involved. Are there enough people feeling responsible to provide security fix in a few hours? Who is going to care about failing tests? What would happen if I quit the project?
And for reminder, I cannot fix a bug alone, there is a workflow to follow. Note that I have been bypassing these steps for some patches I could not wait for days to be pushed. Which is not good either, I shout out when previous RMs did :)

"So I was just writing a criticism of http://dashboard.koha-community.org when I noticed that clicking on..."
See "What's on in koha-devel #10" :)
As I already said several times I am assuming that everybody read these email. 10min per month to follow what has been done, what's hot, etc. sounds like the very minimum everybody must do.
Chris accepts pull requests, if you want to improve the ergonomic ;)

What make me keep moving forward (my own carrot) is to see that Koha is being used more and more and that librarians love it. Regarding the source code and the interface I see and know that there are still a lot to achieve to make it even better.

Cheers,
Jonathan

On Wed, 26 Jul 2017 at 22:24 David Cook <[hidden email]> wrote:

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/

 

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). 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/ 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: <a href="tel:02%2092%2012%2008%2099" value="+33292120899" target="_blank">02 9212 0899

Direct: <a href="tel:02%2080%2005%2005%2095" value="+33280050595" target="_blank">02 8005 0595

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Jonathan Druart
Sent: Thursday, 27 July 2017 6:03 AM
To: [hidden email]
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


_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Loading...