James Polley wrote:
> I'm fairly certain the buzzing sound I can hear is a bee in my bonnet...
> so I suspect that I'm starting to sound like someone chasing a bee that
> only they can hear. I'm not sure if it's helpful to keep this discussion
> on this list - would there be a better forum somewher
I'm fairly certain the buzzing sound I can hear is a bee in my bonnet... so
I suspect that I'm starting to sound like someone chasing a bee that only
they can hear. I'm not sure if it's helpful to keep this discussion on this
list - would there be a better forum somewhere else?
On Fri, Aug 29, 20
James Polley wrote:
>
> > However, Thierry pointed
> > to https://wiki.openstack.org/wiki/Governance/Foundation/Structure
> which
> > still refers to Project Technical Leads and says explicitly that they
> > lead individual projects, not programs. I actually have edit access to
On Thu, Aug 28, 2014 at 10:40 PM, Thierry Carrez
wrote:
> James Polley wrote:
> >>> Point of clarification: I've heard PTL=Project Technical Lead
> >>> and PTL=Program Technical Lead. Which is it? It is kind of
> >>> important as OpenStack grows, because the first is res
James Polley wrote:
>>> Point of clarification: I've heard PTL=Project Technical Lead
>>> and PTL=Program Technical Lead. Which is it? It is kind of
>>> important as OpenStack grows, because the first is responsible
>>> for *a* project, and the second is responsibl
On Sat, Aug 23, 2014 at 11:02 AM, Anne Gentle wrote:
>
>
>
> On Fri, Aug 22, 2014 at 6:17 PM, Rochelle.RochelleGrober <
> rochelle.gro...@huawei.com> wrote:
>
>> /flame-on
>> Ok, this is funny to some of us in the community. The general populace
>> of this community is so against the idea of man
On Aug 26, 2014, at 11:28 AM, Matthew Treinish wrote:
> On Tue, Aug 26, 2014 at 10:04:41AM -0400, Doug Hellmann wrote:
>>
>> On Aug 26, 2014, at 5:13 AM, Thierry Carrez wrote:
>>
>>> OK, now that we have evacuated the terminology issue (we'll use liaison
>>> or janitor or secretary, not czar)
On Tue, Aug 26, 2014 at 10:04:41AM -0400, Doug Hellmann wrote:
>
> On Aug 26, 2014, at 5:13 AM, Thierry Carrez wrote:
>
> > OK, now that we have evacuated the terminology issue (we'll use liaison
> > or janitor or secretary, not czar), and side-stepped the offtopic
> > development (this is not a
On 08/26/2014 10:04 AM, Doug Hellmann wrote:
On Aug 26, 2014, at 5:13 AM, Thierry Carrez wrote:
OK, now that we have evacuated the terminology issue (we'll use liaison
or janitor or secretary, not czar), and side-stepped the offtopic
development (this is not about suppressing PTLs, just a fram
On 08/26/2014 05:13 AM, Thierry Carrez wrote:
> OK, now that we have evacuated the terminology issue (we'll use liaison
> or janitor or secretary, not czar), and side-stepped the offtopic
> development (this is not about suppressing PTLs, just a framework to let
> them delegate along predetermined
On Tue, Aug 26, 2014 at 9:48 AM, Doug Hellmann wrote:
>
> On Aug 26, 2014, at 10:10 AM, Kyle Mestery wrote:
>
>> On Fri, Aug 22, 2014 at 8:19 PM, John Dickinson wrote:
>>> I think Anne makes some excellent points about the pattern being proposed
>>> being unlikely to be commonly implemented acr
On Aug 26, 2014, at 10:10 AM, Kyle Mestery wrote:
> On Fri, Aug 22, 2014 at 8:19 PM, John Dickinson wrote:
>> I think Anne makes some excellent points about the pattern being proposed
>> being unlikely to be commonly implemented across all the programs (or, at
>> best, very difficult). Let's
-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 th
On Fri, Aug 22, 2014 at 8:19 PM, John Dickinson wrote:
> I think Anne makes some excellent points about the pattern being proposed
> being unlikely to be commonly implemented across all the programs (or, at
> best, very difficult). Let's not try to formalize another "best practice"
> that works
On Aug 26, 2014, at 5:13 AM, Thierry Carrez wrote:
> OK, now that we have evacuated the terminology issue (we'll use liaison
> or janitor or secretary, not czar), and side-stepped the offtopic
> development (this is not about suppressing PTLs, just a framework to let
> them delegate along predet
On 08/26/2014 11:13 AM, Thierry Carrez wrote:
> OK, now that we have evacuated the terminology issue (we'll use liaison
> or janitor or secretary, not czar), and side-stepped the offtopic
> development (this is not about suppressing PTLs, just a framework to let
> them delegate along predetermined
OK, now that we have evacuated the terminology issue (we'll use liaison
or janitor or secretary, not czar), and side-stepped the offtopic
development (this is not about suppressing PTLs, just a framework to let
them delegate along predetermined lines if they want to)... which of
those unnamed roles
On 08/22/2014 08:19 PM, John Dickinson wrote:
> I think Anne makes some excellent points about the pattern being
> proposed being unlikely to be commonly implemented across all the
> programs (or, at best, very difficult). Let's not try to formalize
> another "best practice" that works many times a
Zane Bitter [August 25, 2014 1:38 PM] wrote:
. . .
>
> I'd say we've done fairly well, but I would attribute that at least in
> part to the fact that we've treated the PTL as effectively the
> temporary
> "release management contact" more than the "guy who will resolve
> disputes for us". In
On Mon 25 Aug 2014 03:38:18 PM CDT, Zane Bitter wrote:
> I'd say we've done fairly well, but I would attribute that at least in
> part to the fact that we've treated the PTL as effectively the
> temporary "release management contact" more than the "guy who will
> resolve disputes for us". In other
On 25/08/14 06:30, Thierry Carrez wrote:
Zane Bitter wrote:
On 22/08/14 12:45, Dolph Mathews wrote:
I'm all for getting a final decision, but a 'final' decision that
has been
imposed from outside rather than internalised by the participants is...
rarely final.
The expectation of a PTL isn't
On 2014-08-25 19:39:30 + (+), Rochelle.RochelleGrober wrote:
> Or, how about Secretary?
[...]
While we're painting this particular bike shed, I have a preference
for "janitor," "drudge," "mule," "valet," "slogger" or similar terms
which make it apparent that there is nothing at all glamoro
Zane Bitter wrote:
> On 22/08/14 21:02, Anne Gentle wrote:
> > I'm with Rocky on the anti-czar-as-a-word camp. We all like clever
> names to
> > shed the "corporate" stigma but this word ain't it. Liaison or lead?
>
> +1. The only time you hear the word 'czar' in regular life (outside of
> refer
On Aug 23, 2014, at 6:35 PM, Clint Byrum wrote:
> Excerpts from Dolph Mathews's message of 2014-08-22 09:45:37 -0700:
>> On Fri, Aug 22, 2014 at 11:32 AM, Zane Bitter wrote:
>>
>>> On 22/08/14 11:19, Thierry Carrez wrote:
>>>
Zane Bitter wrote:
> On 22/08/14 08:33, Thierry Carr
On 22/08/14 21:02, Anne Gentle wrote:
I'm with Rocky on the anti-czar-as-a-word camp. We all like clever names to
shed the "corporate" stigma but this word ain't it. Liaison or lead?
+1. The only time you hear the word 'czar' in regular life (outside of
references to pre-revolutionary Russia)
On 08/25/2014 12:30 PM, Thierry Carrez wrote:
> Zane Bitter wrote:
>> On 22/08/14 12:45, Dolph Mathews wrote:
> I'm all for getting a final decision, but a 'final' decision that
has been
> imposed from outside rather than internalised by the participants is...
> rarely final.
>
Tim Bell wrote:
> As part of the user feedback loop, we've found the PTL role extremely useful
> to channel feedback. The operator PTL discussions during the Atlanta summit
> helped to clarify a number of areas where the PTL can then take the points
> back to the design summit. It is not clear
Zane Bitter wrote:
> On 22/08/14 12:45, Dolph Mathews wrote:
>>> >I'm all for getting a final decision, but a 'final' decision that
>>> has been
>>> >imposed from outside rather than internalised by the participants is...
>>> >rarely final.
>>> >
>> The expectation of a PTL isn't to stomp around an
Anne Gentle wrote:
> Rochelle.RochelleGrober wrote:
>>/flame-on
>> Let's call spades, spades here. Czar is not only overkill, but the
>> wrong metaphor.
>> /flame-off
>
> I'm with Rocky on the anti-czar-as-a-word camp. We all like clever names
> to shed the "corporate" stigma but
k-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
> impa
On 08/22/2014 09:02 PM, Anne Gentle wrote:
/flame-on
Let's call spades, spades here. Czar is not only overkill, but
the wrong metaphor.
/flame-off
I'm with Rocky on the anti-czar-as-a-word camp. We all like clever
names to shed the "corporate" stigma but this word ain't it.
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 b
On Fri, Aug 22, 2014 at 02:33:27PM +0200, Thierry Carrez wrote:
[Snip some well articulated thoughts.]
> Enter the Czar system: each project should have a number of liaisons /
> official contacts / delegates that are fully responsible to cover one
> aspect of the project. We need to have Bugs cza
Excerpts from Dolph Mathews's message of 2014-08-22 09:45:37 -0700:
> On Fri, Aug 22, 2014 at 11:32 AM, Zane Bitter wrote:
>
> > On 22/08/14 11:19, Thierry Carrez wrote:
> >
> >> Zane Bitter wrote:
> >>
> >>> On 22/08/14 08:33, Thierry Carrez wrote:
> >>>
> We also
> still need someone
> -Original Message-
> From: John Dickinson [mailto:m...@not.mn]
> Sent: 23 August 2014 03:20
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale
> PTLs
>
> I think A
I think Anne makes some excellent points about the pattern being proposed being
unlikely to be commonly implemented across all the programs (or, at best, very
difficult). Let's not try to formalize another "best practice" that works many
times and force it to work every time. Here's an alternate
On Fri, Aug 22, 2014 at 6:17 PM, Rochelle.RochelleGrober <
rochelle.gro...@huawei.com> wrote:
> /flame-on
> Ok, this is funny to some of us in the community. The general populace of
> this community is so against the idea of management that they will use the
> term for a despotic dictator as a po
/flame-on
Ok, this is funny to some of us in the community. The general populace of this
community is so against the idea of management that they will use the term for
a despotic dictator as a position name rather than "manager". Sorry, but this
needed to be said.
/flame-off
Specific comments
On 22/08/14 12:45, Dolph Mathews wrote:
>I'm all for getting a final decision, but a 'final' decision that has been
>imposed from outside rather than internalised by the participants is...
>rarely final.
>
The expectation of a PTL isn't to stomp around and make "final" decisions,
it's to step in
On Fri, Aug 22, 2014 at 10:51 AM, Jay Pipes wrote:
> On 08/22/2014 08:33 AM, Thierry Carrez wrote:
>
>> Hi everyone,
>>
>> We all know being a project PTL is an extremely busy job. That's because
>> in our structure the PTL is responsible for almost everything in a
>> project:
>>
>> - Release man
On 08/22/2014 08:33 AM, Thierry Carrez wrote:
Hi everyone,
We all know being a project PTL is an extremely busy job. That's because
in our structure the PTL is responsible for almost everything in a project:
- Release management contact
- Work prioritization
- Keeping bugs under control
- Commu
On Fri, Aug 22, 2014 at 11:32 AM, Zane Bitter wrote:
> On 22/08/14 11:19, Thierry Carrez wrote:
>
>> Zane Bitter wrote:
>>
>>> On 22/08/14 08:33, Thierry Carrez wrote:
>>>
We also
still need someone to have the final say in case of deadlocked issues.
>>>
>>> -1 we really don't.
>>>
On 22/08/14 11:19, Thierry Carrez wrote:
Zane Bitter wrote:
On 22/08/14 08:33, Thierry Carrez wrote:
We also
still need someone to have the final say in case of deadlocked issues.
-1 we really don't.
I know we disagree on that :)
No problem, you and I work in different programs so we can
On 22 August 2014 16:19, Thierry Carrez wrote:
> Zane Bitter wrote:
>>> People say we don't have that many deadlocks in OpenStack for which the
>>> PTL ultimate power is needed, so we could get rid of them. I'd argue
>>> that the main reason we don't have that many deadlocks in OpenStack is
>>>
On Fri, Aug 22, 2014 at 9:13 AM, Daniel P. Berrange
wrote:
> On Fri, Aug 22, 2014 at 02:33:27PM +0200, Thierry Carrez wrote:
> > Hi everyone,
> >
> > We all know being a project PTL is an extremely busy job. That's because
> > in our structure the PTL is responsible for almost everything in a
> p
On Fri, 2014-08-22 at 11:01 -0400, Zane Bitter wrote:
> I don't see that as something the wider OpenStack community needs to
> dictate. We have a heavyweight election process for PTLs once every
> cycle because that used to be the process for electing the TC. Now that
> it no longer serves this
Zane Bitter wrote:
> On 22/08/14 08:33, Thierry Carrez wrote:
>> We also
>> still need someone to have the final say in case of deadlocked issues.
>
> -1 we really don't.
I know we disagree on that :)
>> People say we don't have that many deadlocks in OpenStack for which the
>> PTL ultimate powe
Daniel P. Berrange wrote:
> On Fri, Aug 22, 2014 at 02:33:27PM +0200, Thierry Carrez wrote:
>> Hi everyone,
>>
>> We all know being a project PTL is an extremely busy job. That's because
>> in our structure the PTL is responsible for almost everything in a project:
>>
>> - Release management contac
Russell Bryant wrote:
> On 08/22/2014 09:40 AM, Russell Bryant wrote:
>> Another area worth calling out is a gate czar. Having someone who
>> understands infra and QA quite well and is regularly on top of the
>> status of the project in the gate is helpful and quite important.
>
> Oops, you said
On 22/08/14 08:33, Thierry Carrez wrote:
Hi everyone,
We all know being a project PTL is an extremely busy job. That's because
in our structure the PTL is responsible for almost everything in a project:
- Release management contact
- Work prioritization
- Keeping bugs under control
- Communicat
On 08/22/2014 02:33 PM, Thierry Carrez wrote:
> Hi everyone,
>
> We all know being a project PTL is an extremely busy job. That's because
> in our structure the PTL is responsible for almost everything in a project:
>
> - Release management contact
> - Work prioritization
> - Keeping bugs under c
On Fri, Aug 22, 2014 at 02:33:27PM +0200, Thierry Carrez wrote:
> Hi everyone,
>
> We all know being a project PTL is an extremely busy job. That's because
> in our structure the PTL is responsible for almost everything in a project:
>
> - Release management contact
> - Work prioritization
> - Ke
On 08/22/2014 07:33 AM, Thierry Carrez wrote:
> Hi everyone,
>
> We all know being a project PTL is an extremely busy job. That's because
> in our structure the PTL is responsible for almost everything in a project:
>
> - Release management contact
> - Work prioritization
> - Keeping bugs under c
On 08/22/2014 09:40 AM, Russell Bryant wrote:
> Another area worth calling out is a gate czar. Having someone who
> understands infra and QA quite well and is regularly on top of the
> status of the project in the gate is helpful and quite important.
Oops, you said this one, too. Anyway, +1.
--
On 08/22/2014 08:33 AM, Thierry Carrez wrote:
> Hi everyone,
>
> We all know being a project PTL is an extremely busy job. That's because
> in our structure the PTL is responsible for almost everything in a project:
>
> - Release management contact
> - Work prioritization
> - Keeping bugs under c
Hi everyone,
We all know being a project PTL is an extremely busy job. That's because
in our structure the PTL is responsible for almost everything in a project:
- Release management contact
- Work prioritization
- Keeping bugs under control
- Communicate about work being planned or done
- Make s
56 matches
Mail list logo