Re: [openstack-dev] [all] [ptl] Troubleshooting cross-project communications

[Shamail]

> On Sep 17, 2015, at 7:50 PM, Mike Perez  wrote:
> 
>> On 16:16 Sep 16, Thierry Carrez wrote:
>> Anne Gentle wrote:
>>> [...]
>>> What are some of the problems with each layer? 
>>> 
>>> 1. weekly meeting: time zones, global reach, size of cross-project
>>> concerns due to multiple projects being affected, another meeting for
>>> PTLs to attend and pay attention to
>> 
>> A lot of PTLs (or liaisons/lieutenants) skip the meeting, or will only
>> attend when they have something to ask. Their time is precious and most
>> of the time the meeting is not relevant for them, so why bother ? You
>> have a few usual suspects attending all of them, but those people are
>> cross-project-aware already so those are not the people that would
>> benefit the most from the meeting.
>> 
>> This partial attendance makes the meeting completely useless as a way to
>> disseminate information. It makes the meeting mostly useless as a way to
>> get general approval on cross-project specs.
>> 
>> The meeting still is very useful IMHO to have more direct discussions on
>> hot topics. So a ML discussion is flagged for direct discussion on IRC
>> and we have a time slot already booked for that.
> 
> Content for the cross project meeting are usually:
> 
> * Not ready for decisions.
> * Lack solutions.
> 
> A proposal in steps of how cross project ideas start, to something ready for
> the cross project IRC meeting, then the TC:
> 
> 1) An idea starts from either or both:
>   a) Mailing list discussion.
>   b) A patch to a single project (until it's flagged that this patch could be
>  benefical to other projects)
> 2) OpenStack Spec is proposed - discussions happen in gerrit from here on out.
>   Not on the mailing list. Keep encouraging discussions back to gerrit to keep
>   everything in one place in order to avoid confusion with having to fish
>   for some random discussion elsewhere.
> 3) Once enough consensus happens an agenda item is posted cross project IRC
>   meeting.
> 4) Final discussions happen in the meeting. If consensus is still met by
>   interested parties who attend, it moves to TC.  If there is a lack of
>   consensus it goes back to gerrit and repeat.
> 
This approach makes sense.  It will also allow items that don't reach consensus 
to possibly be captured (once) and rise to the top again when/if it becomes a 
pressing need.  There has to be some process to abandon changes eventually too 
(if the scope changes or the initial ask if no longer relevant).  

> With this process, we should have less meetings. Less meetings is:
> 
> * Awesome
> * Makes this meeting more meaningful when it happens because decisions are
>  potentially going to be agreed and passed to the TC!
> 
> If a cross project spec is not getting attention, don't post it to the list 
> for
> attention. We get enough email and it'll probably be lost. Instead, let the
> product working group recognize this and reach out to the projects that this
> spec would benefit, to bring meaningful attention to the spec.
+1 
If something needs attention, we would be glad to help evaluate/socialize.
> 
> For vertical alignment, interaction like IRC is not necessary. A very brief,
> bullet point of collected information from projects that have anything
> interesting is given in a weekly digest email to the list If anyone has
> questions or wants more information, they can use their own time to ask that
> project team.
> 
> Potentially, if we kept everything to the spec on gerrit, and had the product
> working group bringing needed attention to specs, we could eliminate the cross
> project meeting.
> 
Does it make sense to propose a continuation of this discussion at the summit 
(using the tool that Thierry just linked in another message) or a cross-project 
meeting before the summit?  A few of us from the Product WG will be glad to 
participate.

> -- 
> Mike Perez
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [ptl] Troubleshooting cross-project communications

[John Garbutt]

On 18 September 2015 at 00:50, Mike Perez  wrote:
> On 16:16 Sep 16, Thierry Carrez wrote:
>> Anne Gentle wrote:
>> > [...]
>> > What are some of the problems with each layer?
>> >
>> > 1. weekly meeting: time zones, global reach, size of cross-project
>> > concerns due to multiple projects being affected, another meeting for
>> > PTLs to attend and pay attention to
>>
>> A lot of PTLs (or liaisons/lieutenants) skip the meeting, or will only
>> attend when they have something to ask. Their time is precious and most
>> of the time the meeting is not relevant for them, so why bother ? You
>> have a few usual suspects attending all of them, but those people are
>> cross-project-aware already so those are not the people that would
>> benefit the most from the meeting.
>>
>> This partial attendance makes the meeting completely useless as a way to
>> disseminate information. It makes the meeting mostly useless as a way to
>> get general approval on cross-project specs.
>>
>> The meeting still is very useful IMHO to have more direct discussions on
>> hot topics. So a ML discussion is flagged for direct discussion on IRC
>> and we have a time slot already booked for that.
>
> Content for the cross project meeting are usually:
>
> * Not ready for decisions.
> * Lack solutions.
>
> A proposal in steps of how cross project ideas start, to something ready for
> the cross project IRC meeting, then the TC:
>
> 1) An idea starts from either or both:
>a) Mailing list discussion.
>b) A patch to a single project (until it's flagged that this patch could be
>   benefical to other projects)
> 2) OpenStack Spec is proposed - discussions happen in gerrit from here on out.
>Not on the mailing list. Keep encouraging discussions back to gerrit to 
> keep
>everything in one place in order to avoid confusion with having to fish
>for some random discussion elsewhere.
> 3) Once enough consensus happens an agenda item is posted cross project IRC
>meeting.
> 4) Final discussions happen in the meeting. If consensus is still met by
>interested parties who attend, it moves to TC.  If there is a lack of
>consensus it goes back to gerrit and repeat.

+1

That totally seems worth a try.

Its extra process, but that should help drive the right conversations,
in more efficient way.

Thanks,
johnthetubaguy

> With this process, we should have less meetings. Less meetings is:
>
> * Awesome
> * Makes this meeting more meaningful when it happens because decisions are
>   potentially going to be agreed and passed to the TC!
>
> If a cross project spec is not getting attention, don't post it to the list 
> for
> attention. We get enough email and it'll probably be lost. Instead, let the
> product working group recognize this and reach out to the projects that this
> spec would benefit, to bring meaningful attention to the spec.
>
> For vertical alignment, interaction like IRC is not necessary. A very brief,
> bullet point of collected information from projects that have anything
> interesting is given in a weekly digest email to the list If anyone has
> questions or wants more information, they can use their own time to ask that
> project team.
>
> Potentially, if we kept everything to the spec on gerrit, and had the product
> working group bringing needed attention to specs, we could eliminate the cross
> project meeting.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [ptl] Troubleshooting cross-project communications

[Ben Swartzlander]

On 09/15/2015 10:50 AM, Anne Gentle wrote:

Hi all,

What can we do to make the cross-project meeting more helpful and 
useful for cross-project communications? I started with a proposal to 
move it to a different time, which morphed into an idea to alternate 
times. But, knowing that we need to layer communications I wonder if 
we should troubleshoot cross-project communications further? These are 
the current ways cross-project communications happen:


1. The weekly meeting in IRC
2. The cross-project specs and reviewing those
3. Direct connections between team members
4. Cross-project talks at the Summits

What are some of the problems with each layer?

1. weekly meeting: time zones, global reach, size of cross-project 
concerns due to multiple projects being affected, another meeting for 
PTLs to attend and pay attention to


I would actually love to attend the cross-project IRC meeting but it 
falls in a perfectly bad time for my time zone so I can never make it. 
When daylight savings time end the first week of November I'll start 
attending because it will be 1 hour earlier for me.


2. specs: don't seem to get much attention unless they're brought up 
at weekly meeting, finding owners for the work needing to be done in a 
spec is difficult since each project team has its own priorities
3. direct communications: decisions from these comms are difficult to 
then communicate more widely, it's difficult to get time with busy PTLs
4. Summits: only happens twice a year, decisions made then need to be 
widely communicated


I'm sure there are more details and problems I'm missing -- feel free 
to fill in as needed.


Lastly, what suggestions do you have for solving problems with any of 
these layers?


Thanks,
Anne

--
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [ptl] Troubleshooting cross-project communications

[Mike Perez]

On 16:16 Sep 16, Thierry Carrez wrote:
> Anne Gentle wrote:
> > [...]
> > What are some of the problems with each layer? 
> > 
> > 1. weekly meeting: time zones, global reach, size of cross-project
> > concerns due to multiple projects being affected, another meeting for
> > PTLs to attend and pay attention to
> 
> A lot of PTLs (or liaisons/lieutenants) skip the meeting, or will only
> attend when they have something to ask. Their time is precious and most
> of the time the meeting is not relevant for them, so why bother ? You
> have a few usual suspects attending all of them, but those people are
> cross-project-aware already so those are not the people that would
> benefit the most from the meeting.
> 
> This partial attendance makes the meeting completely useless as a way to
> disseminate information. It makes the meeting mostly useless as a way to
> get general approval on cross-project specs.
> 
> The meeting still is very useful IMHO to have more direct discussions on
> hot topics. So a ML discussion is flagged for direct discussion on IRC
> and we have a time slot already booked for that.

Content for the cross project meeting are usually:

* Not ready for decisions.
* Lack solutions.

A proposal in steps of how cross project ideas start, to something ready for
the cross project IRC meeting, then the TC:

1) An idea starts from either or both:
   a) Mailing list discussion.
   b) A patch to a single project (until it's flagged that this patch could be
  benefical to other projects)
2) OpenStack Spec is proposed - discussions happen in gerrit from here on out.
   Not on the mailing list. Keep encouraging discussions back to gerrit to keep
   everything in one place in order to avoid confusion with having to fish
   for some random discussion elsewhere.
3) Once enough consensus happens an agenda item is posted cross project IRC
   meeting.
4) Final discussions happen in the meeting. If consensus is still met by
   interested parties who attend, it moves to TC.  If there is a lack of
   consensus it goes back to gerrit and repeat.

With this process, we should have less meetings. Less meetings is:

* Awesome
* Makes this meeting more meaningful when it happens because decisions are
  potentially going to be agreed and passed to the TC!

If a cross project spec is not getting attention, don't post it to the list for
attention. We get enough email and it'll probably be lost. Instead, let the
product working group recognize this and reach out to the projects that this
spec would benefit, to bring meaningful attention to the spec.

For vertical alignment, interaction like IRC is not necessary. A very brief,
bullet point of collected information from projects that have anything
interesting is given in a weekly digest email to the list If anyone has
questions or wants more information, they can use their own time to ask that
project team.

Potentially, if we kept everything to the spec on gerrit, and had the product
working group bringing needed attention to specs, we could eliminate the cross
project meeting.

-- 
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [ptl] Troubleshooting cross-project communications

[Mike Perez]

On 10:00 Sep 17, Shamail Tahir wrote:
> On Wed, Sep 16, 2015 at 11:30 AM, Anne Gentle  >
> > On Wed, Sep 16, 2015 at 9:16 AM, Thierry Carrez 
> > wrote:



> >>
> >> Just brainstorming out loud, maybe we need to have a base team of people
> >> committed to drive such initiatives to completion, a team that
> >> individuals could leverage when they have a cross-project idea, a team
> >> that could define a few cycle goals and actively push them during the
> >> cycle.
> >>
> >
> This is very similar to how the Product WG structure is setup as well.  We
> have cross-project liaisons (CPLs) that participate in the project team
> meetings and also user-story owners who cover the overall goal of
> completing the user story.  The user story owner leverages the cross
> project liaisons to help with tracking component/project specific
> dependencies for implementing the user story but the user story owner is
> looking at the overall state of the bigger picture.   Our CPLs work with
> multiple user-story owners but the user story owner to user story mapping
> is 1:1.

+1

Before I got to Shamail's email, I was also thinking this sounds exactly what
the product working group is doing.


-- 
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [ptl] Troubleshooting cross-project communications

[Shamail Tahir]

On Wed, Sep 16, 2015 at 11:30 AM, Anne Gentle  wrote:

>
>
> On Wed, Sep 16, 2015 at 9:16 AM, Thierry Carrez 
> wrote:
>
>> Anne Gentle wrote:
>> > [...]
>> > What are some of the problems with each layer?
>> >
>> > 1. weekly meeting: time zones, global reach, size of cross-project
>> > concerns due to multiple projects being affected, another meeting for
>> > PTLs to attend and pay attention to
>>
>> A lot of PTLs (or liaisons/lieutenants) skip the meeting, or will only
>> attend when they have something to ask. Their time is precious and most
>> of the time the meeting is not relevant for them, so why bother ? You
>> have a few usual suspects attending all of them, but those people are
>> cross-project-aware already so those are not the people that would
>> benefit the most from the meeting
>
>
>> This partial attendance makes the meeting completely useless as a way to
>> disseminate information. It makes the meeting mostly useless as a way to
>> get general approval on cross-project specs.
>>
>> The meeting still is very useful IMHO to have more direct discussions on
>> hot topics. So a ML discussion is flagged for direct discussion on IRC
>> and we have a time slot already booked for that.
>>
> I wanted to add a +1 to the idea of using a tag other than [all] to
highlight cross-project communications.

