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 <kluss...@masslnc.org> 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 other ideas out there for addressing the > issue of dusty bugs. > > > Kathy > > > > Kathy Lussier > Project Coordinator > Massachusetts Library Network Cooperative(508) 343-0128kluss...@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 <d...@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> > > > -- 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>