Re: [Koha] Users and developers (was KUDOS - ALA Proposed Agenda)
Okay, get ready for a rant...
Sometimes "users" and "developers" are at opposite poles...
When? I'm a Koha user. And in using Koha I saw that I could make Koha better, and in time became a Koha developer. There is no Koha developer out there who is developing Koha features just because they think it would be cool to do. Koha developers are doing their work because they *see* a need, in an actual user or an actual library. Or developers are getting paid by libraries to develop the features the libraries need. Here's when users and developers are at opposite poles: - When a company decides to develop a feature that they think will help sell a product, even though the feature doesn't meet any actual need - When a company throttles or cripples a feature in a product because they want to charge extra for a particular feature No self-respecting Koha developer or Koha support company is doing that kind of stuff. That's why we're here.
I think this is more about giving the "users" more of a voice than they've traditionally had in the past, no?
I honestly don't know where this comes from. The Koha project is just about as open and accessible as any software project can be. You can participate on the mailing list, you can submit bug reports yourself, you can submit your own patches or hire your own programmers to write code for you. You can talk to Koha developers on IRC almost 24 hours a day! The only way in which one might consider that users need "more of a voice" is if you think of it in terms of working collectively to achieve a goal that Koha libraries individually could not. If that's the intention of that statement then, rant over. I agree 100% that libraries should be seeking ways to pool their resources ($$) to get done the things they want done, i.e. hire developers or commission existing companies to do work for them. However, if by "more of a voice" you mean, "If we all get together an ask for a feature the Koha developers should implement it," then no. This is open source, but time is money. You can donate your time (as I do, every day, in code, markup, email, and IRC) or you can donate your money--in the form of paid development work. This doesn't shut anyone out. But yes, there is a bar that you have to clear. I don't know how else it can work. So: Let's get together as users and/or developers and figure out how we can get some stuff done. Let's put together a structure by which Koha users can spec out new features and get them funded, collectively. Let's put together a structure by which Koha users can communicate with their vendors without fear of exclusion or reprisal. Let's not talk about a users group breaking down some barrier that isn't really there--let's talk about strengthening and leveraging the connection that we *already have!* -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Hear hear, my friend. Well said and I agree completely. Mobile-ly yours, Liz Rea NEKLS On Jan 19, 2010, at 6:58 PM, Owen Leonard <oleonard@myacpl.org> wrote:
Okay, get ready for a rant...
Sometimes "users" and "developers" are at opposite poles...
When? I'm a Koha user. And in using Koha I saw that I could make Koha better, and in time became a Koha developer. There is no Koha developer out there who is developing Koha features just because they think it would be cool to do. Koha developers are doing their work because they *see* a need, in an actual user or an actual library. Or developers are getting paid by libraries to develop the features the libraries need.
Here's when users and developers are at opposite poles:
- When a company decides to develop a feature that they think will help sell a product, even though the feature doesn't meet any actual need - When a company throttles or cripples a feature in a product because they want to charge extra for a particular feature
No self-respecting Koha developer or Koha support company is doing that kind of stuff. That's why we're here.
I think this is more about giving the "users" more of a voice than they've traditionally had in the past, no?
I honestly don't know where this comes from. The Koha project is just about as open and accessible as any software project can be. You can participate on the mailing list, you can submit bug reports yourself, you can submit your own patches or hire your own programmers to write code for you. You can talk to Koha developers on IRC almost 24 hours a day!
The only way in which one might consider that users need "more of a voice" is if you think of it in terms of working collectively to achieve a goal that Koha libraries individually could not. If that's the intention of that statement then, rant over. I agree 100% that libraries should be seeking ways to pool their resources ($$) to get done the things they want done, i.e. hire developers or commission existing companies to do work for them.
However, if by "more of a voice" you mean, "If we all get together an ask for a feature the Koha developers should implement it," then no. This is open source, but time is money. You can donate your time (as I do, every day, in code, markup, email, and IRC) or you can donate your money--in the form of paid development work.
This doesn't shut anyone out. But yes, there is a bar that you have to clear. I don't know how else it can work.
So: Let's get together as users and/or developers and figure out how we can get some stuff done. Let's put together a structure by which Koha users can spec out new features and get them funded, collectively. Let's put together a structure by which Koha users can communicate with their vendors without fear of exclusion or reprisal. Let's not talk about a users group breaking down some barrier that isn't really there--let's talk about strengthening and leveraging the connection that we *already have!*
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
+1 Well said. Kind Regards, Chris On Tue, Jan 19, 2010 at 7:58 PM, Owen Leonard <oleonard@myacpl.org> wrote:
Okay, get ready for a rant...
Sometimes "users" and "developers" are at opposite poles...
When? I'm a Koha user. And in using Koha I saw that I could make Koha better, and in time became a Koha developer. There is no Koha developer out there who is developing Koha features just because they think it would be cool to do. Koha developers are doing their work because they *see* a need, in an actual user or an actual library. Or developers are getting paid by libraries to develop the features the libraries need.
Here's when users and developers are at opposite poles:
- When a company decides to develop a feature that they think will help sell a product, even though the feature doesn't meet any actual need - When a company throttles or cripples a feature in a product because they want to charge extra for a particular feature
No self-respecting Koha developer or Koha support company is doing that kind of stuff. That's why we're here.
I think this is more about giving the "users" more of a voice than they've traditionally had in the past, no?
I honestly don't know where this comes from. The Koha project is just about as open and accessible as any software project can be. You can participate on the mailing list, you can submit bug reports yourself, you can submit your own patches or hire your own programmers to write code for you. You can talk to Koha developers on IRC almost 24 hours a day!
The only way in which one might consider that users need "more of a voice" is if you think of it in terms of working collectively to achieve a goal that Koha libraries individually could not. If that's the intention of that statement then, rant over. I agree 100% that libraries should be seeking ways to pool their resources ($$) to get done the things they want done, i.e. hire developers or commission existing companies to do work for them.
However, if by "more of a voice" you mean, "If we all get together an ask for a feature the Koha developers should implement it," then no. This is open source, but time is money. You can donate your time (as I do, every day, in code, markup, email, and IRC) or you can donate your money--in the form of paid development work.
This doesn't shut anyone out. But yes, there is a bar that you have to clear. I don't know how else it can work.
So: Let's get together as users and/or developers and figure out how we can get some stuff done. Let's put together a structure by which Koha users can spec out new features and get them funded, collectively. Let's put together a structure by which Koha users can communicate with their vendors without fear of exclusion or reprisal. Let's not talk about a users group breaking down some barrier that isn't really there--let's talk about strengthening and leveraging the connection that we *already have!*
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Yep - totally agree. Owen Leonard wrote:
Okay, get ready for a rant...
Sometimes "users" and "developers" are at opposite poles...
When? I'm a Koha user. And in using Koha I saw that I could make Koha better, and in time became a Koha developer. There is no Koha developer out there who is developing Koha features just because they think it would be cool to do. Koha developers are doing their work because they *see* a need, in an actual user or an actual library. Or developers are getting paid by libraries to develop the features the libraries need.
Here's when users and developers are at opposite poles:
- When a company decides to develop a feature that they think will help sell a product, even though the feature doesn't meet any actual need - When a company throttles or cripples a feature in a product because they want to charge extra for a particular feature
No self-respecting Koha developer or Koha support company is doing that kind of stuff. That's why we're here.
I think this is more about giving the "users" more of a voice than they've traditionally had in the past, no?
I honestly don't know where this comes from. The Koha project is just about as open and accessible as any software project can be. You can participate on the mailing list, you can submit bug reports yourself, you can submit your own patches or hire your own programmers to write code for you. You can talk to Koha developers on IRC almost 24 hours a day!
The only way in which one might consider that users need "more of a voice" is if you think of it in terms of working collectively to achieve a goal that Koha libraries individually could not. If that's the intention of that statement then, rant over. I agree 100% that libraries should be seeking ways to pool their resources ($$) to get done the things they want done, i.e. hire developers or commission existing companies to do work for them.
However, if by "more of a voice" you mean, "If we all get together an ask for a feature the Koha developers should implement it," then no. This is open source, but time is money. You can donate your time (as I do, every day, in code, markup, email, and IRC) or you can donate your money--in the form of paid development work.
This doesn't shut anyone out. But yes, there is a bar that you have to clear. I don't know how else it can work.
So: Let's get together as users and/or developers and figure out how we can get some stuff done. Let's put together a structure by which Koha users can spec out new features and get them funded, collectively. Let's put together a structure by which Koha users can communicate with their vendors without fear of exclusion or reprisal. Let's not talk about a users group breaking down some barrier that isn't really there--let's talk about strengthening and leveraging the connection that we *already have!*
-- Owen
As one of the individuals that is ATTEMPTING to put some structure to this and get it off the ground I would love suggestions on how to make this work for the community. I hate confrontation and love constructive criticism - and am open for suggestions on how to make this work for the community in North America. I don't want to put people at opposite poles, but also must work within the regulations of the IRS. I am open to suggestions on how we can get KUDOS up and running so as to function to benefit all of us. I see KUDOS as a major help in getting conferences to work, possible joint development/grant writing/managing - IMLS is always looking for collaborative ventures between various library types. WE ARE IT! I don't mind rants, I don't mind listening, but help me build the structure so that we can work and move forward. What specifically do you suggest to make this work and stay away from the proprietary user group structure. Trying our best to get it right. David Schuster - don't shoot the messenger if you don't like the way it looks - help us out as libraries are known to do so well. HELP each other. Owen Leonard-4 wrote:
Okay, get ready for a rant...
Sometimes "users" and "developers" are at opposite poles...
When? I'm a Koha user. And in using Koha I saw that I could make Koha better, and in time became a Koha developer. There is no Koha developer out there who is developing Koha features just because they think it would be cool to do. Koha developers are doing their work because they *see* a need, in an actual user or an actual library. Or developers are getting paid by libraries to develop the features the libraries need.
Here's when users and developers are at opposite poles:
- When a company decides to develop a feature that they think will help sell a product, even though the feature doesn't meet any actual need - When a company throttles or cripples a feature in a product because they want to charge extra for a particular feature
No self-respecting Koha developer or Koha support company is doing that kind of stuff. That's why we're here.
I think this is more about giving the "users" more of a voice than they've traditionally had in the past, no?
I honestly don't know where this comes from. The Koha project is just about as open and accessible as any software project can be. You can participate on the mailing list, you can submit bug reports yourself, you can submit your own patches or hire your own programmers to write code for you. You can talk to Koha developers on IRC almost 24 hours a day!
The only way in which one might consider that users need "more of a voice" is if you think of it in terms of working collectively to achieve a goal that Koha libraries individually could not. If that's the intention of that statement then, rant over. I agree 100% that libraries should be seeking ways to pool their resources ($$) to get done the things they want done, i.e. hire developers or commission existing companies to do work for them.
However, if by "more of a voice" you mean, "If we all get together an ask for a feature the Koha developers should implement it," then no. This is open source, but time is money. You can donate your time (as I do, every day, in code, markup, email, and IRC) or you can donate your money--in the form of paid development work.
This doesn't shut anyone out. But yes, there is a bar that you have to clear. I don't know how else it can work.
So: Let's get together as users and/or developers and figure out how we can get some stuff done. Let's put together a structure by which Koha users can spec out new features and get them funded, collectively. Let's put together a structure by which Koha users can communicate with their vendors without fear of exclusion or reprisal. Let's not talk about a users group breaking down some barrier that isn't really there--let's talk about strengthening and leveraging the connection that we *already have!*
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- View this message in context: http://old.nabble.com/Re%3A-Users-and-developers-%28was-KUDOS---ALA-Proposed... Sent from the Koha - Discuss mailing list archive at Nabble.com.
David Schuster wrote: [...]
I hate confrontation and love constructive criticism - and am open for suggestions on how to make this work for the community in North America. I don't want to put people at opposite poles, but also must work within the regulations of the IRS. [...]
I think the IRS is pretty well-documented online, as is the non-profit law of quite a few states of the USA, so I know I don't know the law there, but I hope it's online. The IRS non-profit web homepage is http://www.irs.gov/charities/index.html?navmenu=menu1 but I didn't find the Pennsylvania Nonprofit Corporation Law online. What particular IRS regulation is motivating developer marginalisation? Some UK charities exclude workers from membership needlessly and I feel that's because someone misunderstood the limits on commercial activity. As long as the non-profit is clearly structured so it can't be used for tax evasion or other naughties, there shouldn't be a problem, should there? I'm pretty sure that KUDOS has got to answer the question of corporate membership anyway because many user libraries will be corporations rather than individual librarians, so can developer corporations be handled by the same protections?
I am open to suggestions on how we can get KUDOS up and running so as to function to benefit all of us. I see KUDOS as a major help in getting conferences to work, possible joint development/grant writing/managing - IMLS is always looking for collaborative ventures between various library types. WE ARE IT!
Open the membership, open the organisation, gather members, build consensus. Maybe when we've a bit more information, people can suggest or do more specific actions. Looking at the bylaws again for suggestions: I think there should also be a minimal activity requirement for good standing and an ability to refuse to renew members who are not in good standing. Otherwise, it is possible to become paralysed with idle members. Other failure cases I've seen are a present-but-idle majority on the board and a failure to organise board meetings or elections. It looks like http://kudos.koha.org/bylaws/ doesn't handle those yet either. It would be good to give the wider membership a last chance to regain control of the corporation legitimately, but I don't know how that sits with local laws. Hope that helps, -- MJ Ray (slef) Webmaster and LMS developer at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op
I appreciate all of the input on this topic so far. I would encourage even more North American users and developers to chime in. One of the decisions made at the KUDOS meeting was that we would not create a separate KUDOS list, but we would use koha-l to discuss KUDOS business. It was felt that we had nothing to hide from the community and the community might be interested. Hopefully this will be the case. Thanks, Vicki On Wed, Jan 20, 2010 at 5:03 AM, MJ Ray <mjr@phonecoop.coop> wrote:
David Schuster wrote: [...]
I hate confrontation and love constructive criticism - and am open for suggestions on how to make this work for the community in North America. I don't want to put people at opposite poles, but also must work within the regulations of the IRS. [...]
I think the IRS is pretty well-documented online, as is the non-profit law of quite a few states of the USA, so I know I don't know the law there, but I hope it's online. The IRS non-profit web homepage is http://www.irs.gov/charities/index.html?navmenu=menu1 but I didn't find the Pennsylvania Nonprofit Corporation Law online. What particular IRS regulation is motivating developer marginalisation?
Some UK charities exclude workers from membership needlessly and I feel that's because someone misunderstood the limits on commercial activity. As long as the non-profit is clearly structured so it can't be used for tax evasion or other naughties, there shouldn't be a problem, should there?
I'm pretty sure that KUDOS has got to answer the question of corporate membership anyway because many user libraries will be corporations rather than individual librarians, so can developer corporations be handled by the same protections?
I am open to suggestions on how we can get KUDOS up and running so as to function to benefit all of us. I see KUDOS as a major help in getting conferences to work, possible joint development/grant writing/managing - IMLS is always looking for collaborative ventures between various library types. WE ARE IT!
Open the membership, open the organisation, gather members, build consensus. Maybe when we've a bit more information, people can suggest or do more specific actions.
Looking at the bylaws again for suggestions: I think there should also be a minimal activity requirement for good standing and an ability to refuse to renew members who are not in good standing. Otherwise, it is possible to become paralysed with idle members.
Other failure cases I've seen are a present-but-idle majority on the board and a failure to organise board meetings or elections. It looks like http://kudos.koha.org/bylaws/ doesn't handle those yet either. It would be good to give the wider membership a last chance to regain control of the corporation legitimately, but I don't know how that sits with local laws.
Hope that helps, -- MJ Ray (slef) Webmaster and LMS developer at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Vicki Teal Lovely Helping our 52 member libraries provide the best possible service to the public. Software Applications Supervisor South Central Library System vtl@scls.lib.wi.us (608)242-4713
Again thanks for following through and making suggestions: http://www.irs.gov/charities/article/0,,id=139515,00.html - an article about having a policy to deal with conflict of interest. The concern for having the 501c3 exemption status pulled by the IRS was the concern. The board will have to put this policy together and submit it as well with the application. If KUDOS in the future does fund development we were trying to look long term and avoid conflict of interest through membership. It will be part of the board members duty(as volunteers) to provide diligence that the policy is maintained and followed. It is hard to anticipate how this will work so again it is hard to write when we haven't done it before. Again we are open for suggestions and comments! Keep them coming! David Schuster MJ Ray-2 wrote:
David Schuster wrote: [...]
I hate confrontation and love constructive criticism - and am open for suggestions on how to make this work for the community in North America. I don't want to put people at opposite poles, but also must work within the regulations of the IRS. [...]
I think the IRS is pretty well-documented online, as is the non-profit law of quite a few states of the USA, so I know I don't know the law there, but I hope it's online. The IRS non-profit web homepage is http://www.irs.gov/charities/index.html?navmenu=menu1 but I didn't find the Pennsylvania Nonprofit Corporation Law online. What particular IRS regulation is motivating developer marginalisation?
Some UK charities exclude workers from membership needlessly and I feel that's because someone misunderstood the limits on commercial activity. As long as the non-profit is clearly structured so it can't be used for tax evasion or other naughties, there shouldn't be a problem, should there?
I'm pretty sure that KUDOS has got to answer the question of corporate membership anyway because many user libraries will be corporations rather than individual librarians, so can developer corporations be handled by the same protections?
I am open to suggestions on how we can get KUDOS up and running so as to function to benefit all of us. I see KUDOS as a major help in getting conferences to work, possible joint development/grant writing/managing - IMLS is always looking for collaborative ventures between various library types. WE ARE IT!
Open the membership, open the organisation, gather members, build consensus. Maybe when we've a bit more information, people can suggest or do more specific actions.
Looking at the bylaws again for suggestions: I think there should also be a minimal activity requirement for good standing and an ability to refuse to renew members who are not in good standing. Otherwise, it is possible to become paralysed with idle members.
Other failure cases I've seen are a present-but-idle majority on the board and a failure to organise board meetings or elections. It looks like http://kudos.koha.org/bylaws/ doesn't handle those yet either. It would be good to give the wider membership a last chance to regain control of the corporation legitimately, but I don't know how that sits with local laws.
Hope that helps, -- MJ Ray (slef) Webmaster and LMS developer at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- View this message in context: http://old.nabble.com/Re%3A-Users-and-developers-%28was-KUDOS---ALA-Proposed... Sent from the Koha - Discuss mailing list archive at Nabble.com.
http://www.irs.gov/instructions/i1023/ar03.html - here is a sample of a conflict of interest policy from the IRS for discussion. David Schuster David Schuster wrote:
Again thanks for following through and making suggestions:
http://www.irs.gov/charities/article/0,,id=139515,00.html - an article about having a policy to deal with conflict of interest.
The concern for having the 501c3 exemption status pulled by the IRS was the concern. The board will have to put this policy together and submit it as well with the application.
If KUDOS in the future does fund development we were trying to look long term and avoid conflict of interest through membership.
It will be part of the board members duty(as volunteers) to provide diligence that the policy is maintained and followed. It is hard to anticipate how this will work so again it is hard to write when we haven't done it before. Again we are open for suggestions and comments! Keep them coming!
David Schuster
MJ Ray-2 wrote:
David Schuster wrote: [...]
I hate confrontation and love constructive criticism - and am open for suggestions on how to make this work for the community in North America. I don't want to put people at opposite poles, but also must work within the regulations of the IRS. [...]
I think the IRS is pretty well-documented online, as is the non-profit law of quite a few states of the USA, so I know I don't know the law there, but I hope it's online. The IRS non-profit web homepage is http://www.irs.gov/charities/index.html?navmenu=menu1 but I didn't find the Pennsylvania Nonprofit Corporation Law online. What particular IRS regulation is motivating developer marginalisation?
Some UK charities exclude workers from membership needlessly and I feel that's because someone misunderstood the limits on commercial activity. As long as the non-profit is clearly structured so it can't be used for tax evasion or other naughties, there shouldn't be a problem, should there?
I'm pretty sure that KUDOS has got to answer the question of corporate membership anyway because many user libraries will be corporations rather than individual librarians, so can developer corporations be handled by the same protections?
I am open to suggestions on how we can get KUDOS up and running so as to function to benefit all of us. I see KUDOS as a major help in getting conferences to work, possible joint development/grant writing/managing - IMLS is always looking for collaborative ventures between various library types. WE ARE IT!
Open the membership, open the organisation, gather members, build consensus. Maybe when we've a bit more information, people can suggest or do more specific actions.
Looking at the bylaws again for suggestions: I think there should also be a minimal activity requirement for good standing and an ability to refuse to renew members who are not in good standing. Otherwise, it is possible to become paralysed with idle members.
Other failure cases I've seen are a present-but-idle majority on the board and a failure to organise board meetings or elections. It looks like http://kudos.koha.org/bylaws/ doesn't handle those yet either. It would be good to give the wider membership a last chance to regain control of the corporation legitimately, but I don't know how that sits with local laws.
Hope that helps, -- MJ Ray (slef) Webmaster and LMS developer at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- View this message in context: http://old.nabble.com/Re%3A-Users-and-developers-%28was-KUDOS---ALA-Proposed... Sent from the Koha - Discuss mailing list archive at Nabble.com.
Hi all, On Wed, Jan 20, 2010 at 9:41 AM, David Schuster <dschust1@tx.rr.com> wrote:
http://www.irs.gov/instructions/i1023/ar03.html - here is a sample of a conflict of interest policy from the IRS for discussion.
As this is certainly not a new "problem," it seems to me that the thing to do here is to obtain the advice of a lawyer or CPA. I'm confident that many groups have dealt with this many times and there is little reason to agonize over the issue long. It may be that SFLC (http://www.softwarefreedom.org/) may be able to provide such advice. Kind Regards, Chris
Salvete!
Again thanks for following through and making suggestions:
http://www.irs.gov/charities/article/0,,id=139515,00.html - an article about having a policy to deal with conflict of interest. The concern for having the 501c3 exemption status pulled by the IRS was the concern. The board will have to put this policy together and submit it as well with the application. If KUDOS in the future does fund development we were trying to look long term and avoid conflict of interest through membership. It will be part of the board members duty(as volunteers) to provide diligence that the policy is maintained and followed. It is hard to anticipate how this will work so again it is hard to write when we haven't done it before. Again we are open for suggestions and comments! Keep them coming!
Bearing in mind that I'm not a lawyer, I personally think that you're being overly conservative in this concern at the expense of organisational development, which is a Librarian virtue. Clearly overcompensation is absolutely no concern to KUDOS since Board Members won't be paid. It's much more important to have a conflict of interest policy that says if a developer is sitting on the Board, they needs abstain if there's a possibility that they, a family member, a friend (you can take this list quite far) have a substantial financial interest in the matter before them (defining this would be a good idea, too.) It would be even better to have a recommended course of action, such that they declare, and abstain from discussion and voting. Have you visited www.globethics.net? There are a lot of lawyers out there that would love to help on such a small matter pro bono once plans are in place to give them an idea of how we want things to operate. The state in question has someone to help you, though the degree of help granted will probably vary. Contacting the IRS for guidance wouldn't hurt, either. They aren't unreasonable, and in a lot of cases it's not like it goes from you have status to YOINK! you just lost it. Cheers, Brooke
Hi David, I think it is important not to overreact to what happened with LL by making KUDOS a group to which developers are not welcome. Like Owen said, users becomes developer and the more access users and developers have to each other, the better. Excluding developers seems (at best) unnecessary and not at all straight-forward. At worst, it is creating a divide between two groups of participants in the Koha effort that we really don't want to have divided at all! Lori Non-user, Non-Developer, but Committed to the Use of Koha in NA Libraries Nonetheless On Tue, Jan 19, 2010 at 7:43 PM, David Schuster <dschust1@tx.rr.com> wrote:
As one of the individuals that is ATTEMPTING to put some structure to this and get it off the ground I would love suggestions on how to make this work for the community.
I hate confrontation and love constructive criticism - and am open for suggestions on how to make this work for the community in North America. I don't want to put people at opposite poles, but also must work within the regulations of the IRS.
I am open to suggestions on how we can get KUDOS up and running so as to function to benefit all of us. I see KUDOS as a major help in getting conferences to work, possible joint development/grant writing/managing - IMLS is always looking for collaborative ventures between various library types. WE ARE IT!
I don't mind rants, I don't mind listening, but help me build the structure so that we can work and move forward. What specifically do you suggest to make this work and stay away from the proprietary user group structure.
Trying our best to get it right.
David Schuster - don't shoot the messenger if you don't like the way it looks - help us out as libraries are known to do so well. HELP each other.
Owen Leonard-4 wrote:
Okay, get ready for a rant...
Sometimes "users" and "developers" are at opposite poles...
When? I'm a Koha user. And in using Koha I saw that I could make Koha better, and in time became a Koha developer. There is no Koha developer out there who is developing Koha features just because they think it would be cool to do. Koha developers are doing their work because they *see* a need, in an actual user or an actual library. Or developers are getting paid by libraries to develop the features the libraries need.
Here's when users and developers are at opposite poles:
- When a company decides to develop a feature that they think will help sell a product, even though the feature doesn't meet any actual need - When a company throttles or cripples a feature in a product because they want to charge extra for a particular feature
No self-respecting Koha developer or Koha support company is doing that kind of stuff. That's why we're here.
I think this is more about giving the "users" more of a voice than they've traditionally had in the past, no?
I honestly don't know where this comes from. The Koha project is just about as open and accessible as any software project can be. You can participate on the mailing list, you can submit bug reports yourself, you can submit your own patches or hire your own programmers to write code for you. You can talk to Koha developers on IRC almost 24 hours a day!
The only way in which one might consider that users need "more of a voice" is if you think of it in terms of working collectively to achieve a goal that Koha libraries individually could not. If that's the intention of that statement then, rant over. I agree 100% that libraries should be seeking ways to pool their resources ($$) to get done the things they want done, i.e. hire developers or commission existing companies to do work for them.
However, if by "more of a voice" you mean, "If we all get together an ask for a feature the Koha developers should implement it," then no. This is open source, but time is money. You can donate your time (as I do, every day, in code, markup, email, and IRC) or you can donate your money--in the form of paid development work.
This doesn't shut anyone out. But yes, there is a bar that you have to clear. I don't know how else it can work.
So: Let's get together as users and/or developers and figure out how we can get some stuff done. Let's put together a structure by which Koha users can spec out new features and get them funded, collectively. Let's put together a structure by which Koha users can communicate with their vendors without fear of exclusion or reprisal. Let's not talk about a users group breaking down some barrier that isn't really there--let's talk about strengthening and leveraging the connection that we *already have!*
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- View this message in context: http://old.nabble.com/Re%3A-Users-and-developers-%28was-KUDOS---ALA-Proposed... Sent from the Koha - Discuss mailing list archive at Nabble.com.
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Owen, MJ. Et. Al. Didn't mean to start a minor controversy amongst the list. Let me clarify what I meant. Where I see developers and users at odds (or, a "disconnect, if you will), is in the Request for Code Development process. Right now, we are all operating like little "islands" where each library goes through a long "planning process" in which each library decides what features that they absolutely need to see in Koha to operate daily and meet their patron's needs. Now, much development currently needed, which is not yet committed, is very redundant, and what I'm trying to suggest is that we all don't spend (and waste) time trying to re-invent the same wheel. Also, we can't really know what others are planning right now for KOHA without communicating to them, before the RFC process. I see KUDOS as a place where libraries can meet and discuss the code that they are "planning" to sponsor, before submitting to Bugzilla (brrr..) ,or the Koha Wiki, so code development can be leveraged before being submitted, thereby making the process more stream-lined and efficient. Am I saying that developer's should be excluded from this process? Absolutely not. Am I saying that a KOHA USERS group is an excellent vehicle for the USERS to communicate and further leverage the planning process and development thereby making KOHA better. Absolutely. That is my take on the value of a "USERS" group in KOHA. If I am wrong, then, have at me.... Scott Kushner Information Technologies Middletown Public Library -----Original Message----- From: koha-bounces@lists.katipo.co.nz [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of Owen Leonard Sent: Tuesday, January 19, 2010 7:59 PM To: koha@lists.katipo.co.nz Subject: Re: [Koha] Users and developers (was KUDOS - ALA Proposed Agenda) Okay, get ready for a rant...
Sometimes "users" and "developers" are at opposite poles...
I think this is more about giving the "users" more of a voice than
When? I'm a Koha user. And in using Koha I saw that I could make Koha better, and in time became a Koha developer. There is no Koha developer out there who is developing Koha features just because they think it would be cool to do. Koha developers are doing their work because they *see* a need, in an actual user or an actual library. Or developers are getting paid by libraries to develop the features the libraries need. Here's when users and developers are at opposite poles: - When a company decides to develop a feature that they think will help sell a product, even though the feature doesn't meet any actual need - When a company throttles or cripples a feature in a product because they want to charge extra for a particular feature No self-respecting Koha developer or Koha support company is doing that kind of stuff. That's why we're here. they've traditionally had in
the past, no?
I honestly don't know where this comes from. The Koha project is just about as open and accessible as any software project can be. You can participate on the mailing list, you can submit bug reports yourself, you can submit your own patches or hire your own programmers to write code for you. You can talk to Koha developers on IRC almost 24 hours a day! The only way in which one might consider that users need "more of a voice" is if you think of it in terms of working collectively to achieve a goal that Koha libraries individually could not. If that's the intention of that statement then, rant over. I agree 100% that libraries should be seeking ways to pool their resources ($$) to get done the things they want done, i.e. hire developers or commission existing companies to do work for them. However, if by "more of a voice" you mean, "If we all get together an ask for a feature the Koha developers should implement it," then no. This is open source, but time is money. You can donate your time (as I do, every day, in code, markup, email, and IRC) or you can donate your money--in the form of paid development work. This doesn't shut anyone out. But yes, there is a bar that you have to clear. I don't know how else it can work. So: Let's get together as users and/or developers and figure out how we can get some stuff done. Let's put together a structure by which Koha users can spec out new features and get them funded, collectively. Let's put together a structure by which Koha users can communicate with their vendors without fear of exclusion or reprisal. Let's not talk about a users group breaking down some barrier that isn't really there--let's talk about strengthening and leveraging the connection that we *already have!* -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Hi All 2010/1/22 Scott Kushner <skushner@mtpl.org>:
Owen, MJ. Et. Al.
Didn't mean to start a minor controversy amongst the list. Let me clarify what I meant.
Where I see developers and users at odds (or, a "disconnect, if you will), is in the Request for Code Development process. Right now, we are all operating like little "islands" where each library goes through a long "planning process" in which each library decides what features that they absolutely need to see in Koha to operate daily and meet their patron's needs. Now, much development currently needed, which is not yet committed, is very redundant, and what I'm trying to suggest is that we all don't spend (and waste) time trying to re-invent the same wheel. Also, we can't really know what others are planning right now for KOHA without communicating to them, before the RFC process.
Ahh I think this is where the problem is. The RFC shouldn't be the last thing you do. RFC or a enhancement bug in bugzilla should be the first thing you do. IE before you start planning, before you spec out solutions before you start any real work of any kind, you should let the rest of the Koha (its a maori word, not an acronym : a pet peeve of mine, feel free to ignore it :)) world know that you are even thinking of doing so.
I see KUDOS as a place where libraries can meet and discuss the code that they are "planning" to sponsor, before submitting to Bugzilla (brrr..) ,or the Koha Wiki, so code development can be leveraged before being submitted, thereby making the process more stream-lined and efficient.
Yeah, I think that if people aren't submitting to bugzilla or the wiki before development is done, we are doing it wrong.
Am I saying that developer's should be excluded from this process? Absolutely not.
Am I saying that a KOHA USERS group is an excellent vehicle for the USERS to communicate and further leverage the planning process and development thereby making KOHA better. Absolutely.
That is my take on the value of a "USERS" group in KOHA.
If I am wrong, then, have at me....
I think KUDOS is a good idea, and as a place to pool ideas and resources together for North American libraries it seems great. I fear though, if the wider community is not informed early, we will still have redundancy. IE Libraries and other users and other developers need to let each other know, before any real planning takes place. While KUDOS can do this for North American libraries, it still needs to inform the rest of the world as early as possible, otherwise we are only slightly reducing double up. For about the last 7 months around 85% (hundreds of patcheds) of the development has been done from people outside the US, so I think that it is important (and I know people have thought of this already) that KUDOS has an efficient and effective means of communicating early and often to the rest of the world. And finally, I don't see this as a controversy, and I don't see reasoned debate/discourse as a problem either. I think this is how the community used to, and should work again. Let's talk in the open, no more cabal, no more back room deals. Open and honest is how the community was, let's bring that back. Chris (Who has spent 4 days at linux.conf.au having his batteries recharged)
Hi All, As some of you know I'm involved as a consultant with both Koha and Evergreen projects. One of the things that is being pursued by King County Library System as part of the IMLS grant they received is the development of an Enhancement Database. The RFP is going to be "on the street" soon. The concept is to create an online venue and set of tools to help people find out what others are doing with development and to find out what they WANT to do so they can chime in or join up in some way. Whatever is created could certainly be used by either project as it will not be Evergreen centric in any way (except possibly in the way that it relates to the Equinox team's development environment - since we're specifying that the product should be able to export specs to the development team once they've been accepted and funded ...or something). Anyway, just wanted to alert you to that. I'll post it to this list (if you like) as soon as it is released (the RFP that is). Lori On Thu, Jan 21, 2010 at 9:32 AM, Scott Kushner <skushner@mtpl.org> wrote:
Owen, MJ. Et. Al.
Didn't mean to start a minor controversy amongst the list. Let me clarify what I meant.
Where I see developers and users at odds (or, a "disconnect, if you will), is in the Request for Code Development process. Right now, we are all operating like little "islands" where each library goes through a long "planning process" in which each library decides what features that they absolutely need to see in Koha to operate daily and meet their patron's needs. Now, much development currently needed, which is not yet committed, is very redundant, and what I'm trying to suggest is that we all don't spend (and waste) time trying to re-invent the same wheel. Also, we can't really know what others are planning right now for KOHA without communicating to them, before the RFC process.
I see KUDOS as a place where libraries can meet and discuss the code that they are "planning" to sponsor, before submitting to Bugzilla (brrr..) ,or the Koha Wiki, so code development can be leveraged before being submitted, thereby making the process more stream-lined and efficient.
Am I saying that developer's should be excluded from this process? Absolutely not.
Am I saying that a KOHA USERS group is an excellent vehicle for the USERS to communicate and further leverage the planning process and development thereby making KOHA better. Absolutely.
That is my take on the value of a "USERS" group in KOHA.
If I am wrong, then, have at me....
Scott Kushner Information Technologies Middletown Public Library -----Original Message----- From: koha-bounces@lists.katipo.co.nz [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of Owen Leonard Sent: Tuesday, January 19, 2010 7:59 PM To: koha@lists.katipo.co.nz Subject: Re: [Koha] Users and developers (was KUDOS - ALA Proposed Agenda)
Okay, get ready for a rant...
Sometimes "users" and "developers" are at opposite poles...
When? I'm a Koha user. And in using Koha I saw that I could make Koha better, and in time became a Koha developer. There is no Koha developer out there who is developing Koha features just because they think it would be cool to do. Koha developers are doing their work because they *see* a need, in an actual user or an actual library. Or developers are getting paid by libraries to develop the features the libraries need.
Here's when users and developers are at opposite poles:
- When a company decides to develop a feature that they think will help sell a product, even though the feature doesn't meet any actual need - When a company throttles or cripples a feature in a product because they want to charge extra for a particular feature
No self-respecting Koha developer or Koha support company is doing that kind of stuff. That's why we're here.
I think this is more about giving the "users" more of a voice than they've traditionally had in the past, no?
I honestly don't know where this comes from. The Koha project is just about as open and accessible as any software project can be. You can participate on the mailing list, you can submit bug reports yourself, you can submit your own patches or hire your own programmers to write code for you. You can talk to Koha developers on IRC almost 24 hours a day!
The only way in which one might consider that users need "more of a voice" is if you think of it in terms of working collectively to achieve a goal that Koha libraries individually could not. If that's the intention of that statement then, rant over. I agree 100% that libraries should be seeking ways to pool their resources ($$) to get done the things they want done, i.e. hire developers or commission existing companies to do work for them.
However, if by "more of a voice" you mean, "If we all get together an ask for a feature the Koha developers should implement it," then no. This is open source, but time is money. You can donate your time (as I do, every day, in code, markup, email, and IRC) or you can donate your money--in the form of paid development work.
This doesn't shut anyone out. But yes, there is a bar that you have to clear. I don't know how else it can work.
So: Let's get together as users and/or developers and figure out how we can get some stuff done. Let's put together a structure by which Koha users can spec out new features and get them funded, collectively. Let's put together a structure by which Koha users can communicate with their vendors without fear of exclusion or reprisal. Let's not talk about a users group breaking down some barrier that isn't really there--let's talk about strengthening and leveraging the connection that we *already have!*
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
On 1/21/10, Lori Ayre <loriayre@gmail.com> wrote:
Hi All,
As some of you know I'm involved as a consultant with both Koha and Evergreen projects. One of the things that is being pursued by King County Library System as part of the IMLS grant they received is the development of an Enhancement Database.
Isn't this functionality in Bugzilla? Kind Regards, Chris
A lot of it is indeed in Bugzilla (and perhaps more of it even that we know) but the idea was to make this very user friendly and to make it possible for people to contribute funding to enhancements, to claim themselves as lead sponsor, to vote on the desirability of the feature...that sort of thing. Conceptually, it was more for the end users to use to organize themselves before they pass it off to developers to actually begin doing something with it. Lori On Thu, Jan 21, 2010 at 3:00 PM, Chris Nighswonger < cnighswonger@foundations.edu> wrote:
On 1/21/10, Lori Ayre <loriayre@gmail.com> wrote:
Hi All,
As some of you know I'm involved as a consultant with both Koha and Evergreen projects. One of the things that is being pursued by King County Library System as part of the IMLS grant they received is the development of an Enhancement Database.
Isn't this functionality in Bugzilla?
Kind Regards, Chris
Hi Lori, My pre-RFP thoughts follow. On Thu, Jan 21, 2010 at 6:04 PM, Lori Ayre <loriayre@gmail.com> wrote:
A lot of it is indeed in Bugzilla (and perhaps more of it even that we know) but the idea was to make this very user friendly and to make it possible for people to contribute funding to enhancements, to claim themselves as lead sponsor, to vote on the desirability of the feature...that sort of thing.
Take a look at this bugzilla screenshot: http://www.screencast.com/t/ZGY5OTJiYjIt You will notice a section for indicating sponsorship. There are currently three options: Seeking Cosponsors, Seeking Developer, and Sponsored. I think more options could be added. This shot misses it, but just down the page in the right sidebar labeled 'Related Actions' there is an option to vote for this bug/enhancement as well as in indication of the current votes cast for this bug/enhancement. You can also see that bugzilla allows for the tracking of time invested in the particular bug/enhancement. I believe there are other features available which can be switched on or off in the configuration. I think it would also be possible to write a different (perhaps more friendly) interface for those who find the default interface unappealing or confusing. In my opinion that might be less expensive and reduce the possibility of introducing another impedance point between librarians and developers which might otherwise (though unintentionally) be caused by having two different tracking systems. Kind Regards, Chris
On Thu, Jan 21, 2010 at 3:00 PM, Chris Nighswonger <cnighswonger@foundations.edu> wrote:
On 1/21/10, Lori Ayre <loriayre@gmail.com> wrote:
Hi All,
As some of you know I'm involved as a consultant with both Koha and Evergreen projects. One of the things that is being pursued by King County Library System as part of the IMLS grant they received is the development of an Enhancement Database.
Isn't this functionality in Bugzilla?
Kind Regards, Chris
Hi Lori, My understanding is that is what Bugzilla is designed to manage. Are you suggesting this replaces bugzilla as the official Koha enhancement and bug database? As a user I really don't want to have to go to 2 different places, and I am sure we are all aware of the strong feelings around forking Koha, not juist the code here but the community tools which support the code. Cheers Jo. Lori Ayre wrote:
Hi All,
As some of you know I'm involved as a consultant with both Koha and Evergreen projects. One of the things that is being pursued by King County Library System as part of the IMLS grant they received is the development of an Enhancement Database. The RFP is going to be "on the street" soon. The concept is to create an online venue and set of tools to help people find out what others are doing with development and to find out what they WANT to do so they can chime in or join up in some way.
Whatever is created could certainly be used by either project as it will not be Evergreen centric in any way (except possibly in the way that it relates to the Equinox team's development environment - since we're specifying that the product should be able to export specs to the development team once they've been accepted and funded ...or something).
Anyway, just wanted to alert you to that. I'll post it to this list (if you like) as soon as it is released (the RFP that is).
Lori
On Thu, Jan 21, 2010 at 9:32 AM, Scott Kushner <skushner@mtpl.org <mailto:skushner@mtpl.org>> wrote:
Owen, MJ. Et. Al.
Didn't mean to start a minor controversy amongst the list. Let me clarify what I meant.
Where I see developers and users at odds (or, a "disconnect, if you will), is in the Request for Code Development process. Right now, we are all operating like little "islands" where each library goes through a long "planning process" in which each library decides what features that they absolutely need to see in Koha to operate daily and meet their patron's needs. Now, much development currently needed, which is not yet committed, is very redundant, and what I'm trying to suggest is that we all don't spend (and waste) time trying to re-invent the same wheel. Also, we can't really know what others are planning right now for KOHA without communicating to them, before the RFC process.
I see KUDOS as a place where libraries can meet and discuss the code that they are "planning" to sponsor, before submitting to Bugzilla (brrr..) ,or the Koha Wiki, so code development can be leveraged before being submitted, thereby making the process more stream-lined and efficient.
Am I saying that developer's should be excluded from this process? Absolutely not.
Am I saying that a KOHA USERS group is an excellent vehicle for the USERS to communicate and further leverage the planning process and development thereby making KOHA better. Absolutely.
That is my take on the value of a "USERS" group in KOHA.
If I am wrong, then, have at me....
Scott Kushner Information Technologies Middletown Public Library -----Original Message----- From: koha-bounces@lists.katipo.co.nz <mailto:koha-bounces@lists.katipo.co.nz> [mailto:koha-bounces@lists.katipo.co.nz <mailto:koha-bounces@lists.katipo.co.nz>] On Behalf Of Owen Leonard Sent: Tuesday, January 19, 2010 7:59 PM To: koha@lists.katipo.co.nz <mailto:koha@lists.katipo.co.nz> Subject: Re: [Koha] Users and developers (was KUDOS - ALA Proposed Agenda)
Okay, get ready for a rant...
> Sometimes "users" and "developers" are at opposite poles...
When? I'm a Koha user. And in using Koha I saw that I could make Koha better, and in time became a Koha developer. There is no Koha developer out there who is developing Koha features just because they think it would be cool to do. Koha developers are doing their work because they *see* a need, in an actual user or an actual library. Or developers are getting paid by libraries to develop the features the libraries need.
Here's when users and developers are at opposite poles:
- When a company decides to develop a feature that they think will help sell a product, even though the feature doesn't meet any actual need - When a company throttles or cripples a feature in a product because they want to charge extra for a particular feature
No self-respecting Koha developer or Koha support company is doing that kind of stuff. That's why we're here.
> I think this is more about giving the "users" more of a voice than they've traditionally had in > the past, no?
I honestly don't know where this comes from. The Koha project is just about as open and accessible as any software project can be. You can participate on the mailing list, you can submit bug reports yourself, you can submit your own patches or hire your own programmers to write code for you. You can talk to Koha developers on IRC almost 24 hours a day!
The only way in which one might consider that users need "more of a voice" is if you think of it in terms of working collectively to achieve a goal that Koha libraries individually could not. If that's the intention of that statement then, rant over. I agree 100% that libraries should be seeking ways to pool their resources ($$) to get done the things they want done, i.e. hire developers or commission existing companies to do work for them.
However, if by "more of a voice" you mean, "If we all get together an ask for a feature the Koha developers should implement it," then no. This is open source, but time is money. You can donate your time (as I do, every day, in code, markup, email, and IRC) or you can donate your money--in the form of paid development work.
This doesn't shut anyone out. But yes, there is a bar that you have to clear. I don't know how else it can work.
So: Let's get together as users and/or developers and figure out how we can get some stuff done. Let's put together a structure by which Koha users can spec out new features and get them funded, collectively. Let's put together a structure by which Koha users can communicate with their vendors without fear of exclusion or reprisal. Let's not talk about a users group breaking down some barrier that isn't really there--let's talk about strengthening and leveraging the connection that we *already have!*
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz <mailto:Koha@lists.katipo.co.nz> http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz <mailto:Koha@lists.katipo.co.nz> http://lists.katipo.co.nz/mailman/listinfo/koha
------------------------------------------------------------------------
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Could be it isn't a good fit for the Koha community. As I said, it is designed to fill a need for Evergreen which isn't currently using anything like this. But even if no one here thinks it makes sense for Koha, perhaps someone could respond to the RFP with a Bugzilla-based solution! That would be welcome. Lori On Thu, Jan 21, 2010 at 3:03 PM, Joann Ransom <jransom@library.org.nz>wrote:
Hi Lori,
My understanding is that is what Bugzilla is designed to manage. Are you suggesting this replaces bugzilla as the official Koha enhancement and bug database? As a user I really don't want to have to go to 2 different places, and I am sure we are all aware of the strong feelings around forking Koha, not juist the code here but the community tools which support the code.
Cheers Jo.
Lori Ayre wrote:
Hi All,
As some of you know I'm involved as a consultant with both Koha and Evergreen projects. One of the things that is being pursued by King County Library System as part of the IMLS grant they received is the development of an Enhancement Database. The RFP is going to be "on the street" soon. The concept is to create an online venue and set of tools to help people find out what others are doing with development and to find out what they WANT to do so they can chime in or join up in some way. Whatever is created could certainly be used by either project as it will not be Evergreen centric in any way (except possibly in the way that it relates to the Equinox team's development environment - since we're specifying that the product should be able to export specs to the development team once they've been accepted and funded ...or something). Anyway, just wanted to alert you to that. I'll post it to this list (if you like) as soon as it is released (the RFP that is).
Lori
On Thu, Jan 21, 2010 at 9:32 AM, Scott Kushner <skushner@mtpl.org<mailto: skushner@mtpl.org>> wrote:
Owen, MJ. Et. Al.
Didn't mean to start a minor controversy amongst the list. Let me clarify what I meant.
Where I see developers and users at odds (or, a "disconnect, if you will), is in the Request for Code Development process. Right now, we are all operating like little "islands" where each library goes through a long "planning process" in which each library decides what features that they absolutely need to see in Koha to operate daily and meet their patron's needs. Now, much development currently needed, which is not yet committed, is very redundant, and what I'm trying to suggest is that we all don't spend (and waste) time trying to re-invent the same wheel. Also, we can't really know what others are planning right now for KOHA without communicating to them, before the RFC process.
I see KUDOS as a place where libraries can meet and discuss the code that they are "planning" to sponsor, before submitting to Bugzilla (brrr..) ,or the Koha Wiki, so code development can be leveraged before being submitted, thereby making the process more stream-lined and efficient.
Am I saying that developer's should be excluded from this process? Absolutely not.
Am I saying that a KOHA USERS group is an excellent vehicle for the USERS to communicate and further leverage the planning process and development thereby making KOHA better. Absolutely.
That is my take on the value of a "USERS" group in KOHA.
If I am wrong, then, have at me....
Scott Kushner Information Technologies Middletown Public Library -----Original Message----- From: koha-bounces@lists.katipo.co.nz <mailto:koha-bounces@lists.katipo.co.nz> [mailto:koha-bounces@lists.katipo.co.nz <mailto:koha-bounces@lists.katipo.co.nz>] On Behalf Of Owen Leonard Sent: Tuesday, January 19, 2010 7:59 PM To: koha@lists.katipo.co.nz <mailto:koha@lists.katipo.co.nz> Subject: Re: [Koha] Users and developers (was KUDOS - ALA Proposed Agenda)
Okay, get ready for a rant...
Sometimes "users" and "developers" are at opposite poles...
When? I'm a Koha user. And in using Koha I saw that I could make Koha better, and in time became a Koha developer. There is no Koha developer out there who is developing Koha features just because they think it would be cool to do. Koha developers are doing their work because they *see* a need, in an actual user or an actual library. Or developers are getting paid by libraries to develop the features the libraries need.
Here's when users and developers are at opposite poles:
- When a company decides to develop a feature that they think will help sell a product, even though the feature doesn't meet any actual need - When a company throttles or cripples a feature in a product because they want to charge extra for a particular feature
No self-respecting Koha developer or Koha support company is doing that kind of stuff. That's why we're here.
I think this is more about giving the "users" more of a voice than they've traditionally had in the past, no?
I honestly don't know where this comes from. The Koha project is just about as open and accessible as any software project can be. You can participate on the mailing list, you can submit bug reports yourself, you can submit your own patches or hire your own programmers to write code for you. You can talk to Koha developers on IRC almost 24 hours a day!
The only way in which one might consider that users need "more of a voice" is if you think of it in terms of working collectively to achieve a goal that Koha libraries individually could not. If that's the intention of that statement then, rant over. I agree 100% that libraries should be seeking ways to pool their resources ($$) to get done the things they want done, i.e. hire developers or commission existing companies to do work for them.
However, if by "more of a voice" you mean, "If we all get together an ask for a feature the Koha developers should implement it," then no. This is open source, but time is money. You can donate your time (as I do, every day, in code, markup, email, and IRC) or you can donate your money--in the form of paid development work.
This doesn't shut anyone out. But yes, there is a bar that you have to clear. I don't know how else it can work.
So: Let's get together as users and/or developers and figure out how we can get some stuff done. Let's put together a structure by which Koha users can spec out new features and get them funded, collectively. Let's put together a structure by which Koha users can communicate with their vendors without fear of exclusion or reprisal. Let's not talk about a users group breaking down some barrier that isn't really there--let's talk about strengthening and leveraging the connection that we *already have!*
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz <mailto:Koha@lists.katipo.co.nz>
http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz <mailto:Koha@lists.katipo.co.nz>
http://lists.katipo.co.nz/mailman/listinfo/koha
------------------------------------------------------------------------
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
I would like to say that I am in favor of pursuing this in one way or another. I do feel that bugzilla is more of a developer's tool. Yes, I do agree that we should check there to see if an enhancement has been suggested before we do anything else. But, for the purposes of pursuing shared development I think another type of tool may be needed. One that is intended for that purpose. If bugzilla could become that tool, then someone should reply to the RFP as Lori suggests. But I think we would be foolish to completely ignore the opportunity we are being offered to participate in this grant along with the Evergreen users. What could be more open source than that? 2010/1/21 Lori Ayre <loriayre@gmail.com>
Could be it isn't a good fit for the Koha community. As I said, it is designed to fill a need for Evergreen which isn't currently using anything like this. But even if no one here thinks it makes sense for Koha, perhaps someone could respond to the RFP with a Bugzilla-based solution! That would be welcome.
Lori
On Thu, Jan 21, 2010 at 3:03 PM, Joann Ransom <jransom@library.org.nz>wrote:
Hi Lori,
My understanding is that is what Bugzilla is designed to manage. Are you suggesting this replaces bugzilla as the official Koha enhancement and bug database? As a user I really don't want to have to go to 2 different places, and I am sure we are all aware of the strong feelings around forking Koha, not juist the code here but the community tools which support the code.
Cheers Jo.
Lori Ayre wrote:
Hi All,
As some of you know I'm involved as a consultant with both Koha and Evergreen projects. One of the things that is being pursued by King County Library System as part of the IMLS grant they received is the development of an Enhancement Database. The RFP is going to be "on the street" soon. The concept is to create an online venue and set of tools to help people find out what others are doing with development and to find out what they WANT to do so they can chime in or join up in some way. Whatever is created could certainly be used by either project as it will not be Evergreen centric in any way (except possibly in the way that it relates to the Equinox team's development environment - since we're specifying that the product should be able to export specs to the development team once they've been accepted and funded ...or something). Anyway, just wanted to alert you to that. I'll post it to this list (if you like) as soon as it is released (the RFP that is).
Lori
On Thu, Jan 21, 2010 at 9:32 AM, Scott Kushner <skushner@mtpl.org<mailto: skushner@mtpl.org>> wrote:
Owen, MJ. Et. Al.
Didn't mean to start a minor controversy amongst the list. Let me clarify what I meant.
Where I see developers and users at odds (or, a "disconnect, if you will), is in the Request for Code Development process. Right now, we are all operating like little "islands" where each library goes through a long "planning process" in which each library decides what features that they absolutely need to see in Koha to operate daily and meet their patron's needs. Now, much development currently needed, which is not yet committed, is very redundant, and what I'm trying to suggest is that we all don't spend (and waste) time trying to re-invent the same wheel. Also, we can't really know what others are planning right now for KOHA without communicating to them, before the RFC process.
I see KUDOS as a place where libraries can meet and discuss the code that they are "planning" to sponsor, before submitting to Bugzilla (brrr..) ,or the Koha Wiki, so code development can be leveraged before being submitted, thereby making the process more stream-lined and efficient.
Am I saying that developer's should be excluded from this process? Absolutely not.
Am I saying that a KOHA USERS group is an excellent vehicle for the USERS to communicate and further leverage the planning process and development thereby making KOHA better. Absolutely.
That is my take on the value of a "USERS" group in KOHA.
If I am wrong, then, have at me....
Scott Kushner Information Technologies Middletown Public Library -----Original Message----- From: koha-bounces@lists.katipo.co.nz <mailto:koha-bounces@lists.katipo.co.nz> [mailto:koha-bounces@lists.katipo.co.nz <mailto:koha-bounces@lists.katipo.co.nz>] On Behalf Of Owen Leonard Sent: Tuesday, January 19, 2010 7:59 PM To: koha@lists.katipo.co.nz <mailto:koha@lists.katipo.co.nz> Subject: Re: [Koha] Users and developers (was KUDOS - ALA Proposed Agenda)
Okay, get ready for a rant...
Sometimes "users" and "developers" are at opposite poles...
When? I'm a Koha user. And in using Koha I saw that I could make Koha better, and in time became a Koha developer. There is no Koha developer out there who is developing Koha features just because they think it would be cool to do. Koha developers are doing their work because they *see* a need, in an actual user or an actual library. Or developers are getting paid by libraries to develop the features the libraries need.
Here's when users and developers are at opposite poles:
- When a company decides to develop a feature that they think will help sell a product, even though the feature doesn't meet any actual need - When a company throttles or cripples a feature in a product because they want to charge extra for a particular feature
No self-respecting Koha developer or Koha support company is doing that kind of stuff. That's why we're here.
I think this is more about giving the "users" more of a voice than they've traditionally had in the past, no?
I honestly don't know where this comes from. The Koha project is just about as open and accessible as any software project can be. You can participate on the mailing list, you can submit bug reports yourself, you can submit your own patches or hire your own programmers to write code for you. You can talk to Koha developers on IRC almost 24 hours a day!
The only way in which one might consider that users need "more of a voice" is if you think of it in terms of working collectively to achieve a goal that Koha libraries individually could not. If that's the intention of that statement then, rant over. I agree 100% that libraries should be seeking ways to pool their resources ($$) to get done the things they want done, i.e. hire developers or commission existing companies to do work for them.
However, if by "more of a voice" you mean, "If we all get together an ask for a feature the Koha developers should implement it," then no. This is open source, but time is money. You can donate your time (as I do, every day, in code, markup, email, and IRC) or you can donate your money--in the form of paid development work.
This doesn't shut anyone out. But yes, there is a bar that you have to clear. I don't know how else it can work.
So: Let's get together as users and/or developers and figure out how we can get some stuff done. Let's put together a structure by which Koha users can spec out new features and get them funded, collectively. Let's put together a structure by which Koha users can communicate with their vendors without fear of exclusion or reprisal. Let's not talk about a users group breaking down some barrier that isn't really there--let's talk about strengthening and leveraging the connection that we *already have!*
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz <mailto:Koha@lists.katipo.co.nz>
http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz <mailto:Koha@lists.katipo.co.nz>
http://lists.katipo.co.nz/mailman/listinfo/koha
------------------------------------------------------------------------
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Vicki Teal Lovely Helping our 52 member libraries provide the best possible service to the public. Software Applications Supervisor South Central Library System vtl@scls.lib.wi.us (608)242-4713
2010/1/21 Lori Ayre <loriayre@gmail.com>:
Could be it isn't a good fit for the Koha community. As I said, it is designed to fill a need for Evergreen which isn't currently using anything like this. But even if no one here thinks it makes sense for Koha, perhaps someone could respond to the RFP with a Bugzilla-based solution! That would be welcome.
Actually, the Evergreen community is in a trial period of using LaunchPad (http://launchpad.net/evergreen) for many of these purposes (bugs, blueprints for future developments, for indicating interest in a particular bug or feature, translations, etc). LaunchPad doesn't have a formalized interface for "sponsorship claiming" or a funding model attached to it, but to be frank KCLS runs the risk of investing lots of money in developing a solution to a problem that the rest of the Evergreen community isn't interested in. I guess we'll have to wait and see what they come up with and evaluate it then. In the meantime, the LaunchPad experiment continues. -- Dan Scott Laurentian University
Ah. Thanks for the information Dan. On Sat, Jan 23, 2010 at 8:43 PM, Dan Scott <denials@gmail.com> wrote:
Could be it isn't a good fit for the Koha community. As I said, it is designed to fill a need for Evergreen which isn't currently using anything like this. But even if no one here thinks it makes sense for Koha,
2010/1/21 Lori Ayre <loriayre@gmail.com>: perhaps
someone could respond to the RFP with a Bugzilla-based solution! That would be welcome.
Actually, the Evergreen community is in a trial period of using LaunchPad (http://launchpad.net/evergreen) for many of these purposes (bugs, blueprints for future developments, for indicating interest in a particular bug or feature, translations, etc). LaunchPad doesn't have a formalized interface for "sponsorship claiming" or a funding model attached to it, but to be frank KCLS runs the risk of investing lots of money in developing a solution to a problem that the rest of the Evergreen community isn't interested in.
I guess we'll have to wait and see what they come up with and evaluate it then. In the meantime, the LaunchPad experiment continues.
-- Dan Scott Laurentian University _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Vicki Teal Lovely Helping our 52 member libraries provide the best possible service to the public. Software Applications Supervisor South Central Library System vtl@scls.lib.wi.us (608)242-4713
Dan Scott <denials@gmail.com>
Actually, the Evergreen community is in a trial period of using LaunchPad (http://launchpad.net/evergreen) for many of these purposes
Would you believe that I decided against replying earlier in the thread that the last thing the world needs is another repeat of the Launchpad problem which gives everyone Yet Another website to check for bugs? So I'm pretty disappointed to see Launchpad appear here. It is more of a black hole than a tool, in that it tries to track everyone and draw them into using it. Launchpad.net has claimed that I am a member twice, even though I have never agreed to membership. I get a bit annoyed about such silly failures to respect people's basic rights. Whatever is chosen, please can it be something which at least gives people the freedom to choose whether or not to associate? Voluntary membership is not only a cooperative principle, it's even in the UDHR. Of course, bugzilla has a related drawback in that most site configurations don't allow you to contribute if you choose not to associate. That's better than Launchpad in that you do have a choice, but a front-end could address that problem, as well as being more user-friendly. Going back more widely for a moment: yes, it would be great if a user group allows users to discuss RFPs and so on, but that wouldn't justify restricting developers in a USERS AND DEVELOPERS group. I await to see how KUDOS develops with interest. Hopa that explains, -- MJ Ray (slef) Webmaster and LMS developer at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op
MJ said: Going back more widely for a moment: yes, it would be great if a user group allows users to discuss RFPs and so on, but that wouldn't justify restricting developers in a USERS AND DEVELOPERS group. I await to see how KUDOS develops with interest. To which I wish to clarify....I'll keep everyone posted about the "enhancement database RFP" we're pursuing on the Evergreen side to see if there's an interest on the Koha side. And I too wish to be clear that I am in favor of KUDOS being a Koha Users and Developers group. Lori Ayre On Sun, Jan 24, 2010 at 3:26 PM, MJ Ray <mjr@phonecoop.coop> wrote:
Dan Scott <denials@gmail.com>
Actually, the Evergreen community is in a trial period of using LaunchPad (http://launchpad.net/evergreen) for many of these purposes
Would you believe that I decided against replying earlier in the thread that the last thing the world needs is another repeat of the Launchpad problem which gives everyone Yet Another website to check for bugs?
So I'm pretty disappointed to see Launchpad appear here. It is more of a black hole than a tool, in that it tries to track everyone and draw them into using it. Launchpad.net has claimed that I am a member twice, even though I have never agreed to membership. I get a bit annoyed about such silly failures to respect people's basic rights.
Whatever is chosen, please can it be something which at least gives people the freedom to choose whether or not to associate? Voluntary membership is not only a cooperative principle, it's even in the UDHR.
Of course, bugzilla has a related drawback in that most site configurations don't allow you to contribute if you choose not to associate. That's better than Launchpad in that you do have a choice, but a front-end could address that problem, as well as being more user-friendly.
Going back more widely for a moment: yes, it would be great if a user group allows users to discuss RFPs and so on, but that wouldn't justify restricting developers in a USERS AND DEVELOPERS group. I await to see how KUDOS develops with interest.
Hopa that explains, -- MJ Ray (slef) Webmaster and LMS developer at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
participants (12)
-
Chris Cormack -
Chris Nighswonger -
Dan Scott -
David Schuster -
Joann Ransom -
Liz (me) Rea -
Lori Ayre -
M. Brooke Helman -
MJ Ray -
Owen Leonard -
Scott Kushner -
vtl＠scls.lib.wi.us