<div dir="ltr">Looks like we need to make it totally clear in our policy...<div><br></div><div>> <span style="line-height:1.5">So we assume that detailed architectural work will be relayed to Component Leads</span></div><div><span style="line-height:1.5">I don't agree with this statement, as it implies that _all_ architectural work will be relayed to component leads.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">PTL is fully responsible for technical direction of the project. However, since the project is large, I'd expect that PTL will rely on Component Leads for most of particular technical decisions to be made.</span></div><div><span style="line-height:1.5">At the same time, PTL defines technical direction for the project, and ensures that component leads as well as others are aligned to it.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">If people are not aligned, it's job of PTL in the first order to:</span></div><div><span style="line-height:1.5">a) delegate alignment work to Component Lead if possible</span></div><div><span style="line-height:1.5">b) make yourself available to participate in alignment and resolving disputes, if component leads can't do it or if there is misalignment between Component Leads or Component Leads and PTL or Component Leads and PTLs of other OpenStack projects.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">I hope that this definition most of fuelers will find reasonable... but as I said, we need to spend some time and get it crystal clear in our policy.</span></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 6, 2015 at 8:45 AM Vladimir Kuklin <<a href="mailto:vkuklin@mirantis.com">vkuklin@mirantis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Which is actually contradictory and ambiguous and shows that PTL has less power than CLs while CLs at the same time have less power than PTL. I think this is the time when universe should collapse as we found that time-space is contradicting laws of propositional calculus.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 6:26 PM, Tomasz Napierala <span dir="ltr"><<a href="mailto:tnapierala@mirantis.com" target="_blank">tnapierala@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<br>
That’s right, but we made slight change here:<br>
<span>"Define architecture direction & review majority of design specs. Rely on Component Leads and Core Reviewers"<br>
<br>
</span>So we assume that detailed architectural work will be relayed to Component Leads<br>
<div><div><br>
<br>
> On 02 Oct 2015, at 10:12, Evgeniy L <<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>> wrote:<br>
><br>
> Hi Mike,<br>
><br>
> According to the description of the role, I wouldn't say that the role is less architectural than<br>
> political, since PTL should review designs and resolve conflicts between cores (which are<br>
> usually technical), PTL should also have strong skills in software architecture, and understanding<br>
> of what Fuel should look like.<br>
><br>
> Thanks,<br>
><br>
> On Thu, Oct 1, 2015 at 11:32 PM, Mike Scherbakov <<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>> wrote:<br>
> > we may mix technical direction / tech debt roadmap and process, political, and people management work of PTL.<br>
> sorry, of course I meant that we rather should NOT mix these things.<br>
><br>
> To make my email very short, I'd say PTL role is more political and process-wise rather than architectural.<br>
><br>
> On Wed, Sep 30, 2015 at 5:48 PM Mike Scherbakov <<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>> wrote:<br>
> Vladimir,<br>
> we may mix technical direction / tech debt roadmap and process, political, and people management work of PTL.<br>
><br>
> PTL definition in OpenStack [1] reflects many things which PTL becomes responsible for. This applies to Fuel as well.<br>
><br>
> I'd like to reflect some things here which I'd expect PTL doing, most of which will intersect with [1]:<br>
> - Participate in cross-project initiatives & resolution of issues around it. Great example is puppet-openstack vs Fuel [2]<br>
> - Organize required processes around launchpad bugs & blueprints<br>
> - Personal personal feedback to Fuel contributors & public suggestions when needed<br>
> - Define architecture direction & review majority of design specs. Rely on Component Leads and Core Reviewers<br>
> - Ensure that roadmap & use cases are aligned with architecture work<br>
> - Resolve conflicts between core reviewers, component leads. Get people to the same page<br>
> - Watch for code review queues and quality of reviews. Ensure discipline of code review.<br>
> - Testing / coverage have to be at the high level<br>
><br>
> Considering all above, contributors actually have been working with all of us and know who could be better handling such a hard work. I don't think special Q&A is needed. If there are concerns / particular process/tech questions we'd like to discuss - those should be just open as email threads.<br>
><br>
> [1] <a href="https://wiki.openstack.org/wiki/PTL_Guide" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/PTL_Guide</a><br>
> [2] <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-June/066685.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-June/066685.html</a><br>
><br>
> Thank you,<br>
><br>
> On Tue, Sep 29, 2015 at 3:47 AM Vladimir Kuklin <<a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a>> wrote:<br>
> Folks<br>
><br>
> I think it is awesome we have three candidates for PTL position in Fuel. I read all candidates' emails (including mine own several times :-) ) and I got a slight thought of not being able to really differentiate the candidates platforms as they are almost identical from the high-level point of view. But we all know that the devil is in details. And this details will actually affect project future.<br>
><br>
> Thus I thought about Q&A session at #fuel-dev channel in IRC. I think that this will be mutually benefitial for everyone to get our platforms a little bit more clear.<br>
><br>
> Let's do it before or right at the start of actual voting so that our contributors can make better decisions based on this session.<br>
><br>
> I suggest the following format:<br>
><br>
> 1) 3 questions from electorate members - let's put them onto an etherpad<br>
> 2) 2 questions from a candidate to his opponents (1 question per opponent)<br>
> 3) external moderator - I suppose, @xarses as our weekly meeting moderator could help us<br>
> 4) time and date - Wednesday or Thursday comfortable for both timezones, e.g. after 4PM UTC or right after fuel weekly meeting.<br>
><br>
> What do you think, folks?<br>
><br>
> --<br>
> Yours Faithfully,<br>
> Vladimir Kuklin,<br>
> Fuel Library Tech Lead,<br>
> Mirantis, Inc.<br>
> +7 (495) 640-49-04<br>
> +7 (926) 702-39-68<br>
> Skype kuklinvv<br>
> 35bk3, Vorontsovskaya Str.<br>
> Moscow, Russia,<br>
> <a href="http://www.mirantis.com" rel="noreferrer" target="_blank">www.mirantis.com</a><br>
> <a href="http://www.mirantis.ru" rel="noreferrer" target="_blank">www.mirantis.ru</a><br>
> <a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> --<br>
> Mike Scherbakov<br>
> #mihgen<br>
<br>
<br>
--<br>
</div></div>Tomasz 'Zen' Napierala<br>
Product Engineering - Poland<br>
<div><div><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>Skype kuklinvv<br>35bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></div></div></div>
</div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><div dir="ltr">-- <br></div><div dir="ltr">Mike Scherbakov<br>#mihgen</div>