[chef-dev] Re: Re: Re: Re: Incentivizing open source, possible bounty program?

[Bryan McLellan < >]

On Tue, Feb 7, 2012 at 6:49 PM, Eric G. Wolfe 
<
 >
 wrote:
> It has been my experience that people already do this when they see the
> Opscode shirts.  If I happen to be wearing an Opscode T-Shirt at a
> conference, then it ultimately leads to a conversation about Chef.

For sure, but I think we're talking about something more special that
you only get if you're a contributor.

> I like Ann's idea of an incentive to have conference admission compensated
> for key community contributors.

We've done something like this in the past. We do try to take care of
our key contributors and MVPs. I think it would be high cost to
develop and sustain a fair award based system that gets you into a
conference. Lots of energy would be spent trying to translate
contributions into points and there would be too much room for being
shorted. I'm reminded of the reasons you're not supposed to pay
developers for lines of code and testers for bugs found; even honest
well-intentioned people end up getting hurt by the system.

> I also like James' idea of putting a monetary bounty on high priority
> bugs/issues.  That would probably work well for many independent
> consultants, looking for work when business is slow.  Monetary bounties may
> not fly for certain community developers, if there happens to be any ethical
> non-compete issue with their employment contract, however.

Right. This is where everyone jumps to at the word 'bounty.' I don't
even know if we could legally set up a framework for something like
this. I'll obviously have to have big talks with legal and HR to see
if we could do it and under what circumstances. Noah pointed out the
Python Software Foundation grants program [1], which appears to be a
more flexible way to approach this sort of thing. This also puts more
expectation on the contributor to put the energy into defining the
body of work, which I like because it requires less up-front and
on-going work on my part to maintain something that may not get used.

> I wasn't fully aware there was a list of high priority bugs.  Is there a
> better way to highlight which outstanding issues are a top priority, and
> bounty worthy, maybe within JIRA?

What I did with 'Get Involved' was a list of projects and a
description of their difficulty for new people who didn't know where
to start. I've curated it a few times, and can continue doing so if it
is useful to people. I'm not sure yet if this project crosses the line
from "you know what you should do" into "you know what I would do if
you did this." Jury is still out.

So there is not a list of high priority bugs. You can, of course,
search JIRA. We don't have a formal triage program that sets priority
on tickets in JIRA though, that is left up to the reporter mostly.
Here's what we've done so far.

About a year ago we started a weekly triage meeting at Opscode where a
group of us sit down and review "resolved/fixed" tickets for all the
projects in JIRA. If everything looks in order, such as a CLA, tests
where appropriate, good code, we mark it "Triaged," which puts it in
queue for the merge pass. After doing this for a while we caught up
with the backlog and we often spend some time reviewing pull requests,
particularly for new contributors who don't know about our ticketing
system and CLA requirements.

A couple of months ago we started another weekly OSS triage meeting,
where we look for any issues that have bubbled to the surface that we
would like to put into the Opscode Engineering backlog. However, just
because we think something would be swell to fix, doesn't
automatically justify spending engineering resource on it, especially
when we have a number of internal projects vying for these resources.
This is why I'm looking for another resource for some of these.

I've thought a lot about creating a better workflow on JIRA and
working out a process for a more complete triage workflow that would
set priority. We have extremely limited resources though, so we have
to weigh what work would really help you folks out and ensure that the
benefits are worth while.

It isn't that hard to search JIRA for an open Chef ticket, reproduce
it, and start fixing it. I'm unconvinced that if I took the time to
review and estimate most of the open tickets for difficulty, that more
people would contribute fixes. Are there really people on this list
who would be contributing more but have chosen to work on tickets that
turned out to be too hard for them, and since have stopped trying out
of fear of repeating this? Keep in mind that the time I would spend
estimating ticket difficulty could be spent doing other helpful work,
like fixing bugs.

Which brings me back to the original question, what can I do for you
that would help you?

-- 
Bryan McLellan | opscode | technical program manager
(c) 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org

[1] http://www.python.org/psf/grants/