>
>> > 2. specs: don't seem to get much attention unless they're brought up at
>> > weekly meeting, finding owners for the work needing to be done in a spec
>> > is difficult since each project team has its own priorities
>>
>> Right, it's difficult to get them reviewed, and getting consensus and TC
>> rubberstamp on them is also a bit of a thankless job. Basically you're
>> trying to make sure everyone is OK with what you propose and most people
>> ignore you (and then would be unhappy when they are impacted by the
>> implementation a month later). I don't think that system works well and
>> I'd prefer we change it.
>>
>> > 3. direct communications: decisions from these comms are difficult to
>> > then communicate more widely, it's difficult to get time with busy PTLs
>> > 4. Summits: only happens twice a year, decisions made then need to be
>> > widely communicated
>> >
>> > I'm sure there are more details and problems I'm missing -- feel free to
>> > fill in as needed.
>> >
>> > Lastly, what suggestions do you have for solving problems with any of
>> > these layers?
>>
>> I'm starting to think we need to overhaul the whole concept of
>> cross-project initiatives. The current system where an individual drives
>> a specific spec and goes through all the hoops to expose it to the rest
>> of the community is not really working. The current model doesn't
>> support big overall development cycle goals either, since there is no
>> team to implement those.
>>
>
> Completely agree, this is my observation as well from the service catalog
> improvement work. While the keystone team is crucial, so many other teams
> are affected. And I don't have all the key skills to implement the vision,
> nor do I want to be a spec writer who can't implement, ya know? It's a
> tough one.
>

Hi, would it make sense for the product WG to help write and/or track the
specs?  Apologies, in advance, if our workflow does not fit the needs being
discussed.

We have a defined workflow for how we will be working on user stories
through our process[1] and I wonder if a similar workflow could be built
for cross-project specs.  We are already trying to focus on
multi-release/cross-project user stories[2] but we are doing it from a
market perspective as opposed to tracking items that are cross-project
needs based on the current state.  The process could definitely be expanded
to help coordinate these needs as well.   This will allow an individual to
still be associated with a spec but if the person is unable to finish the
work or needs more help, the team could ask for more resources or let
stakeholders know that there might be a delay.

[1]
https://docs.google.com/presentation/d/1dZBm4cfpSyVlvPLpHSReaQiZ7e8SfgS7VLSbSqoWokw/edit?usp=sharing
[2] https://wiki.openstack.org/wiki/ProductTeam#Objectives

>
>
>>
>> Just brainstorming out loud, maybe we need to have a base team of people
>> committed to drive such initiatives to completion, a team that
>> individuals could leverage when they have a cross-project idea, a team
>> that could define a few cycle goals and actively push them during the
>> cycle.
>>
>
This is very similar to how the Product WG structure is setup as well.  We
have cross-project liaisons (CPLs) that participate in the project team
meetings and also user-story owners who cover the overall goal of
completing the user story.  The user story owner leverages the cross
project liaisons to help with tracking component/project specific
dependencies for implementing the user story but the user story owner is
looking at the overall state of the bigger picture.   Our CPLs work with
multiple user-story owners but the user story owner t

Re: [openstack-dev] [all] [ptl] Troubleshooting cross-project communications

[Anne Gentle]

On Wed, Sep 16, 2015 at 9:16 AM, Thierry Carrez 
wrote:

> Anne Gentle wrote:
> > [...]
> > What are some of the problems with each layer?
> >
> > 1. weekly meeting: time zones, global reach, size of cross-project
> > concerns due to multiple projects being affected, another meeting for
> > PTLs to attend and pay attention to
>
> A lot of PTLs (or liaisons/lieutenants) skip the meeting, or will only
> attend when they have something to ask. Their time is precious and most
> of the time the meeting is not relevant for them, so why bother ? You
> have a few usual suspects attending all of them, but those people are
> cross-project-aware already so those are not the people that would
> benefit the most from the meeting.
>
> This partial attendance makes the meeting completely useless as a way to
> disseminate information. It makes the meeting mostly useless as a way to
> get general approval on cross-project specs.
>
> The meeting still is very useful IMHO to have more direct discussions on
> hot topics. So a ML discussion is flagged for direct discussion on IRC
> and we have a time slot already booked for that.
>
> > 2. specs: don't seem to get much attention unless they're brought up at
> > weekly meeting, finding owners for the work needing to be done in a spec
> > is difficult since each project team has its own priorities
>
> Right, it's difficult to get them reviewed, and getting consensus and TC
> rubberstamp on them is also a bit of a thankless job. Basically you're
> trying to make sure everyone is OK with what you propose and most people
> ignore you (and then would be unhappy when they are impacted by the
> implementation a month later). I don't think that system works well and
> I'd prefer we change it.
>
> > 3. direct communications: decisions from these comms are difficult to
> > then communicate more widely, it's difficult to get time with busy PTLs
> > 4. Summits: only happens twice a year, decisions made then need to be
> > widely communicated
> >
> > I'm sure there are more details and problems I'm missing -- feel free to
> > fill in as needed.
> >
> > Lastly, what suggestions do you have for solving problems with any of
> > these layers?
>
> I'm starting to think we need to overhaul the whole concept of
> cross-project initiatives. The current system where an individual drives
> a specific spec and goes through all the hoops to expose it to the rest
> of the community is not really working. The current model doesn't
> support big overall development cycle goals either, since there is no
> team to implement those.
>

Completely agree, this is my observation as well from the service catalog
improvement work. While the keystone team is crucial, so many other teams
are affected. And I don't have all the key skills to implement the vision,
nor do I want to be a spec writer who can't implement, ya know? It's a
tough one.


>
> Just brainstorming out loud, maybe we need to have a base team of people
> committed to drive such initiatives to completion, a team that
> individuals could leverage when they have a cross-project idea, a team
> that could define a few cycle goals and actively push them during the
> cycle.
>
>
Or, to dig into this further, continue along the lines of the TC specialty
teams we've set up? We ran out of time a few TC meetings ago to dive into
solutions here, so I'm glad we can continue the conversation.

I'm sure existing cross-project teams have ideas too, liaisons and the like
may be matrixed somehow? We'll still need accountability and matching skill
sets for tasks.

Anne


> Maybe cross-project initiatives are too important to be left to the
> energy of an individual and rely on random weekly meetings to make
> progress. They might need a clear team to own them.
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [ptl] Troubleshooting cross-project communications

[Anne Gentle]

On Tue, Sep 15, 2015 at 11:32 AM, Christopher Aedo  wrote:

> On Tue, Sep 15, 2015 at 7:50 AM, Anne Gentle
>  wrote:
> > Hi all,
> >
> > What can we do to make the cross-project meeting more helpful and useful
> for
> > cross-project communications? I started with a proposal to move it to a
> > different time, which morphed into an idea to alternate times. But,
> knowing
> > that we need to layer communications I wonder if we should troubleshoot
> > cross-project communications further? These are the current ways
> > cross-project communications happen:
> >
> > 1. The weekly meeting in IRC
> > 2. The cross-project specs and reviewing those
> > 3. Direct connections between team members
> > 4. Cross-project talks at the Summits
>
> 5. This mailing list
>
> >
> > What are some of the problems with each layer?
> >
> > 1. weekly meeting: time zones, global reach, size of cross-project
> concerns
> > due to multiple projects being affected, another meeting for PTLs to
> attend
> > and pay attention to
> > 2. specs: don't seem to get much attention unless they're brought up at
> > weekly meeting, finding owners for the work needing to be done in a spec
> is
> > difficult since each project team has its own priorities
> > 3. direct communications: decisions from these comms are difficult to
> then
> > communicate more widely, it's difficult to get time with busy PTLs
> > 4. Summits: only happens twice a year, decisions made then need to be
> widely
> > communicated
>
> 5. There's tremendous volume on the mailing list, and it can be very
> difficult to stay on top of all that traffic.
>
> >
> > I'm sure there are more details and problems I'm missing -- feel free to
> > fill in as needed.
> >
> > Lastly, what suggestions do you have for solving problems with any of
> these
> > layers?
>
> Unless I missed it, I'm really not sure why the mailing list didn't
> make the list here?  My take at least is that we should be
> coordinating with each other through the mailing list when real-time
> isn't possible (due time zone issues, etc.)  At the very least, it
> keeps people from holding on to information or issues until the next
> weekly meeting, or for a few months until the next mid-cycle or
> summit.
>
>
My apologies, that's called "blindness to the current medium" or some such.
:) Yes, absolutely we use this mailing list a lot for communication.


> I personally would like to see more coordination happening on the ML,
> and would be curious to hear opinions on how that can be improved.
> Maybe a tag on the subject line to draw attention in this case makes
> this a little easier, since we are by nature talking about issues that
> span all projects?  [cross-project] rather than [all]?
>
>
 I agree, another topic sounds like a good starting point.

Thanks,
Anne


> -Christopher
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [ptl] Troubleshooting cross-project communications

[Thierry Carrez]

Anne Gentle wrote:
> [...]
> What are some of the problems with each layer? 
> 
> 1. weekly meeting: time zones, global reach, size of cross-project
> concerns due to multiple projects being affected, another meeting for
> PTLs to attend and pay attention to

A lot of PTLs (or liaisons/lieutenants) skip the meeting, or will only
attend when they have something to ask. Their time is precious and most
of the time the meeting is not relevant for them, so why bother ? You
have a few usual suspects attending all of them, but those people are
cross-project-aware already so those are not the people that would
benefit the most from the meeting.

This partial attendance makes the meeting completely useless as a way to
disseminate information. It makes the meeting mostly useless as a way to
get general approval on cross-project specs.

The meeting still is very useful IMHO to have more direct discussions on
hot topics. So a ML discussion is flagged for direct discussion on IRC
and we have a time slot already booked for that.

> 2. specs: don't seem to get much attention unless they're brought up at
> weekly meeting, finding owners for the work needing to be done in a spec
> is difficult since each project team has its own priorities

Right, it's difficult to get them reviewed, and getting consensus and TC
rubberstamp on them is also a bit of a thankless job. Basically you're
trying to make sure everyone is OK with what you propose and most people
ignore you (and then would be unhappy when they are impacted by the
implementation a month later). I don't think that system works well and
I'd prefer we change it.

> 3. direct communications: decisions from these comms are difficult to
> then communicate more widely, it's difficult to get time with busy PTLs
> 4. Summits: only happens twice a year, decisions made then need to be
> widely communicated
> 
> I'm sure there are more details and problems I'm missing -- feel free to
> fill in as needed. 
> 
> Lastly, what suggestions do you have for solving problems with any of
> these layers? 

I'm starting to think we need to overhaul the whole concept of
cross-project initiatives. The current system where an individual drives
a specific spec and goes through all the hoops to expose it to the rest
of the community is not really working. The current model doesn't
support big overall development cycle goals either, since there is no
team to implement those.

Just brainstorming out loud, maybe we need to have a base team of people
committed to drive such initiatives to completion, a team that
individuals could leverage when they have a cross-project idea, a team
that could define a few cycle goals and actively push them during the cycle.

Maybe cross-project initiatives are too important to be left to the
energy of an individual and rely on random weekly meetings to make
progress. They might need a clear team to own them.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [ptl] Troubleshooting cross-project communications

[Christopher Aedo]

On Tue, Sep 15, 2015 at 7:50 AM, Anne Gentle
 wrote:
> Hi all,
>
> What can we do to make the cross-project meeting more helpful and useful for
> cross-project communications? I started with a proposal to move it to a
> different time, which morphed into an idea to alternate times. But, knowing
> that we need to layer communications I wonder if we should troubleshoot
> cross-project communications further? These are the current ways
> cross-project communications happen:
>
> 1. The weekly meeting in IRC
> 2. The cross-project specs and reviewing those
> 3. Direct connections between team members
> 4. Cross-project talks at the Summits

5. This mailing list

>
> What are some of the problems with each layer?
>
> 1. weekly meeting: time zones, global reach, size of cross-project concerns
> due to multiple projects being affected, another meeting for PTLs to attend
> and pay attention to
> 2. specs: don't seem to get much attention unless they're brought up at
> weekly meeting, finding owners for the work needing to be done in a spec is
> difficult since each project team has its own priorities
> 3. direct communications: decisions from these comms are difficult to then
> communicate more widely, it's difficult to get time with busy PTLs
> 4. Summits: only happens twice a year, decisions made then need to be widely
> communicated

