Open Stack

On Mon, Aug 25, 2014 at 4:45 AM, Alan Kavanagh
<alan.kavanagh at ericsson.com> wrote:
> That's a fair point Jay. The Czar does sound like a reasonable approach and what would be useful and helpful would be to appoint additional PTL's and not have the burden of everything falling on one individual which becomes over loading after a period of time. In this case, imho it would be useful to have 2 or more PTL's assigned per project to adjust the workload and have different views and assess the "sticky points" with different views.
> /Alan
>
I disagree with this assessment. Having multiple PTLs defeated the
purpose of a PTL. Also, the PTL should be about building consensus,
not using a hammer as was noted in other parts of this thread. As
developers in Open Source, you have to be able to build consensus
before some ideas and concepts can move forward. The PTL, in my
opinion, is about helping to establish that consensus and being able
to say no when that consensus isn't built. I don't think having
multiple PTLs would help here.

Thanks,
Kyle

> -----Original Message-----
> From: Jay Pipes [mailto:jaypipes at gmail.com]
> Sent: August-25-14 1:58 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs
>
> On 08/23/2014 06:35 PM, Clint Byrum wrote:
>>  I agree as well. PTL is a servant of the community, as any good
>> leader is. If the PTL feels they have to drop the hammer, or if an
>> impass is reached where they are asked to, it is because they have
>> failed to get everyone communicating effectively, not because "that's their job."
>
> The problem isn't really that teams are not communicating effectively, nor is the problem to do with some deficit of a PTL in either putting the hammer down or failing to figure out common ground.
>
> The issue in my opinion and my experience is that there are multiple valid ways of doing something (say, deployment or metering or making
> toast) and the TC and our governing structure has decided to pick winners in spaces instead of having a big tent and welcoming different solutions and projects into the OpenStack fold. We pick winners and by doing so, we are exclusionary, and this exclusivity does not benefit our user community, but rather just gives it fewer options.
>
> IMHO, the TC should become an advisory team that recommends to interested project teams ways in which they can design and architect their projects to integrate well with other projects in the OpenStack community, and design their projects for the scale, stability and requirements (such as multi-tenancy) that an open cloud software ecosystem demands.
>
> Just my two cents,
> -jay
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev