Re: [OPEN-ILS-GENERAL] Bug bounties

[Andrea Buntz Neiman]

I've been following this entire bug bounty conversation with interest, 
but this:



We also have our dashboard,http://dashboard.koha-community.org/  which
is designed to highlight where work is needed.
(Cloneable as well of course)


... is awesome.  I like the clarity, I like the details, I like the 
chart, I like the "random bug", and I especially like that QA is tied 
into it.


How difficult would it be to also tie in things like documentation & 
testing to this kind of one-stop dashboard?  I know there is also a 
conversation currently about using Launchpad for documentation 
requests/tracking.


I envision a place where coders, testers, & documenters can see what 
needs to be done all in one location, pick what they work on, and get it 
done -- even if it is just a front/landing page for something like 
Launchpad.


A.




Andrea Buntz Neiman, MLS
Librarian II, Public Services
Kent County Public Library
408 High Street
Chestertown, MD 21620
410-778-3636 x2115
www.kentcountylibrary.org

On 8/1/2013 5:08 AM, Chris Cormack wrote:

We also have our dashboard,http://dashboard.koha-community.org/  which
is designed to highlight where work is needed.
(Cloneable as well of course)

Re: [OPEN-ILS-GENERAL] Bug bounties

[Chris Cormack]

On 1 August 2013 07:46, Kathy Lussier  wrote:

>
> However, it might be a good way to encourage contributors to spend one day
> where they can focus on fixing bugs. The idea came from a Koha global bug
> squashing day that was held last May -
> http://wiki.koha-community.org/wiki/2013-05-10_Global_bug_squashing_day. The
> Koha community even had a scorecard of "number of kittens saved" to
> highlight the contributors who had the most bug fixes, patches reviewed,
> etc. I can't remember all of the categories, and the scorecard doesn't
> appear to be available online anymore. We could designate one day where
> contributors are committed to submitting code to fix bugs, reviewing bugs,
> signing off on the fixes, etc. Koha even provided sandboxes for people who
> do not have access to a testing server, but are interested in testing fixes.
> I think this would be a great way to encourage more people to get involved
> in the process.
>
l
Actually we have held a lot of bug squashing days

http://wiki.koha-community.org/wiki/Category:Global_bug_squashing_days

The next one is Friday the 9th of August, each of them we keep
statistics for 
http://wiki.koha-community.org/wiki/2011-11-04_Global_bug_squashing_day

The scoreboard was actually from the Kohacon12 Hackfest, you can see
it here https://gitorious.org/scoreboard/scoreboard/blobs/raw/master/index.html
you can clone it if you want,

https://gitorious.org/scoreboard/scoreboard

We also have our dashboard, http://dashboard.koha-community.org/ which
is designed to highlight where work is needed.
(Cloneable as well of course)

Chris

Re: [OPEN-ILS-GENERAL] Bug bounties

[Rogan Hamby]

I think we should high light that Dan Wells has helped push cleaning up a
lot of bugs with 2.5 including wishlist ones which as he pointed out is
characteristic of a maturing software project.

I like the idea of the bug squashing being something symbolic but
meaningful.  I don't mind giving out money but nor do I want it to be about
money.

I like the bug squashing idea too.

A big part of all this though is what do the developers think would be a
fun thing that they would rally behind.  A bug squashing day?  Should we
devote some time at the hack-a-way to reviewing long standing bugs and
seeing what can be done about them?  What do you think?


On Wed, Jul 31, 2013 at 3:46 PM, Kathy Lussier  wrote:

