On Wed, Sep 16, 2015 at 11:30 AM, Anne Gentle <annegen...@justwriteclick.com > wrote:
> > > On Wed, Sep 16, 2015 at 9:16 AM, Thierry Carrez <thie...@openstack.org> > 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 to user story mapping is 1:1. > >> > 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 > > -- Thanks, Shamail Tahir t: @ShamailXD tz: Eastern Time
__________________________________________________________________________ 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