5. There's tremendous volume on the mailing list, and it can be very
difficult to stay on top of all that traffic.

>
> I'm sure there are more details and problems I'm missing -- feel free to
> fill in as needed.
>
> Lastly, what suggestions do you have for solving problems with any of these
> layers?

Unless I missed it, I'm really not sure why the mailing list didn't
make the list here?  My take at least is that we should be
coordinating with each other through the mailing list when real-time
isn't possible (due time zone issues, etc.)  At the very least, it
keeps people from holding on to information or issues until the next
weekly meeting, or for a few months until the next mid-cycle or
summit.

I personally would like to see more coordination happening on the ML,
and would be curious to hear opinions on how that can be improved.
Maybe a tag on the subject line to draw attention in this case makes
this a little easier, since we are by nature talking about issues that
span all projects?  [cross-project] rather than [all]?

-Christopher

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [ptl] Troubleshooting cross-project communications

[Anita Kuno]

On 09/15/2015 08:50 AM, Anne Gentle wrote:
> Hi all,
> 
> What can we do to make the cross-project meeting more helpful and useful
> for cross-project communications? I started with a proposal to move it to a
> different time, which morphed into an idea to alternate times. But, knowing
> that we need to layer communications I wonder if we should troubleshoot
> cross-project communications further? These are the current ways
> cross-project communications happen:
> 
> 1. The weekly meeting in IRC
> 2. The cross-project specs and reviewing those
> 3. Direct connections between team members
> 4. Cross-project talks at the Summits
> 
> What are some of the problems with each layer?
> 
> 1. weekly meeting: time zones, global reach, size of cross-project concerns
> due to multiple projects being affected, another meeting for PTLs to attend
> and pay attention to
> 2. specs: don't seem to get much attention unless they're brought up at
> weekly meeting, finding owners for the work needing to be done in a spec is
> difficult since each project team has its own priorities
> 3. direct communications: decisions from these comms are difficult to then
> communicate more widely, it's difficult to get time with busy PTLs
> 4. Summits: only happens twice a year, decisions made then need to be
> widely communicated
> 
> I'm sure there are more details and problems I'm missing -- feel free to
> fill in as needed.
> 
> Lastly, what suggestions do you have for solving problems with any of these
> layers?
> 
> Thanks,
> Anne
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

Hi Anne,

Thanks for starting the conversation as I think it is an area we can
really benefit from improving.

For my part, I have been trying to attend multiple mid-cycles in order
to do what I can to alleviate the effect of decisions made by one group
either duplicating work with another or directly contravening it.

It is one small part of the over communication issue which affects us
all but I do believe it has some benefit to those with whom I am able to
interact. One of the things I look for is ways for folks who need to be
discussing something specific, since they are both involved in the same
problem area, to become aware of the efforts of the other and to
encourage direct communication between those involved.

I know due to financial and personal effects this strategy doesn't
scale, but I did want to bring awareness to my efforts in your status
report.

Thanks for initiating the discussion, Anne,
Anita.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] [ptl] Troubleshooting cross-project communications

[Anne Gentle]

Hi all,

What can we do to make the cross-project meeting more helpful and useful
for cross-project communications? I started with a proposal to move it to a
different time, which morphed into an idea to alternate times. But, knowing
that we need to layer communications I wonder if we should troubleshoot
cross-project communications further? These are the current ways
cross-project communications happen:

1. The weekly meeting in IRC
2. The cross-project specs and reviewing those
3. Direct connections between team members
4. Cross-project talks at the Summits

What are some of the problems with each layer?

1. weekly meeting: time zones, global reach, size of cross-project concerns
due to multiple projects being affected, another meeting for PTLs to attend
and pay attention to
2. specs: don't seem to get much attention unless they're brought up at
weekly meeting, finding owners for the work needing to be done in a spec is
difficult since each project team has its own priorities
3. direct communications: decisions from these comms are difficult to then
communicate more widely, it's difficult to get time with busy PTLs
4. Summits: only happens twice a year, decisions made then need to be
widely communicated

I'm sure there are more details and problems I'm missing -- feel free to
fill in as needed.

Lastly, what suggestions do you have for solving problems with any of these
layers?

Thanks,
Anne

-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev