<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Anne Gentle wrote:<br>
> [...]<br>
<span class="">> 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.<br>
<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>
<span class=""><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 class=""><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>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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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>
<br></blockquote><div><br></div><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><br></div><div>Anne</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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 class="HOEnZb"><font color="#888888"><br>
--<br>
Thierry Carrez (ttx)<br>
</font></span><div class="HOEnZb"><div class="h5"><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 class="gmail_signature"><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>
</div></div>