Summary of Open session at KohaCon13 - with a focus on Funding the Future of Koha.
Hello All - I’d like to give a summary of a open discussion that occurred at KohaCon14 in Reno. A spot opened up from a presenter not being able to attend - so I volunteered to lead a discussion on Funding the future of Koha. First we invited all current and past RM’s of Koha up to the front of the room, to educate the audience on some of the “plumbing” needs in the code. When I use the term “plumbing” - I really mean portions of the code that need to be “rewritten”, “updated for current coding practices”, and a “plan for placing newer technologies and practices into the code”. Mainly plumbing = what do we need to get completed in the near future and how are we going to get that done. Many of these “needs” are larger projects that not a single organization or library can fund, as we would really need to dedicate an expert programmer some uninterrupted time to accomplish these goals. Not one support vendor can brunt the front of the plumbing needs that need to happen. We need to work together to fund this and we need to have a place and plan going forward "now". Let's do this for Koha! Points that were raised. Many attendees felt that a clear plan on what path Koha should be developing towards would be a useful project. Although setting a ridged path is a difficult thing with a community like ours, maybe a place for everyone to get or stash ideas for future paths would be a good thing to organize. An important comment here from the attendees was that when someone is funding a development - they should not just fund the code, but also plan for time and funding for the Sign-Off process and the QA process. Funding and how would we organize this? Since many in the audience were from the USA - there was discussion of getting a users group going again OR creating some sort of “non-profit like org” where libraries could pool funding towards projects. An organization like this would be able to apply for grants etc. Something where we could crowd-source funding and then fund a developer for a number of hours towards a project. My thoughts on some things that we can do in the USA. Have a hackfest in Athen’s Ohio next summer. Next year will be 10 years since Koha migrated to the US and I think it’s about time we have a hackfest here. I have briefly talked with Owen Leonard about putting this together for next summer and would love for help and encourage those from overseas to join us. (Also a commitment here that we will be sending a few employees to the France Hackfest in March and will continue to do this every year that we can - that also being right around a feature freeze for releases it's important to have a solid week dedicated to hacking koha only) Gauge the interest of a North American Koha users group so at least we are having more of the community meeting together and sharing practices and ideas. Comments from Galen "As far as a US or North American user group goes: I think a relaunch should start off with just the goal of hosting a US/NA conference, as it would /not/ be necessary to set up a nonprofit first to run conferences. We'd just need willing hosts and, if necessary, a firm willing and able to act as a fiscal agent. That's not to say that such a group couldn't pursue nonprofit status later, but we can get a lot of education and user-connecting done without ever having to have a formal organization." Thanks all - this is to promote discussion and hopefully we can all do this together! Brendan -- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Santa Barbara, CA - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com brendan@bywatersolutions.com <info@bywatersolutions.com>
I’d like to give a summary of a open discussion that occurred at KohaCon14 in Reno. A spot opened up from a presenter not being able to attend - so I volunteered to lead a discussion on Funding
Salvete! the future of Koha. First we invited all current and past RM’s of Koha up to the front of the room, to educate the audience on some of the “plumbing” needs in the code. When I use the term “plumbing” - I really mean portions of the code that need to be “rewritten”, “updated for current coding practices”, and a “plan for placing newer technologies and practices into the code”. Mainly plumbing = what do we need to get completed in the near future and how are we going to get that done.
Many of these “needs” are larger projects that not a single
organization or library can fund, as we would really need to dedicate an expert programmer some uninterrupted time to accomplish these goals. Not one support vendor can brunt the front of the plumbing needs that need to happen. We need to work together to fund this and we need to have a place and plan going forward "now". Let's do this for Koha!
Points that were raised.
Many attendees felt that a clear
I can't stress this enough. Bust things into the smallest pieces possible and put a price on them with the understanding that the longer things are delayed, the more the price will rise. I think one of the biggest fears can be not knowing how much a rewrite will cost. I would further hope that vendors would factor some rewriting into the quotes they give their clients. I can't see this long term need simply disappearing. I would assume that it's as agitating to vendors as it would be to libraries to have nagging problems. I don't think anyone wants folks to bankrupt themselves short term or long term. So please consider everything in your aestimates. Perhaps a few tiers as in a consortium makes sense; the larger Libraries with means to do so can self identify and help financially, while the smaller ones can give in kind. I know I'm beating a dead horse here, but it is very important to remember the relationship between open source development and fun. I think it might be safe to say that rewriting is really not any one's idea of fun. plan on what path Koha should be developing towards would be a useful project. Although setting a ridged path is a difficult thing with a community like ours, maybe a place for everyone to get or stash ideas for future paths would be a good thing to organize.
An important comment here from the attendees was that when someone is funding a development - they should not just fund the code, but also
It doesn't have to be rigid. When I was your age and Paul was release manager the first time, we had a really simply road map. Anyone could put anything on it, and there was a lot of satisfaction as folks signed their names to it and owned each feature or fix. We didn't get everything we wanted by any stretch, but it sure seemed like we got an awful lot. We have the wiki. I know not everyone likes it and it's disorganised, but I still feel like it's friendly enough that even I can do it. As long as folks have an account, they can muck about and make things as they see it. Someplace a long the line, and I tend to blame us Yanks, we lost the spirit of just DOING things, and we transitioned to talking about doing things instead. plan for time and funding for the Sign-Off process and the QA process.
Funding and how would we organize this? Since many in the audience were from the USA - there was discussion of getting a users group going again OR creating some sort of “non-profit like org” where libraries could pool funding towards projects. An organization like this would be able to apply for grants etc. Something where we could crowd-source funding and then fund a developer for a number of hours towards a
This should be factored in to a vendor's quote. Sign offs are usually not fun, but bugfixing days, chorewars, and scoreboards changed this a little! :D (One of many great ideas. :D) I stand by my previous assertion that mechanical turking out sign offsand sandboxing could be a good thing. We could at least try it for very low cost, but it would require pretty bad arse sandboxing. I'm also olde enough to remember a time pre sandbox. :D So yes, we are definitely making forward progress even if it doesn't seem like it to those in the thick of the fight! project.
Users' groups pre date things like Kickstarter. Individual Libraries are still free to explore grants without building a whole new umbrella organisation. That said, a proper non profit foundation is still highly attractive to me despite the endless hoops and pitfalls. I feel like it would be a safe place for IP, a good bank for good purposes that Libraries couldn't support - like travel to Conference for folks outside their walls. (Thankfully this is starting to happen *anyway* but it could be quicker.)
My thoughts on some things that we can do in the USA.
Have
Gauge the interest of a North American Koha users group so at least we are having more of the community meeting together and sharing practices and ideas. Comments from Galen "As far as a US or North American user group goes: I
a hackfest in Athen’s Ohio next summer. Next year will be 10 years since Koha migrated to the US and I think it’s about time we have a hackfest here. I have briefly talked with Owen Leonard about putting this together for next summer and would love for help and encourage those from overseas to join us. (Also a commitment here that we will be sending a few employees to the France Hackfest in March and will continue to do this every year that we can - that also being right around a feature freeze for releases it's important to have a solid week dedicated to hacking koha only) think a relaunch should start off with just the goal of hosting a US/NA conference, as it would /not/ be necessary to set up a nonprofit first to run conferences. We'd just need willing hosts and, if necessary, a firm willing and able to act as a fiscal agent. That's not to say that such a group couldn't pursue nonprofit status later, but we can get a lot of education and user-connecting done without ever having to have a formal organization."
I put in a bid for Conference this go round. I'd gladly do so again in an off election year. I'd still be willing to host. So if Owen's too busy, lemme know. :D I think Winter might be a better time for me and less likely to conflict with ALA annual. (Screw Midwinter.) Dunno if there's a method to picking summer, though. Just sayin: summer in Ohio, prolly decent rates balmy temperatures. Summer in DC, not so much. Rumour has it that summer in Montana might be nice. ;) Cheers, Brooke
Greetings, I am currently working on Bug 7567, News by Library, and one thing that came up while testing is the filtering. I have a very simple question which doesn't even require applying a patch. It just requires staff client access and news access. I know the screen has been basically the same since 3.4. 1) Log into your staff client 2) Click 'Tools' 3) Click 'News' (Additional Tools column, 4th item) There is a "Display location" label just below the pretty "+ New Entry" button. Beside that is a drop down list. When you first come to this page it says "All" and displays every news item in a nice table below. This seems good to me. The problem comes in when you then: 1) Select something other than All 2) Click the 'Filter' button. It filters it correctly, but the drop down list value displayed still says "All". My question is this: Should it display "All" or the value for which it is filtering? Your feedback is very much appreciated, Mark Tompsett
My question is this: Should it display "All" or the value for which it is filtering?
Filters like that should always display the current selection. This is a pattern which we try to maintain throughout Koha and instances which violate this pattern are considered bugs. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Hello All -
I’d like to give a summary of a open discussion that occurred at KohaCon14 in Reno...a discussion on Funding the future of Koha...to educate the audience on some of the “plumbing” needs in the code...and how are we going to get that done.
Many of these “needs” are larger projects...Not one support vendor can brunt the front of the plumbing needs that need to happen...We need to...plan going forward "now".
Points that were raised.
----snip--- An important comment here from the attendees was that when someone is funding a development - they should not just fund the code, but also plan for time and funding for the Sign-Off process and the QA process. *+1. Excellent idea! How would this work? Would the funding organization contract directly with a separate dev to signoff/QA, or would the code developer contract with someone to do this? Would there be a conflict of interest if the funding organization had someone on their staff sign/QA if that person was qualified?* Funding and how would we organize this? Since many in the audience were from the USA - there was discussion of getting a users group going again OR creating some sort of “non-profit like org” where libraries could pool funding towards projects. An organization like this would be able to apply for grants etc. Something where we could crowd-source funding and then fund a developer for a number of hours towards a project. *+1. I also am generally in favor of charging some nominal amount to attend KUG's/conferences. Even if it's just 25 USD--split the amount between the hosting organization for coffee and contribute some to Koha plumbing. US libraries typically can't just "donate" money to anything, but they certainly are used to paying attendance fees, and $25 or $50 is only a small fraction of the cost of flying and hotels.* . *And as long as I'm on the general subject of funding, I've often
<comment> note numerous snips from original post --------------------------------------------------------------------- On 11/06/2013 09:38 PM, Brendan Gallagher wrote: thought privately that there should be some way to help out the Horowhenua Library Trust for their work of holding the Koha keys. In an ideal world they should have a 10 million USD trust fund to aggressively support Koha.*
My thoughts on some things that we can do in the USA.
Have a hackfest in Athen’s Ohio next summer. Next year will be 10 years since Koha migrated to the US and I think it’s about time we have a hackfest here.
*+1*
I have briefly talked with Owen Leonard about putting this together for next summer... Gauge the interest of a North American Koha users group so at least we are having more of the community meeting together and sharing practices and ideas. Comments from Galen "As far as a US or North American user group goes: I think a relaunch should start off with just the goal of hosting a US/NA conference, as it would /not/ be necessary to set up a nonprofit first to run conferences. *+1* We'd just need willing hosts and, if necessary, a firm willing and able to act as a fiscal agent. That's not to say that such a group couldn't pursue nonprofit status later, but we can get a lot of education and user-connecting done without ever having to have a formal organization."
Brendan
*Staccato comment #1: most of the Koha conferences to date (to the limited extent I'm qualified to comment on this) have been very technically focused. Someday there will begin to be more and more library staff attending, and those people will be more interested in end-user things. And someday I expect that KohaCon's will have different tracks, like code development, system administration and library staff interest. I think we need to start considering our audience soon. * *Staccato comment #2: apologies first, I've long considered the following, but I have some trouble expressing it coherently. Say with a larger project like plumbing, let's presume 250,000 USD is raised by some means by an independent organization, and by some fair and equitable method one of the major Koha support companies or independent developers is selected to do the work. As far as I know, all these qualified entities are already writing Koha code full-time, i.e., nobody has a lawn-care business for their daytime job and only write code when they get funded. So if we take our 250k and pay for a major rewrite, we're taking away from the development pool by substituting paid work for "otherwise-compensated" work already being done. Assuming we can equate the two types of work (improbable?), there is no net gain. In economic terms, this *somewhat analogous* to an "opportunity cost"-the cost of an alternative that must be forgone in order to achieve a different objective. As I mentioned at the beginning of this block, I struggle somewhat with what this means, if anything, but it would be nice to find a way for major funding developments to have an additive effect. * -- Greg Lawson Network Administrator Rolling Hills Consolidated Library 1912 N. Belt Highway St. Joseph, MO 64506
Le 07/11/2013 17:31, glaws a écrit :
>> An important comment here from the attendees was that when someone is
>> funding a development - they should not just fund the code, but also plan
>> for time and funding for the Sign-Off process and the QA process.
> *+1. Excellent idea! How would this work? Would the
> funding organization contract directly with a separate dev
> to signoff/QA, or would the code developer contract
> with someone to do this? Would there be a conflict of
> interest if the funding organization had someone on their staff
> sign/QA if that person was qualified?*
I started a private discussion with some other developers yesterday,
about this question.
There are different ways to achieve this goal:
* the funder funds 3 different organisations he choose
* the funder funds 1 organisation, that sub-contract 2 others
I'm about to try something like that in France. Seen from France side,
if we want to have a chance to get some funding, it must be simple for
the funder. So funding 1 org, that is responsible of subcontracting 2
others.
>> Funding and how would we organize this? Since many in the audience were
>> from the USA - there was discussion of getting a users group going again OR
>> creating some sort of “non-profit like org” where libraries could pool
>> funding towards projects. An organization like this would be able to apply
>> for grants etc. Something where we could crowd-source funding and then
>> fund a developer for a number of hours towards a project.
> *+1. I also am generally in favor of charging some nominal amount
> to attend KUG's/conferences. Even if it's just 25 USD--split the
> amount between the hosting organization for coffee and contribute
> some to Koha plumbing. US libraries typically can't just "donate"
> money to anything, but they certainly are used to paying attendance
> fees, and $25 or $50 is only a small fraction of the cost of flying
> and hotels.*
maybe that's possible for US meetings.
For french ones, we decided to keep them free, because we want to
attract more libraries to those conferences ! OTOH, the french NPO
("kohala") has decided to increase the NPO membership fee, to have a
little bit more money to fund some work. It's been considered as a valid
option, because the membership is made by libraries that already use
Koha, so they understand what the money can be used for.
Note that the amount risen is much too small to fund what we need.
> *And as long as I'm on the general subject of funding, I've often
> thought privately that there should be some way to help out the
> Horowhenua Library Trust for their work of holding the Koha keys.
> In an ideal world they should have a 10 million USD trust fund to
> aggressively support Koha.*
10 millions, I would be very happy for the project with this amount. I
would even be happy with just one ;-)
>> Have a hackfest in Athen’s Ohio next summer. Next year will be 10 years
>> since Koha migrated to the US and I think it’s about time we have a
>> hackfest here.
> *+1*
+1 too. We plan to have the 4th "hackfest in Europe" in 2014 march, I
hope I'll be able to send one or more BibLibre hackers to Athens OH !
>> I have briefly talked with Owen Leonard about putting this
>> together for next summer...
>> Gauge the interest of a North American Koha users group so at least we are
>> having more of the community meeting together and sharing practices and
>> ideas. Comments from Galen "As far as a US or North American user group
>> goes: I think a relaunch should start off with just the goal of hosting a
>> US/NA conference, as it would /not/ be necessary to set up a nonprofit
>> first to run conferences.
> *+1*
Yes, my preference going to work on both !
> *Staccato comment #1: most of the Koha conferences to date
> (to the limited extent I'm qualified to comment on this) have been
> very technically focused.
Not sure I understand what you mean here. The first 3 days, are really
non tech focused.
The hackfest is. And there's been different hackfests, depending on the
audience: we sometimes do a lot of teaching how to hack Koha, and
sometimes do actual hacking.
This year, it was mostly focused on hacking, as most of attendees being
long timer Koha hackers. But there's been some training for newbies as
well (and I hope they've been happy with what they learned !)
> Someday there will begin to be more and
> more library staff attending, and those people will be more
> interested in end-user things. And someday I expect that KohaCon's
> will have different tracks, like code development, system
> administration and library staff interest. I think we need to start
> considering our audience soon.
In "hackfest in Europe", we had something like 12-15 librarians (most of
them with *NO* technical skills)
They've been *very* happy to:
* work on non technical things like translations, or documentation
* test patches using sandboxes
* have talks together
The 1st year I organized the hackfest, I had only a few librarians
announcing themselves. So I send 10 mails to our 10 largest customers,
with some arguments to convince them to send someone. And those
arguments were specific to each. Something like "hey, you want this into
Koha, there's a patch, come and we will let you know how to test it"
It took me almost a full day to write those 10 mails.
BUT : the result was *great* ! 8 of them answered "hey, I didn't
understood that it could be so interesting. OK, I'll come".
The year after, they came again. And in 2013, again.
What was wrong was *bootstraping* the hackfest.
So YES, if you want to participate, you can, even if you don't know a
line of Perl !
> *Staccato comment #2: apologies first, I've long considered the following,
> but I have some trouble expressing it coherently. Say with a larger
> project like plumbing, let's presume 250,000 USD is raised by some
Could you say 500,000 please ? Or even 1M, that would be perfect ;-)
> means by an independent organization, and by some fair and
> equitable method one of the major Koha support companies or
> independent developers is selected to do the work.
Not only one, but 3 : one to develop, one to signoff, one to QA.
> As far as
> I know, all these qualified entities are already writing Koha code
> full-time, i.e., nobody has a lawn-care business for their
> daytime job and only write code when they get funded. So if we take
> our 250k and pay for a major rewrite, we're taking away from the
> development pool by substituting paid work for
> "otherwise-compensated" work already being done.
Yes and no. If you come and say "I've 1M for you, you start tomorrow
morning on plumbing, I'll have some trouble to do it. But if you let me
3 months I can organise my company: change planning of some projects,
hire a new developer,...
My agenda is full for the next 2 months. We've some project that will
probably start in january, but that's our business to manage priorities
and agendas !
> Assuming we can equate the two types of work (improbable?),
> there is no net gain. In economic terms, this *somewhat analogous* to an
> "opportunity cost"-the cost of an alternative that must be forgone in
> order to achieve a different objective.
Wrong asumption I think.
I would that I would prefer, from far, having 2 developers working on
plumbing, than putting plaster on wounds (google translate here,
frenchism suspected ;-) )
And most developers (at least BibLibre one's) are really willing to do
plumbing, beacuse they're tired of adding lines on code they would
prefer to rewrite to have it more modular, more modern, ...
--
Paul POULAIN - Associé-gérant
Tel : (33) 4 91 81 35 08
http://www.biblibre.com
Logiciels Libres pour les bibliothèques et les centres de documentation
Lots of lines snipped...
*Staccato comment #1: most of the Koha conferences to date (to the limited extent I'm qualified to comment on this) have been very technically focused. Not sure I understand what you mean here. The first 3 days, are really non tech focused.
Depends on your definition of tech. A lot of discussion (which I thoroughly enjoyed and learned from) focused on what features people wanted to improve it. As Koha becomes more widespread, I think KohaCon could benefit from more sessions on using it: *Now that I have this system installed, how can I get the best use out of it? *How do I get the library staff used to Koha? Training tips for Everylibrarian. *How does a non-sysadmin run the system? I'm sure others will be able to come up with more. One likely use for Koha is to give small libraries with minuscule budgets a chance to install an ILS at minimal cost. Maybe someone with a lot of extra time on their hands* could design a questionnaire that a library could download, fill out, and send to a vendor. The vendor could then configure Koha according to the library's needs and send them a server, or even just a hard drive. Plug it in, instant ILS! All right, it doesn't have any books in it yet, and cataloging is far from quick-n-easy, but at least their ILS is up and running. If there's a market for that kind of barebones service, maybe there could be a few sessions at KohaCon on supporting small libraries. Sorry if I'm rambling. I need another cup of tea... --Fred King kohauser@phred.us *If I worked at a place that would give me a sabbatical, I'd do it. Unfortunately, I don't. Besides, I have to finish my novel first.** **I'm a very slow reader.
Paul Poulain wrote:
Le 07/11/2013 17:31, glaws a écrit :
*+1. Excellent idea! How would this work? Would the funding organization contract directly with a separate dev to signoff/QA, or would the code developer contract with someone to do this? Would there be a conflict of interest if the funding organization had someone on their staff sign/QA if that person was qualified?* I started a private discussion with some other developers yesterday, about this question.
There are different ways to achieve this goal: * the funder funds 3 different organisations he choose * the funder funds 1 organisation, that sub-contract 2 others
Uh-oh! I think both of those present the same conflict of interest that is why it is(was?) discouraged for people from one company to do all the development and signing on a patch: they all have a short-term financial incentive to approve less-than-great work. I'm sure many wouldn't, but it still means the reviews aren't very independent. I'd like it if developers could barter sign-off reviews (not the actual sign-offs, because it takes as much time to reject with reasons - if not more time) in a bit more structured/asynchronous way than the current IRC-based begging/nagging. Then a funder could fund 1 organisation and it barters reviews with others to ensure its developments get reviewed. Has anyone an easy way to do this? Think of it like product reviews in magazines. If the manufacturer is paying for the review, it's seen as less reliable than if the recipients of the review are paying for it... we could see the pot of bartered reviews as like the koha-community paying for reviews - but paying by writing other reviews. That still leaves QA as a question, but it's reviews/signoffs that is the tighter bottleneck, isn't it? Other that that aspect, I agree with much of what Paul wrote, which should surprise almost no-one. Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/
* MJ Ray (mjr@phonecoop.coop) wrote:
Paul Poulain wrote:
Le 07/11/2013 17:31, glaws a écrit :
*+1. Excellent idea! How would this work? Would the funding organization contract directly with a separate dev to signoff/QA, or would the code developer contract with someone to do this? Would there be a conflict of interest if the funding organization had someone on their staff sign/QA if that person was qualified?* I started a private discussion with some other developers yesterday, about this question.
There are different ways to achieve this goal: * the funder funds 3 different organisations he choose * the funder funds 1 organisation, that sub-contract 2 others
Uh-oh! I think both of those present the same conflict of interest that is why it is(was?) discouraged for people from one company to do all the development and signing on a patch: they all have a short-term financial incentive to approve less-than-great work. I'm sure many wouldn't, but it still means the reviews aren't very independent.
I'd like it if developers could barter sign-off reviews (not the actual sign-offs, because it takes as much time to reject with reasons - if not more time) in a bit more structured/asynchronous way than the current IRC-based begging/nagging. Then a funder could fund 1 organisation and it barters reviews with others to ensure its developments get reviewed. Has anyone an easy way to do this?
I plan to write something, but I need help from a UX person. I want a simple taskboard, with bugs, that people can claim by a simple click. Then a simple karma type system. ByWater have signed off 10 Catalyst patches, Catalyst have signed off 5 software.coop and 1 Bywater patch, leaving Catalyst 4 patches to go ... kind of idea. It's not fully formed, but if it sounds like something people would to see, or explore further, let me know and I will devote some evenings to it. Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand
I plan to write something, but I need help from a UX person.
I want a simple taskboard, with bugs, that people can claim by a simple click. Then a simple karma type system. ByWater have signed off 10 Catalyst patches, Catalyst have signed off 5 software.coop and 1 Bywater patch, leaving Catalyst 4 patches to go ... kind of idea.
It's not fully formed, but if it sounds like something people would to see, or explore further, let me know and I will devote some evenings to it.
I would totally be behind an idea like this. Ideally it would be great to "easily" see if we (ByWater) really are doing enough to eventually get our patches signed off. Something like this would give us a great snapshot of where we need to quickly pick up the slack or just help another developer/company. Although I usually look for patches that are within my skillset to sign-off on, the company or person that submitted the patch is never an issue or goal for me to test or sign-off and I would urge that mind-set stay in the forefront for everyone (which I'm pretty positive that it will).
Chris
-- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Santa Barbara, CA - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com info@bywatersolutions.com
Salvete! *breaks out dead horse whip again*
I'd like it if developers could barter sign-off reviews (not the actual sign-offs, because it takes as much time to reject with reasons - if not more time) in a bit more structured/asynchronous way than the current IRC-based begging/nagging. Then a funder could fund 1 organisation and it barters reviews with others to ensure its developments get reviewed. Has anyone an easy way to do this?
Yes, mechanical turk it. Have the QA manager approve turks, who will prolly be people that have been involved in the project for a little bit. As long as permissions are set so that HITs can't be picked up from people that are in the same company it will still work the way out QA process currently works, the difference will be that people can get a tiny amount of money for each bug. Cheers, Brooke
participants (9)
-
Brendan Gallagher -
BWS Johnson -
Chris Cormack -
Fred King -
glaws -
Mark Tompsett -
MJ Ray -
Owen Leonard -
Paul Poulain