>  Hi Rogan, Dan, et al.,
>
>
> Anyway, I think those are valid concerns and concerns I have as well but
> I'd like to see what Kathy comes up with for a proposal.
>
>
> Hmmm...I think what I said was I would be willing to *help* work out the
> details, but I guess I could poke around to see what other projects do and
> start with something bare bones for the community to react to.
>
> One of the reasons I was so quick to volunteer to help on this is because
> I do submit a lot of bugs and don't really have the ability to fix them,
> with the exception of some really, easy tpac bugs. In some cases, the bugs
> are resolved fairly quickly; others are collecting dust, not because the
> community doesn't care about fixing them, but because everyone has limited
> time and usually must address the needs important to their own
> organizations before working on other bugs. I just did a search of
> Launchpad and saw that I have 48 outstanding bugs that have not been
> committed or released, though a few do have code that needs to be tested.
> Since I'm limited in the amount of fixing I can do, I see this as another
> way I can contribute to help get Evergreen bugs resolved.
>
> I also understand some of Dan's concerns and was thinking it might be good
> to reframe this discussion. Maybe we should look at the underlying problem,
> which is the issue of valid bugs that languish in Launchpad, and then
> consider ways that the community can support getting those bugs fixed.
>
> One idea is to go with the bug bounty system, providing some type of
> incentive (monetary or otherwise) to developers who fix bugs of a certain
> age. In thinking about the monetary incentive, I couldn't help but think
> about all the money and staff time that many Evergreen sites (including
> MassLNC) put into new enhancements without giving the same attention to
> long-standing bugs that need to be fixed. Even when the new enhancement has
> gone through thorough testing, it isn't unusual for it to introduce even
> more bugs that then get added to the list of bugs that need to be fixed.
> When Rogan first raised the ideas of bug bounties, I was seeing it as a way
> to provide a little more balance between all of the funding that supports
> new enhancements and funding that supports fixing bugs.
>
> Swag could be another incentive, but, since I anticipate one developer may
> be submitting fixes for several bugs, we might need to do a scale where
> fixing 1-5 bugs gets you a sticker, 10 gets you a t-shirt, and 20 gets you
> a bike. Or maybe we could do something where the person who has submitted
> the most bug fixes during a certain month gets a spotlight on the community
> web site. Incentives can take many forms.
>
> Another idea is one I raised at the June developers meeting regarding an
> Evergreen bug squashing day. I was left with an action item to e-mail the
> list about this idea, but I never followed up on it, partially because of
> other time commitments, but also because Dan Wells has been so effective in
> encouraging developers to review active pullrequests that I wasn't sure it
> was still needed.
>
> However, it might be a good way to encourage contributors to spend one day
> where they can focus on fixing bugs. The idea came from a Koha global bug
> squashing day that was held last May -
> http://wiki.koha-community.org/wiki/2013-05-10_Global_bug_squashing_day.
> The Koha community even had a scorecard of "number of kittens saved" to
> highlight the contributors who had the most bug fixes, patches reviewed,
> etc. I can't remember all of the categories, and the scorecard doesn't
> appear to be available online anymore. We could designate one day where
> contributors are committed to submitting code to fix bugs, reviewing bugs,
> signing off on the fixes, etc. Koha even provided sandboxes for people who
> do not have access to a testing server, but are interested in testing
> fixes. I think this would be a great way to encourage more people to get
> involved in the process.
>
> I don't think these ideas need to be mutually exclusive of each other.
> Maybe we could organize a bug squashing day sometime after the 2.5 release
> to see how many old bugs can be knocked off before running a test of a bug
> bounty system. Maybe there are o

Re: [OPEN-ILS-GENERAL] Bug bounties

[Kathy Lussier]

Hi Rogan, Dan, et al.,

Anyway, I think those are valid concerns and concerns I have as well 
but I'd like to see what Kathy comes up with for a proposal. 


Hmmm...I think what I said was I would be willing to *help* work out the 
details, but I guess I could poke around to see what other projects do 
and start with something bare bones for the community to react to.


One of the reasons I was so quick to volunteer to help on this is 
because I do submit a lot of bugs and don't really have the ability to 
fix them, with the exception of some really, easy tpac bugs. In some 
cases, the bugs are resolved fairly quickly; others are collecting dust, 
not because the community doesn't care about fixing them, but because 
everyone has limited time and usually must address the needs important 
to their own organizations before working on other bugs. I just did a 
search of Launchpad and saw that I have 48 outstanding bugs that have 
not been committed or released, though a few do have code that needs to 
be tested. Since I'm limited in the amount of fixing I can do, I see 
this as another way I can contribute to help get Evergreen bugs resolved.


I also understand some of Dan's concerns and was thinking it might be 
good to reframe this discussion. Maybe we should look at the underlying 
problem, which is the issue of valid bugs that languish in Launchpad, 
and then consider ways that the community can support getting those bugs 
fixed.


One idea is to go with the bug bounty system, providing some type of 
incentive (monetary or otherwise) to developers who fix bugs of a 
certain age. In thinking about the monetary incentive, I couldn't help 
but think about all the money and staff time that many Evergreen sites 
(including MassLNC) put into new enhancements without giving the same 
attention to long-standing bugs that need to be fixed. Even when the new 
enhancement has gone through thorough testing, it isn't unusual for it 
to introduce even more bugs that then get added to the list of bugs that 
need to be fixed. When Rogan first raised the ideas of bug bounties, I 
was seeing it as a way to provide a little more balance between all of 
the funding that supports new enhancements and funding that supports 
fixing bugs.


Swag could be another incentive, but, since I anticipate one developer 
may be submitting fixes for several bugs, we might need to do a scale 
where fixing 1-5 bugs gets you a sticker, 10 gets you a t-shirt, and 20 
gets you a bike. Or maybe we could do something where the person who has 
submitted the most bug fixes during a certain month gets a spotlight on 
the community web site. Incentives can take many forms.


Another idea is one I raised at the June developers meeting regarding an 
Evergreen bug squashing day. I was left with an action item to e-mail 
the list about this idea, but I never followed up on it, partially 
because of other time commitments, but also because Dan Wells has been 
so effective in encouraging developers to review active pullrequests 
that I wasn't sure it was still needed.


