<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 16, 2015 at 11:30 AM, Anne Gentle <span dir="ltr"><<a href="mailto:annegentle@justwriteclick.com" target="_blank">annegentle@justwriteclick.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Wed, Sep 16, 2015 at 9:16 AM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Anne Gentle wrote:<br>
> [...]<br>
<span>> What are some of the problems with each layer?<br>
><br>
> 1. weekly meeting: time zones, global reach, size of cross-project<br>
> concerns due to multiple projects being affected, another meeting for<br>
> PTLs to attend and pay attention to<br>
<br>
</span>A lot of PTLs (or liaisons/lieutenants) skip the meeting, or will only<br>
attend when they have something to ask. Their time is precious and most<br>
of the time the meeting is not relevant for them, so why bother ? You<br>
have a few usual suspects attending all of them, but those people are<br>
cross-project-aware already so those are not the people that would<br>
benefit the most from the meeting<span style="color:rgb(34,34,34)"> </span></blockquote></div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
This partial attendance makes the meeting completely useless as a way to<br>
disseminate information. It makes the meeting mostly useless as a way to<br>
get general approval on cross-project specs.<br>
<br>
The meeting still is very useful IMHO to have more direct discussions on<br>
hot topics. So a ML discussion is flagged for direct discussion on IRC<br>
and we have a time slot already booked for that.<br></blockquote></div></div></div></div></div></blockquote><div>I wanted to add a +1 to the idea of using a tag other than [all] to highlight cross-project communications. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><br>
> 2. specs: don't seem to get much attention unless they're brought up at<br>
> weekly meeting, finding owners for the work needing to be done in a spec<br>
> is difficult since each project team has its own priorities<br>
<br>
</span>Right, it's difficult to get them reviewed, and getting consensus and TC<br>
rubberstamp on them is also a bit of a thankless job. Basically you're<br>
trying to make sure everyone is OK with what you propose and most people<br>
ignore you (and then would be unhappy when they are impacted by the<br>
implementation a month later). I don't think that system works well and<br>
I'd prefer we change it.<br>
<span><br>
> 3. direct communications: decisions from these comms are difficult to<br>
> then communicate more widely, it's difficult to get time with busy PTLs<br>
> 4. Summits: only happens twice a year, decisions made then need to be<br>
> widely communicated<br>
><br>
> I'm sure there are more details and problems I'm missing -- feel free to<br>
> fill in as needed.<br>
><br>
> Lastly, what suggestions do you have for solving problems with any of<br>
> these layers?<br>
<br>
</span>I'm starting to think we need to overhaul the whole concept of<br>
cross-project initiatives. The current system where an individual drives<br>
a specific spec and goes through all the hoops to expose it to the rest<br>
of the community is not really working. The current model doesn't<br>
support big overall development cycle goals either, since there is no<br>
team to implement those.<br></blockquote><div><br></div></div></div><div>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.</div></div></div></div></blockquote><div><br></div><div>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. </div><div><br></div><div>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.  </div><div><br></div><div>[1] <a href="https://docs.google.com/presentation/d/1dZBm4cfpSyVlvPLpHSReaQiZ7e8SfgS7VLSbSqoWokw/edit?usp=sharing">https://docs.google.com/presentation/d/1dZBm4cfpSyVlvPLpHSReaQiZ7e8SfgS7VLSbSqoWokw/edit?usp=sharing</a><br></div><div>[2] <a href="https://wiki.openstack.org/wiki/ProductTeam#Objectives">https://wiki.openstack.org/wiki/ProductTeam#Objectives</a></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Just brainstorming out loud, maybe we need to have a base team of people<br>
committed to drive such initiatives to completion, a team that<br>
individuals could leverage when they have a cross-project idea, a team<br>
that could define a few cycle goals and actively push them during the cycle.<br></blockquote></span></div></div></div></blockquote><div><br></div><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br></blockquote><div><br></div></span><div>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.</div><div><br></div><div>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. </div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><font color="#888888"><div><br></div><div>Anne</div></font></span><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Maybe cross-project initiatives are too important to be left to the<br>
energy of an individual and rely on random weekly meetings to make<br>
progress. They might need a clear team to own them.<br>
<span><font color="#888888"><br>
--<br>
Thierry Carrez (ttx)<br>
</font></span><div><div><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></span></div><br><br clear="all"><span class=""><div><br></div>-- <br><div><div dir="ltr"><div>Anne Gentle</div><div>Rackspace</div><div>Principal Engineer</div><div><a href="http://www.justwriteclick.com" target="_blank">www.justwriteclick.com</a></div></div></div>
</span></div></div>
<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></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="font-size:small">Thanks,</div><div style="font-size:small">Shamail Tahir</div><div style="font-size:small">t: @ShamailXD</div><div style="font-size:small">tz: Eastern Time</div></div></div></div></div>
</div></div>