On Mon, Aug 25, 2014 at 4:45 AM, Alan Kavanagh <alan.kavan...@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:jaypi...@gmail.com] > Sent: August-25-14 1:58 AM > To: openstack-dev@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
