Open Stack

I think this discussion could potential shape a new business model for 
how contributors are supported as they work with OpenStack.

One difficulty I foresee with Jesus' model is the potential for the 
"Contributed for:" line playing a role in the decision to approve a 
patch vs recommending it being abandoned. Patches get abandoned all the 
time, it is just part of the process, but creating the patch takes work 
and effort, which need to be supported in some fashion. If the business 
model is such that we are creating a scenario which might be perceived 
that only merged patches have value, then pressure might be put on 
reviewers to approve "Contributed for:" patches to ensure the 
contributor gets paid. I don't like scenarios where my vote might hinder 
someone from feeding their family. So I would vote the patch in, so the 
contributer can eat, but the code might suffer.

Perhaps I am taking the scenario too far and this would never happen.

I agree that all the work needs to be acknowledged: wiki page creation 
and maintenance, bug report creation, closing bugs, reviews and all the 
other tasks which we can't function without but which we have difficulty 
quantifying in a stat. How to train companies wanting to state they 
contribute to OpenStack that all the tasks are necessary and have value, 
not just merging of patches?

I don't know.

Thanks,
Anita.

On 13-06-17 05:34 PM, Jesus M. Gonzalez-Barahona wrote:
> For the reports on contributions to releases, we're counting individual
> controbibutions (as gitdm guys do), and then we have a table (which
> should have pretty much the same info that the gitdm table has), which
> states that developer D works for company C for such and such period.
> So, I guess we use basically the same methodology.
>
> An Monty suggests, if a certain developer can be counted as working for
> a certain company during a certain period, it really doesn't matter if
> she/he is working subcontracted, or what.
>
> I see two cases that could not be tracked with this schema:
>
> - Developer D working for company B and C at the same time (maybe
> because of subcontracting, or whatever). The only chance I see here is
> to label each commit somehow, maybe with the "Contributed for:
> <affiliation>" field suggested by Stefano.
>
> - Developer D working for company C, which during a certain period is
> subcontracting for company D. In this  case, both D and C could be
> interested in appearing as "contributors", probably in different
> classifications. If we come to direct affiliations, C would be the
> contributor. If we come to "who is paying", it would be D. Probably
> having both rankings would be important: company C would be interested
> in others knowing that they have expertise in working in OpenStack,
> while company D would be interested in showing their contributions. This
> could be tracked with an extended table, including not only affiliation
> (as we do now), but also subcontracting (for which company is really
> working each developer, for each period).
>
> Of course, both cases could happen at the same time, but I don't know if
> that actually happens.
>
> In addition, it is important to notice that we're also trying to track
> closing tickets, messages, etc. which complicates things, since we would
> need (in the case of tracking specific contributions) similar labels for
> all of this.
>
> Just my two (euro)cents,
>
> 	Jesus.
>