[OPEN-ILS-GENERAL] Bug bounties

Wed Jul 31 15:46:50 EDT 2013

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
klussier at 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 <dan at coffeecode.net 
> <mailto:dan at coffeecode.net>> 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 <http://www.goodreads.com/author/show/1069006.C_S_Lewis>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20130731/0ad8c19f/attachment-0001.htm>