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

[Juan Jesús Ojeda Croissier < >]

On Wed, Feb 8, 2012 at 1:56 AM, Bryan McLellan 
<
 >
 wrote:
> 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?
>

There is a initiative at GNOME project that could give us some ideas.
They call it: GNOME Love:
https://live.gnome.org/GnomeLove

This is a project to make easier the entry to newcomers. There are
different things like:
 * Documentation about how to contribute
 * List of easy bugs so the people get used to the process
 * List of good practices
 * Documentation about how to test things and how to triage
 * List of mentors (core member and contributors who like to help)
 * irc channel and maillist to share the newcomer their questions and
get the mentors around

And some other things. Everything on one place to have a visible a
easy point of entry.
This is being set up by core members but improved by the new contributes.

This may not be the answer to the toughest bugs, but could be good for
get more people involved.

Here is also the Mozilla's Bug Bounty Program, in case it could help:
http://www.mozilla.org/security/bug-bounty.html

Cheers :-)

-- 
Juanje