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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