However, it might be a good way to encourage contributors to spend one 
day where they can focus on fixing bugs. The idea came from a Koha 
global bug squashing day that was held last May - 
http://wiki.koha-community.org/wiki/2013-05-10_Global_bug_squashing_day. 
The Koha community even had a scorecard of "number of kittens saved" to 
highlight the contributors who had the most bug fixes, patches reviewed, 
etc. I can't remember all of the categories, and the scorecard doesn't 
appear to be available online anymore. We could designate one day where 
contributors are committed to submitting code to fix bugs, reviewing 
bugs, signing off on the fixes, etc. Koha even provided sandboxes for 
people who do not have access to a testing server, but are interested in 
testing fixes. I think this would be a great way to encourage more 
people to get involved in the process.


I don't think these ideas need to be mutually exclusive of each other. 
Maybe we could organize a bug squashing day sometime after the 2.5 
release to see how many old bugs can be knocked off before running a 
test of a bug bounty system. Maybe there are other ideas out there for 
addressing the issue of dusty bugs.


Kathy



Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
kluss...@masslnc.org
Twitter: http://www.twitter.com/kmlussier

On 7/31/2013 11:45 AM, Rogan Hamby wrote:
Doing some basic Googling for bug bounties I found mention of Koha 
discussing it at KohaCon 12.  I didn't find mention past that but 
wether they did or didn't implement one their experience may be 
educational to us.





On Tue, Jul 30, 2013 at 5:48 PM, Dan Scott > wrote:


On Tue, Jul 30, 2013 at 05:35:04PM -0400, Rogan Hamby wrote:
> I haven't heard any dissents and at least two in favors of (you
and I) so
> in the spirit of a meritocracy I would say Kathy that

Re: [OPEN-ILS-GENERAL] Bug bounties

[Rogan Hamby]

Doing some basic Googling for bug bounties I found mention of Koha
discussing it at KohaCon 12.  I didn't find mention past that but wether
they did or didn't implement one their experience may be educational to us.




On Tue, Jul 30, 2013 at 5:48 PM, Dan Scott  wrote:

> On Tue, Jul 30, 2013 at 05:35:04PM -0400, Rogan Hamby wrote:
> > I haven't heard any dissents and at least two in favors of (you and I) so
> > in the spirit of a meritocracy I would say Kathy that at the least if you
> > want to come up with a model of how to handle it, go ahead and let's
> start
> > poking at the details.
> >
> > I won't derail things with my wishlist for accessibility.  :)
> >
> > I agree that wishlist bugs shouldn't be on the list.
>
> Okay, I'll offer a conditional dissent then. I worry that the
> introduction of financial incentives will disrupt the contributor
> ecology. As soon as money is in the picture, all sorts of interesting
> side effects can occur.
>
> For example, will this act as a disincentive for open communication
> and collaboration about potential alternatives for fixing a bug (because
> potential fixers jealously guard their approaches from one another)?
> Will it reduce the interest of current developers in providing
> assistance to new contributors? Will it introduce difficulties in trying
> to divvy up credit for bug fixes? Do reviewers of bug fixes get any
> share of the cash? Do reporters of bugs who provide reproducible test
> cases get any share of the cash? Is there any requirement to providing
> regression tests (to prevent the bug from ever rearing its head again)
> as part of the bug fix? Will contributors of new functionality bury bugs
> they know about in the interest of getting paid twice, once for the new
> functionality, and then later for the bug fixes?
>
> My conditional dissent would like some examples of projects where bug
> bounties have actually worked. The examples that I've seen have focused
> on reporting security vulnerabilities. If there are a few solid cases
> out there that can serve as a model for us, then I would turn my dissent
> into cautious assent.
>
> It could be that I've just read one too many Dilbert cartoons...
>



-- 

Rogan Hamby, MLS, CCNP, MIA
Managers Headquarters Library and Reference Services,
York County Library System

"You can never get a cup of tea large enough or a book long enough to suit
me."
-- C.S. Lewis 

Re: [OPEN-ILS-GENERAL] Bug bounties

[Yamil Suarez]

Thinking out of the box for a moment. What about having documentation
bounties? I am sure there are can be "Dilbertesque" issues to those
too, but I had floated around the idea of group sponsoring a retired
librarian, consultant, or part time librarian to devote serious
amounts of hours to work on documentation projects. I have had success
with using an intern, but they still needed me to proofread everything
and be trained and supervised.

Just a thought.

Thanks,
Yamil

On Thu, Jul 18, 2013 at 6:58 PM, Rogan Hamby  wrote:
> I'll be honest it's partially unclear because this is bouncing it off people
> thing at this point in time.  This probably frustrates some people but I
> think these are things that as a community we should have dialogues about.
>
> If I were asked to put forth my personal vision it would be something like
> this:
>
> The community votes on bugs over X age (a year old?) using some kind of
> mechanism and presumably ranks based on priority.  We then offer bug
> bounties on a set rate to Y number of bugs based on how much we have in that
> fund.  Let's say we have $1,000 and pay $100 per bug, then we can offer it
> to the top ten bugs ranked by people's votes.
>
> There are flaws with that approach.  Some may say it does't give weight to
> payments based on complexity of bug (and that's true) and some would say it
> doesn't weigh importance of more recent bugs (and that's true).  Fixing
> those things add issues of their own and  maybe we want to take those issues
> on.  That's part of why I'm throwing it out.
>
>
>

Re: [OPEN-ILS-GENERAL] Bug bounties

[Tim Spindler]

I generally like the idea and support but would have the same concerns as
Dan Scott.  I don't have a solution either.

Tim Spindler
C/W MARS

On Tuesday, July 30, 2013, Rogan Hamby wrote:

> I think I know the Dilbert cartoons you speak of and none of us want those
> scenarios!  Wally made a fortune
>
> Anyway, I think those are valid concerns and concerns I have as well but
> I'd like to see what Kathy comes up with for a proposal.  I don't think we
> have the resources to offer more than a minimal award so I would hope that
> potential financial gain would be a big factor.  And unlike Wally hopefully
> no one would create bugs just to fix them later.  :)
>
> Also, in the spirit of it being largely symbolic, as Ruth points out, in a
> discussion off list about swag the idea has been thrown out to use some
> kind of swag.  I'm personally amused at the idea of a t-shirt that says
> "Bug Killer"
>
>
>
> On Tue, Jul 30, 2013 at 5:48 PM, Dan Scott 
> 
> > wrote:
>
>> On Tue, Jul 30, 2013 at 05:35:04PM -0400, Rogan Hamby wrote:
>> > I haven't heard any dissents and at least two in favors of (you and I)
>> so
>> > in the spirit of a meritocracy I would say Kathy that at the least if
>> you
>> > want to come up with a model of how to handle it, go ahead and let's
>> start
>> > poking at the details.
>> >
>> > I won't derail things with my wishlist for accessibility.  :)
>> >
>> > I agree that wishlist bugs shouldn't be on the list.
>>
>> Okay, I'll offer a conditional dissent then. I worry that the
>> introduction of financial incentives will disrupt the contributor
>> ecology. As soon as money is in the picture, all sorts of interesting
>> side effects can occur.
>>
>> For example, will this act as a disincentive for open communication
>> and collaboration about potential alternatives for fixing a bug (because
>> potential fixers jealously guard their approaches from one another)?
>> Will it reduce the interest of current developers in providing
>> assistance to new contributors? Will it introduce difficulties in trying
>> to divvy up credit for bug fixes? Do reviewers of bug fixes get any
>> share of the cash? Do reporters of bugs who provide reproducible test
>> cases get any share of the cash? Is there any requirement to providing
>> regression tests (to prevent the bug from ever rearing its head again)
>> as part of the bug fix? Will contributors of new functionality bury bugs
>> they know about in the interest of getting paid twice, once for the new
>> functionality, and then later for the bug fixes?
>>
>> My conditional dissent would like some examples of projects where bug
>> bounties have actually worked. The examples that I've seen have focused
>> on reporting security vulnerabilities. If there are a few solid cases
>> out there that can serve as a model for us, then I would turn my dissent
>> into cautious assent.
>>
>> It could be that I've just read one too many Dilbert cartoons...
>>
>
>
>
> --
>
> Rogan Hamby, MLS, CCNP, MIA
> Managers Headquarters Library and Reference Services,
> York County Library System
>
> "You can never get a cup of tea large enough or a book long enough to suit
> me."
> -- C.S. Lewis 
>


-- 
Tim Spindler
tjspind...@gmail.com

*P**   Go Green - **Save a tree! Please don't print this e-mail unless it's
really necessary.*

Re: [OPEN-ILS-GENERAL] Bug bounties

[Rogan Hamby]

I think I know the Dilbert cartoons you speak of and none of us want those
scenarios!  Wally made a fortune

Anyway, I think those are valid concerns and concerns I have as well but
I'd like to see what Kathy comes up with for a proposal.  I don't think we
have the resources to offer more than a minimal award so I would hope that
potential financial gain would be a big factor.  And unlike Wally hopefully
no one would create bugs just to fix them later.  :)

Also, in the spirit of it being largely symbolic, as Ruth points out, in a
discussion off list about swag the idea has been thrown out to use some
kind of swag.  I'm personally amused at the idea of a t-shirt that says
"Bug Killer"



On Tue, Jul 30, 2013 at 5:48 PM, Dan Scott  wrote:

> On Tue, Jul 30, 2013 at 05:35:04PM -0400, Rogan Hamby wrote:
> > I haven't heard any dissents and at least two in favors of (you and I) so
> > in the spirit of a meritocracy I would say Kathy that at the least if you
> > want to come up with a model of how to handle it, go ahead and let's
> start
> > poking at the details.
> >
> > I won't derail things with my wishlist for accessibility.  :)
> >
> > I agree that wishlist bugs shouldn't be on the list.
>
> Okay, I'll offer a conditional dissent then. I worry that the
> introduction of financial incentives will disrupt the contributor
> ecology. As soon as money is in the picture, all sorts of interesting
> side effects can occur.
>
> For example, will this act as a disincentive for open communication
> and collaboration about potential alternatives for fixing a bug (because
> potential fixers jealously guard their approaches from one another)?
> Will it reduce the interest of current developers in providing
> assistance to new contributors? Will it introduce difficulties in trying
> to divvy up credit for bug fixes? Do reviewers of bug fixes get any
> share of the cash? Do reporters of bugs who provide reproducible test
> cases get any share of the cash? Is there any requirement to providing
> regression tests (to prevent the bug from ever rearing its head again)
> as part of the bug fix? Will contributors of new functionality bury bugs
> they know about in the interest of getting paid twice, once for the new
> functionality, and then later for the bug fixes?
>
> My conditional dissent would like some examples of projects where bug
> bounties have actually worked. The examples that I've seen have focused
> on reporting security vulnerabilities. If there are a few solid cases
> out there that can serve as a model for us, then I would turn my dissent
> into cautious assent.
>
> It could be that I've just read one too many Dilbert cartoons...
>



-- 

Rogan Hamby, MLS, CCNP, MIA
Managers Headquarters Library and Reference Services,
York County Library System

"You can never get a cup of tea large enough or a book long enough to suit
me."
-- C.S. Lewis 

Re: [OPEN-ILS-GENERAL] Bug bounties

[Ruth Frasur]

It's been mentioned elsewhere that maybe the bounties be something other
than money.  I think it was in the swag conversation.
On Jul 30, 2013 5:49 PM, "Dan Scott"  wrote:

> On Tue, Jul 30, 2013 at 05:35:04PM -0400, Rogan Hamby wrote:
> > I haven't heard any dissents and at least two in favors of (you and I) so
> > in the spirit of a meritocracy I would say Kathy that at the least if you
> > want to come up with a model of how to handle it, go ahead and let's
> start
> > poking at the details.
> >
> > I won't derail things with my wishlist for accessibility.  :)
> >
> > I agree that wishlist bugs shouldn't be on the list.
>
> Okay, I'll offer a conditional dissent then. I worry that the
> introduction of financial incentives will disrupt the contributor
> ecology. As soon as money is in the picture, all sorts of interesting
> side effects can occur.
>
> For example, will this act as a disincentive for open communication
> and collaboration about potential alternatives for fixing a bug (because
> potential fixers jealously guard their approaches from one another)?
> Will it reduce the interest of current developers in providing
> assistance to new contributors? Will it introduce difficulties in trying
> to divvy up credit for bug fixes? Do reviewers of bug fixes get any
> share of the cash? Do reporters of bugs who provide reproducible test
> cases get any share of the cash? Is there any requirement to providing
> regression tests (to prevent the bug from ever rearing its head again)
> as part of the bug fix? Will contributors of new functionality bury bugs
> they know about in the interest of getting paid twice, once for the new
> functionality, and then later for the bug fixes?
>
> My conditional dissent would like some examples of projects where bug
> bounties have actually worked. The examples that I've seen have focused
> on reporting security vulnerabilities. If there are a few solid cases
> out there that can serve as a model for us, then I would turn my dissent
> into cautious assent.
>
> It could be that I've just read one too many Dilbert cartoons...
>

Re: [OPEN-ILS-GENERAL] Bug bounties

[Dan Scott]

On Tue, Jul 30, 2013 at 05:35:04PM -0400, Rogan Hamby wrote:
> I haven't heard any dissents and at least two in favors of (you and I) so
> in the spirit of a meritocracy I would say Kathy that at the least if you
> want to come up with a model of how to handle it, go ahead and let's start
> poking at the details.
> 
> I won't derail things with my wishlist for accessibility.  :)
> 
> I agree that wishlist bugs shouldn't be on the list.

Okay, I'll offer a conditional dissent then. I worry that the
introduction of financial incentives will disrupt the contributor
ecology. As soon as money is in the picture, all sorts of interesting
side effects can occur.

For example, will this act as a disincentive for open communication
and collaboration about potential alternatives for fixing a bug (because
potential fixers jealously guard their approaches from one another)?
Will it reduce the interest of current developers in providing
assistance to new contributors? Will it introduce difficulties in trying
to divvy up credit for bug fixes? Do reviewers of bug fixes get any
share of the cash? Do reporters of bugs who provide reproducible test
cases get any share of the cash? Is there any requirement to providing
regression tests (to prevent the bug from ever rearing its head again)
as part of the bug fix? Will contributors of new functionality bury bugs
they know about in the interest of getting paid twice, once for the new
functionality, and then later for the bug fixes?

My conditional dissent would like some examples of projects where bug
bounties have actually worked. The examples that I've seen have focused
on reporting security vulnerabilities. If there are a few solid cases
out there that can serve as a model for us, then I would turn my dissent
into cautious assent.

It could be that I've just read one too many Dilbert cartoons...

Re: [OPEN-ILS-GENERAL] Bug bounties

[Rogan Hamby]

I haven't heard any dissents and at least two in favors of (you and I) so
in the spirit of a meritocracy I would say Kathy that at the least if you
want to come up with a model of how to handle it, go ahead and let's start
poking at the details.

I won't derail things with my wishlist for accessibility.  :)

I agree that wishlist bugs shouldn't be on the list.


On Tue, Jul 30, 2013 at 4:53 PM, Kathy Lussier  wrote:

>  Hi Rogan,
>
> Sorry to be late in getting you feedback on this, but I just wanted to
> send along a vote of support for the idea of offering bug bounties. I think
> it's a great idea!
>
> I think it should be limited to true bugs and not be used for wishlist
> bugs. I know there are plenty of bugs to tackle that are more than a year
> old, but, when working in two-releases per year cycle, I'm thinking bugs
> become old much sooner than that. Maybe six month or even less? I generally
> have found that if a bug doesn't receive some kind of attention in the
> first three months (attention being questions, confirmation, lots of "me
> too"s etc.), it is likely to be one of those bugs that ends up gathering
> dust. I think it's important that we give bugs a chance to get community
> attention before offering a bounty. Six months seems like it would be more
> than sufficient.
>
>
> some would say it doesn't weigh importance of more recent bugs (and that's
> true).
>
>
> I think it was me who said that. :) Overall, I would say targeting the
> older bugs is important. However, as with anything, I think there are
> exceptions. The specific bug I had in mind was
> https://bugs.launchpad.net/evergreen/+bug/1187993 which is related to an
> accessibility issue in the catalog when autosuggest is enabled. I see this
> bug as an exception because I believe accessibility is something the
> community should be supporting/striving for in any way we can. Perhaps
> there are/will be other unique cases out there where priority will take
> precedence.
>
> In any case, if the community decides to move forward with this, I would
> be willing to volunteer to help work out the details. We might not come up
> with the perfect system, but, whatever happens, it should lead to some
> fixes for issues that have been frustrating people.
>
> Kathy
>
> Kathy Lussier
> Project Coordinator
> Massachusetts Library Network Cooperative(508) 343-0128kluss...@masslnc.org
> Twitter: http://www.twitter.com/kmlussier
>
> On 7/18/2013 6:58 PM, Rogan Hamby wrote:
>
> I'll be honest it's partially unclear because this is bouncing it off
> people thing at this point in time.  This probably frustrates some people
> but I think these are things that as a community we should have dialogues
> about.
>
>  If I were asked to put forth my personal vision it would be something
> like this:
>
>  The community votes on bugs over X age (a year old?) using some kind of
> mechanism and presumably ranks based on priority.  We then offer bug
> bounties on a set rate to Y number of bugs based on how much we have in
> that fund.  Let's say we have $1,000 and pay $100 per bug, then we can
> offer it to the top ten bugs ranked by people's votes.
>
>  There are flaws with that approach.  Some may say it does't give weight
> to payments based on complexity of bug (and that's true) and some would say
> it doesn't weigh importance of more recent bugs (and that's true).  Fixing
> those things add issues of their own and  maybe we want to take those
> issues on.  That's part of why I'm throwing it out.
>
>
>
>
> On Thu, Jul 18, 2013 at 6:51 PM, Tim Spindler wrote:
>
>>  Rogan,
>>
>>  It is a little unclear what you are proposing.  Are you proposing that
>> bounties are given for fixing bugs?  Finding bugs? or Both?
>>
>>  Don't get me wrong, I think it has some real potential.  If we are to
>> put resources to it, I would advocate for rewarding those who fix bugs
>> because I'm sure many are pressured to add features but not rewarded to fix
>> bugs.
>>
>>  Tim
>>
>>
>> On Thu, Jul 18, 2013 at 5:58 PM, Rogan Hamby 
>> wrote:
>>
>>>  I wanted to bring up an idea that has been kicked around by several
>>> folks (including myself).  At this point I don't have a fleshed out
>>> implementation proposal in mind but wanted to throw it out for
>>> consideration.  The context of conversation so far had been targeting older
>>> bugs though perhaps we should weight them by priority as well.  What, how
>>> much and where are big questions attached to funds.  But, I don't want to
>>> put the cart before the horse.  This is a practice used successfully by
>>> some other open source projects and I think there's merit in considering it.
>>>
>>> Excuse my brevity, sent from my iPhone
>>>
>>>  --
>>>
>>>  Rogan Hamby, MLS, CCNP, MIA
>>> Managers Headquarters Library and Reference Services,
>>> York County Library System
>>>
>>>  "You can never get a cup of tea large enough or a book long enough to
>>> suit me."
>>> -- C.S. Lewis 

Re: [OPEN-ILS-GENERAL] Bug bounties

[Kathy Lussier]

Hi Rogan,

Sorry to be late in getting you feedback on this, but I just wanted to 
send along a vote of support for the idea of offering bug bounties. I 
think it's a great idea!


I think it should be limited to true bugs and not be used for wishlist 
bugs. I know there are plenty of bugs to tackle that are more than a 
year old, but, when working in two-releases per year cycle, I'm thinking 
bugs become old much sooner than that. Maybe six month or even less? I 
generally have found that if a bug doesn't receive some kind of 
attention in the first three months (attention being questions, 
confirmation, lots of "me too"s etc.), it is likely to be one of those 
bugs that ends up gathering dust. I think it's important that we give 
bugs a chance to get community attention before offering a bounty. Six 
months seems like it would be more than sufficient.


some would say it doesn't weigh importance of more recent bugs (and 
that's true). 


I think it was me who said that. :) Overall, I would say targeting the 
older bugs is important. However, as with anything, I think there are 
exceptions. The specific bug I had in mind was 
https://bugs.launchpad.net/evergreen/+bug/1187993 which is related to an 
accessibility issue in the catalog when autosuggest is enabled. I see 
this bug as an exception because I believe accessibility is something 
the community should be supporting/striving for in any way we can. 
Perhaps there are/will be other unique cases out there where priority 
will take precedence.


In any case, if the community decides to move forward with this, I would 
be willing to volunteer to help work out the details. We might not come 
up with the perfect system, but, whatever happens, it should lead to 
some fixes for issues that have been frustrating people.


Kathy

Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
kluss...@masslnc.org
Twitter: http://www.twitter.com/kmlussier

On 7/18/2013 6:58 PM, Rogan Hamby wrote:
I'll be honest it's partially unclear because this is bouncing it off 
people thing at this point in time.  This probably frustrates some 
people but I think these are things that as a community we should have 
dialogues about.


If I were asked to put forth my personal vision it would be something 
like this:


The community votes on bugs over X age (a year old?) using some kind 
of mechanism and presumably ranks based on priority.  We then offer 
bug bounties on a set rate to Y number of bugs based on how much we 
have in that fund.  Let's say we have $1,000 and pay $100 per bug, 
then we can offer it to the top ten bugs ranked by people's votes.


There are flaws with that approach.  Some may say it does't give 
weight to payments based on complexity of bug (and that's true) and 
some would say it doesn't weigh importance of more recent bugs (and 
that's true).  Fixing those things add issues of their own and  maybe 
we want to take those issues on.  That's part of why I'm throwing it out.





On Thu, Jul 18, 2013 at 6:51 PM, Tim Spindler > wrote:


Rogan,

It is a little unclear what you are proposing.  Are you proposing
that bounties are given for fixing bugs?  Finding bugs? or Both?

Don't get me wrong, I think it has some real potential.  If we are
to put resources to it, I would advocate for rewarding those who
fix bugs because I'm sure many are pressured to add features but
not rewarded to fix bugs.

Tim


On Thu, Jul 18, 2013 at 5:58 PM, Rogan Hamby
mailto:rogan.ha...@yclibrary.net>> wrote:

I wanted to bring up an idea that has been kicked around by
several folks (including myself).  At this point I don't have
a fleshed out implementation proposal in mind but wanted to
throw it out for consideration.  The context of conversation
so far had been targeting older bugs though perhaps we should
weight them by priority as well.  What, how much and where are
big questions attached to funds.  But, I don't want to put the
cart before the horse.  This is a practice used successfully
by some other open source projects and I think there's merit
in considering it.

Excuse my brevity, sent from my iPhone

-- 


Rogan Hamby, MLS, CCNP, MIA
Managers Headquarters Library and Reference Services,
York County Library System

"You can never get a cup of tea large enough or a book long
enough to suit me."
-- C.S. Lewis





-- 
Tim Spindler

tjspind...@gmail.com 

*P**   Go Green - **Save a tree! Please don't print this e-mail
unless it's really necessary.*




--

Rogan Hamby, MLS, CCNP, MIA
Managers Headquarters Library and Reference Services,
York County Library System

"You can never get a cup of tea large enough or a book long

Re: [OPEN-ILS-GENERAL] Bug bounties

[Rogan Hamby]

I'll be honest it's partially unclear because this is bouncing it off
people thing at this point in time.  This probably frustrates some people
but I think these are things that as a community we should have dialogues
about.

If I were asked to put forth my personal vision it would be something like
this:

The community votes on bugs over X age (a year old?) using some kind of
mechanism and presumably ranks based on priority.  We then offer bug
bounties on a set rate to Y number of bugs based on how much we have in
that fund.  Let's say we have $1,000 and pay $100 per bug, then we can
offer it to the top ten bugs ranked by people's votes.

There are flaws with that approach.  Some may say it does't give weight to
payments based on complexity of bug (and that's true) and some would say it
doesn't weigh importance of more recent bugs (and that's true).  Fixing
those things add issues of their own and  maybe we want to take those
issues on.  That's part of why I'm throwing it out.




On Thu, Jul 18, 2013 at 6:51 PM, Tim Spindler  wrote:

> Rogan,
>
> It is a little unclear what you are proposing.  Are you proposing that
> bounties are given for fixing bugs?  Finding bugs? or Both?
>
> Don't get me wrong, I think it has some real potential.  If we are to put
> resources to it, I would advocate for rewarding those who fix bugs because
> I'm sure many are pressured to add features but not rewarded to fix bugs.
>
> Tim
>
>
> On Thu, Jul 18, 2013 at 5:58 PM, Rogan Hamby wrote:
>
>> I wanted to bring up an idea that has been kicked around by several folks
>> (including myself).  At this point I don't have a fleshed out
>> implementation proposal in mind but wanted to throw it out for
>> consideration.  The context of conversation so far had been targeting older
>> bugs though perhaps we should weight them by priority as well.  What, how
>> much and where are big questions attached to funds.  But, I don't want to
>> put the cart before the horse.  This is a practice used successfully by
>> some other open source projects and I think there's merit in considering it.
>>
>> Excuse my brevity, sent from my iPhone
>>
>> --
>>
>> Rogan Hamby, MLS, CCNP, MIA
>> Managers Headquarters Library and Reference Services,
>> York County Library System
>>
>> "You can never get a cup of tea large enough or a book long enough to
>> suit me."
>> -- C.S. Lewis 
>>
>>
>
>
> --
> Tim Spindler
> tjspind...@gmail.com
>
> *P**   Go Green - **Save a tree! Please don't print this e-mail unless
> it's really necessary.*
>
>
>



-- 

Rogan Hamby, MLS, CCNP, MIA
Managers Headquarters Library and Reference Services,
York County Library System

"You can never get a cup of tea large enough or a book long enough to suit
me."
-- C.S. Lewis 

Re: [OPEN-ILS-GENERAL] Bug bounties

[Tim Spindler]

Rogan,

It is a little unclear what you are proposing.  Are you proposing that
bounties are given for fixing bugs?  Finding bugs? or Both?

Don't get me wrong, I think it has some real potential.  If we are to put
resources to it, I would advocate for rewarding those who fix bugs because
I'm sure many are pressured to add features but not rewarded to fix bugs.

Tim


On Thu, Jul 18, 2013 at 5:58 PM, Rogan Hamby wrote:

> I wanted to bring up an idea that has been kicked around by several folks
> (including myself).  At this point I don't have a fleshed out
> implementation proposal in mind but wanted to throw it out for
> consideration.  The context of conversation so far had been targeting older
> bugs though perhaps we should weight them by priority as well.  What, how
> much and where are big questions attached to funds.  But, I don't want to
> put the cart before the horse.  This is a practice used successfully by
> some other open source projects and I think there's merit in considering it.
>
> Excuse my brevity, sent from my iPhone
>
> --
>
> Rogan Hamby, MLS, CCNP, MIA
> Managers Headquarters Library and Reference Services,
> York County Library System
>
> "You can never get a cup of tea large enough or a book long enough to suit
> me."
> -- C.S. Lewis 
>
>


-- 
Tim Spindler
tjspind...@gmail.com

*P**   Go Green - **Save a tree! Please don't print this e-mail unless it's
really necessary.*

[OPEN-ILS-GENERAL] Bug bounties

[Rogan Hamby]

I wanted to bring up an idea that has been kicked around by several folks 
(including myself).  At this point I don't have a fleshed out implementation 
proposal in mind but wanted to throw it out for consideration.  The context of 
conversation so far had been targeting older bugs though perhaps we should 
weight them by priority as well.  What, how much and where are big questions 
attached to funds.  But, I don't want to put the cart before the horse.  This 
is a practice used successfully by some other open source projects and I think 
there's merit in considering it.

Excuse my brevity, sent from my iPhone 

-- 

Rogan Hamby, MLS, CCNP, MIA
Managers Headquarters Library and Reference Services, 
York County Library System

“You can never get a cup of tea large enough or a book long enough to suit me.” 
― C.S. Lewis