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
[email protected]
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 <[email protected]
<mailto:[email protected]>> 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>
