Open Stack

Looks like we need to make it totally clear in our policy...

> So we assume that detailed architectural work will be relayed to
Component Leads
I don't agree with this statement, as it implies that _all_ architectural
work will be relayed to component leads.

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.
At the same time, PTL defines technical direction for the project, and
ensures that component leads as well as others are aligned to it.

If people are not aligned, it's job of PTL in the first order to:
a) delegate alignment work to Component Lead if possible
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.

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.

On Tue, Oct 6, 2015 at 8:45 AM Vladimir Kuklin <vkuklin at mirantis.com> wrote:

> 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.
>
> On Tue, Oct 6, 2015 at 6:26 PM, Tomasz Napierala <tnapierala at mirantis.com>
> wrote:
>
>> Hi
>>
>> That’s right, but we made slight change here:
>> "Define architecture direction & review majority of design specs. Rely on
>> Component Leads and Core Reviewers"
>>
>> So we assume that detailed architectural work will be relayed to
>> Component Leads
>>
>>
>> > On 02 Oct 2015, at 10:12, Evgeniy L <eli at mirantis.com> wrote:
>> >
>> > Hi Mike,
>> >
>> > According to the description of the role, I wouldn't say that the role
>> is less architectural than
>> > political, since PTL should review designs and resolve conflicts
>> between cores (which are
>> > usually technical), PTL should also have strong skills in software
>> architecture, and understanding
>> > of what Fuel should look like.
>> >
>> > Thanks,
>> >
>> > On Thu, Oct 1, 2015 at 11:32 PM, Mike Scherbakov <
>> mscherbakov at mirantis.com> wrote:
>> > > we may mix technical direction / tech debt roadmap and process,
>> political, and people management work of PTL.
>> > sorry, of course I meant that we rather should NOT mix these things.
>> >
>> > To make my email very short, I'd say PTL role is more political and
>> process-wise rather than architectural.
>> >
>> > On Wed, Sep 30, 2015 at 5:48 PM Mike Scherbakov <
>> mscherbakov at mirantis.com> wrote:
>> > Vladimir,
>> > we may mix technical direction / tech debt roadmap and process,
>> political, and people management work of PTL.
>> >
>> > PTL definition in OpenStack [1] reflects many things which PTL becomes
>> responsible for. This applies to Fuel as well.
>> >
>> > I'd like to reflect some things here which I'd expect PTL doing, most
>> of which will intersect with [1]:
>> > - Participate in cross-project initiatives & resolution of issues
>> around it. Great example is puppet-openstack vs Fuel [2]
>> > - Organize required processes around launchpad bugs & blueprints
>> > - Personal personal feedback to Fuel contributors & public suggestions
>> when needed
>> > - Define architecture direction & review majority of design specs. Rely
>> on Component Leads and Core Reviewers
>> > - Ensure that roadmap & use cases are aligned with architecture work
>> > - Resolve conflicts between core reviewers, component leads. Get people
>> to the same page
>> > - Watch for code review queues and quality of reviews. Ensure
>> discipline of code review.
>> > - Testing / coverage have to be at the high level
>> >
>> > 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.
>> >
>> > [1] https://wiki.openstack.org/wiki/PTL_Guide
>> > [2]
>> http://lists.openstack.org/pipermail/openstack-dev/2015-June/066685.html
>> >
>> > Thank you,
>> >
>> > On Tue, Sep 29, 2015 at 3:47 AM Vladimir Kuklin <vkuklin at mirantis.com>
>> wrote:
>> > Folks
>> >
>> > 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.
>> >
>> > 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.
>> >
>> > 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.
>> >
>> > I suggest the following format:
>> >
>> > 1) 3 questions from electorate members - let's put them onto an etherpad
>> > 2) 2 questions from a candidate to his opponents (1 question per
>> opponent)
>> > 3) external moderator - I suppose, @xarses as our weekly meeting
>> moderator could help us
>> > 4) time and date - Wednesday or Thursday comfortable for both
>> timezones, e.g. after 4PM UTC or right after fuel weekly meeting.
>> >
>> > What do you think, folks?
>> >
>> > --
>> > Yours Faithfully,
>> > Vladimir Kuklin,
>> > Fuel Library Tech Lead,
>> > Mirantis, Inc.
>> > +7 (495) 640-49-04
>> > +7 (926) 702-39-68
>> > Skype kuklinvv
>> > 35bk3, Vorontsovskaya Str.
>> > Moscow, Russia,
>> > www.mirantis.com
>> > www.mirantis.ru
>> > vkuklin at mirantis.com
>> >
>> __________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> > --
>> > Mike Scherbakov
>> > #mihgen
>>
>>
>> --
>> Tomasz 'Zen' Napierala
>> Product Engineering - Poland
>>
>>
>>
>>
>>
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com <http://www.mirantis.ru/>
> www.mirantis.ru
> vkuklin at mirantis.com
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151007/d4af1d67/attachment.html>