Open Stack

I just looked at the Gerrit docs and saw that there is a "your category here" option that would allow adding a category to the already existing ones.  It can be set as blocking (not what we would want) or non-blocking.  I think this could be used to credit a sponsor ("courtesy of") without mucking up git logs or commit messages.  It would be searchable.  It would cover bugfixes.  It would be a way to keep some control over the statistics.  An owner/author would add the field and value and it would be attached to the review.

Is this a possibility and is it inobtrusive enough while giving credit to keep companies interested?

--Rocky



Monty Taylor wrote:

On 11/11/2013 11:41 AM, Russell Bryant wrote:
> On 11/11/2013 10:57 AM, Mark McLoughlin wrote:
>> Hi Nick,
>>
>> On Mon, 2013-11-11 at 15:20 +0100, Nicolas Barcet wrote:
>>> Dear TC members,
>>>
>>> Our companies are actively encouraging our respective customers to have the
>>> patches they mission us to make be contributed back upstream.  In order to
>>> encourage this behavior from them and others, it would be nice that if
>>> could gain some visibility as "sponsors" of the patches in the same way we
>>> get visibility as "authors" of the patches today.
>>>
>>> The goal here is not to provide yet another way to count affiliations of
>>> direct contributors, nor is it a way to introduce sales pitches in contrib.
>>>  The only acceptable and appropriate use of the proposal we are making is
>>> to signal when a patch made by a contributor for another comany than the
>>> one he is currently employed by.
>>>
>>> For example if I work for a company A and write a patch as part of an
>>> engagement with company B, I would signal that Company B is the sponsor of
>>> my patch this way, not Company A.  Company B would under current
>>> circumstances not get any credit for their indirect contribution to our
>>> code base, while I think it is our intent to encourage them to contribute,
>>> even indirectly.
>>>
>>> To enable this, we are proposing that the commit text of a patch may
>>> include a
>>>    sponsored-by: <sponsorname>
>>> line which could be used by various tools to report on these commits.
>>>  Sponsored-by should not be used to report on the name of the company the
>>> contributor is already affiliated to.
>>
>> Honestly, I've an immediately negative reaction to the prospect of e.g.
>>
>>   Sponsored-By: Red Hat
>>   Sponsored-By: IBM
>>
>> appearing in our commit messages.
>>
>> I feel strongly that the project is first and foremost a community of
>> individuals and we instinctively push as much of corporate backing side
>> of things outside of the project. We try to spend as little time as
>> possible talking about our affiliations as possible.
>>
>> And, IMHO, the git commit log is particularly sacred ground - almost
>> above anything else, it is a place for purely technical details.
> 
> This was exactly my reaction, as well.  I just hadn't been able to come
> up with a good alternate proposal, yet.
> 
>> However, I do think we'll be able to figure out some way of making it
>> easier for tools to track more complex affiliations.
>>
>> Our affiliation databases are all keyed off email addresses right now,
>> so how about if we allowed for encoding affiliation/sponsorship in
>> addresses? e.g.
>>
>>   Author: Mark McLoughlin <markmc+ibm at redhat.com>
>>
>> and we could register that address as "work done by Mark on behalf of
>> IBM" ?
> 
> That doesn't seem any better to me.  It actually seems more likely to
> break, since someone could be using an email address with '+' in it for
> some other reason, right?
> 
> I think it may be worth looking at this from a different angle.  Perhaps
> we should tone down the focus on company metrics, and perhaps remove
> them completely from anything we control or have influence over.


While I agree with the sentiment strongly - I like that the things we
control have them, because it means we can shape them with some sanity.
The companies all want to track this data, and will track this data. If
we don't have a hand in it, it's going to get tracked elsewhere and
probably in a much more biased manner.

Amazing as it may seem, the competitive nature amongst the companies on
this has been a positive thing so far. In a status report I sent up the
chain at HP recently, I was able to point at HP's participation, as well
as my team's role in that - net result - more headcount for Monty, which
as I'm sure we all know means more heads working on core openstack
things that are not driven by vendor plugins.

Remember that the folks paying for all of us to work on an Open Source
project are doing so for a myriad of reasons, and not all of them are
"because Open Source is the right thing to do" The more we can provide
ammunition to those of us who are straddling the line of getting and
allocating those resources, the better.

So, back to the proposal at hand - I think Mark is right that the git
commit log isn't really the place to try to capture that - but I'm not
sure I grok where the right place is. Perhaps we need to brainstorm more?

Monty

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev