[os-infrastructure] Experience with a Community contribution

[David Tondreau]

Hi Alex,

This is an interesting experience you had so I "peeled this layer off 
the onion" and gave it a new name.  I'd like to discuss your experience 
managing a community contribution separately because I'd like to get a 
feel for what to expect for us down the road.

Your experience is in line with what I would have suspected --  
contributions from the community that need review, testing, adjustment 
or rework before they can be incorporated into the product.  It seems 
like they required a bit more than just baking in the oven for a few 
days.  I have some questions for you based on your experience.

   1. How did you get the code from Marty and Chris?  E-mail?
   2. How much code was it?
   3. How much time, if any, would have been saved if Marty and Chris
      could have submitted it directly into source management?
   4. Would there have been any other downsides of them doing that?
   5. Did Marty or Chris ever ask if they could have direct access to
      the code repository?  Do you think they expected that?
   6. Would you have handled the contributions differently if they did
      have access to the repository?  For instance, do you think that
      instead of doing the rework yourself, you might have simply
      rejected the change and told them to re-implement the code based
      on our standards? 
   7. Normally, a code change requiring rework would be rejected and
      sent back to the originating engineer for them to make the
      corrections.  Do you think a contribution from a community member
      needs to be treated differently than from an internal engineer. 
      By that, I mean do we need to treat people like Marty and Chris
      with "kid gloves" because we want to encourage participation?
   8. Given the contributions that were made, do you think you spent
      more or less time time reviewing and correcting their submissions
      than it would have take if you had simply originated the changes
      yourself?
   9. What was your general opinion of the quality of the code you
      received.  Can you say it was 70%, 80%, 90% or 99% done?
  10. What are your feelings about priorities.  You mentioned that these
      two contributions were probably pretty low on the priority scale
      relative to other items in Service Desk.  But you ended up
      spending time on them (presumably to be responsive to and
      encourage the community) which probably means you didn't get other
      stuff done.  What are you thoughts on how we should prioritize
      this work?

Sorry to be such a load of questions but I'm stumbling around in the 
dark on this stuff sometimes and you've got some good first hand experience.

David



On 06/09/2008 05:39 AM, Alex Hanshaw wrote:
>  I recently implemented code changes from Marty Bowes and Chris Dawe.
> Both were performance enhancements to the copydb code.
> Marty's changes needed review implementation and a little testing.
> Chris Dawe's changes needed to be rewritten to use generic code rather
> than platform specific OS calls. Neither change was low cost in terms of
> my time. The collateral testing needed to make sure Chris Dawe's changes
> were OK was fairly high.
>  By educating community contributors and placing a higher bar on what we
> try to integrate this cost could be reduced.
>  My assessment of these two changes is that they made improvements that
> were important to these two individuals and consumed resources that
> could have been used on higher priority issues. Both individuals had
> invested time in establishing their changes and proving the benefits
> that can now be seem by other customers going forward. I'd question the
> importance of these changes compared to the bugs listed in Service Desk
> issues but there's no denying that Marty and Chris spent time trying to
> make Ingres better which long term reduces our cost to improve Ingres.
>  DBMS changes are more likely to come from partners that need specific
> functionality. Apart from Karl I've not seen any so far.
>
>  Alex
>
>