Open Stack

Thanks for bring this to the list, Flavio.

A few thoughts in line ...

> Greetings,
> 
> As probably many of you already know, Zaqar (formerly known as Marconi)
> has recently been evaluated for integration. This is the second time
> this project (and team) has gone through this process and just like last
> time, it wasn't as smooth as we all would have liked it to be.
> 
> I thought about sending this email - regardless of what result is - to
> give a summary of what the experience have been like from the project
> side. Some things were quite frustrating and I think they could be
> revisited and improved, hence this email and ideas as to how I think we
> could make them better.
> 
> ## Misunderstanding of the project goals:
> 
> For both graduation attempts, the goals of the project were not
> clear. It felt like the communication between TC and PTL was
> insufficient to convey enough data to make an informed decision.
> 
> I think we need to work on a better plan to follow-up with incubated
> projects. I think these projects should have a schedule and specific
> incubated milestones in addition to the integrated release milestones.
> For example, it'd be good to have at least 3 TC meetings were the
> project shows the progress, the goals that have been achieved and where
> it is standing on the integration requirements.
> 
> These meetings should be used to address concerns right away. Based on
> Zaqar's experience, it's clear that graduating is more than just meeting
> the requirements listed here[0]. The requirements may change and other
> project-specific concerns may also be raised. The important thing here,
> though, is to be all on the same page of what's needed.
> 
> I suggested after the Juno summit that we should have TC representative
> for each incubated project[1]. I still think that's a good idea and we
> should probably evaluate a way to make that, or something like that,
> happen. We tried to put it in practice during Juno - Devananda
> volunteered to be Zaqar's representative. Thanks for doing this - but it
> didn't work out as we expected. It would probably be a better idea,
> given the fact that we're all overloaded with things to do, to have a
> sub-team of 2 or 3 TC members assigned to a project. These TC
> representatives could lead incubated projects through the process and
> work as a bridge between the TC and the project.
> 
> Would a plan like the one mentioned above scale for the current TC and
> the number of incubated projects?

Agreed that the expectations on the TC representative should be made
clearer. It would be best IMO if this individual (or small sub-team)
could commit to doing a deep-dive on the project and be ready to act
as a mediator with the rest of the TC around the project's intended
use-cases, architecture, APIs etc.

There need not necessarily be an expectation that the representative(s)
would champion the project, but they should ensure that there aren't
"what the heck is this thing?" style questions still being asked right
at the end of the incubation cycle. 

> [0]
> https://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements.rst#n79
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2014-May/035341.html
> 
> ## Have a better structured meeting
> 
> One of the hard things of attending a TC meeting as a representative for
> a project is that you get 13 people asking several different questions
> at the same time, which is impossible to keep up with. I think, for
> future integration/incubation/whatever reviews/meetings, there should be
> a better structure. One of the things I'd recommend is to move all the
> *long* technical discussions to the mailing list and avoid having them
> during the graduation meeting. IRC discussions are great but I'd
> probably advice having them in the project channel or during the project
> meeting time and definitely before the graduation meeting.
> 
> What makes this `all-against-one` thing harder are the parallel
> discussions that normally happen during these meetings. We should really
> work hard on avoiding these kind of parallel discussions because they
> distract attendees and make the really discussion harder and frustrating.

As an observer from afar at those TC meetings, the tone of *some* of
the discussion seemed a bit adversarial, or at least very challenging
to respond to in a coherent way. I wouldn't relish the job of trying 
to field rapid-fire, overlapping questions in real-time, some of which
cast doubts on very fundamental aspects of the project. While I agree
every TC member's questions are important, that approach isn't the most
effective way of ensuring good answers are forthcoming.

+1 that this could be improved by ensuring that most of the detailed
technical discussion has already been aired well in advance on the ML.

In addition, I wonder might there be some mileage in approaches such
as:

 * encouraging the TC to register fundamental concerns/doubts in
   advance via an etherpad so that the project team gets a chance
   to discuss and craft a considered response before the meeting

 * structuring the discussion to ensure there is less interleaving,
   e.g. by passing a virtual conch between TC members so that
   concerns can be dealt with serially by the project team

Cheers,
Eoghan


> I don't have a good solution for this because everyone's questions are
> important. I wonder if there's a good way to voice folks during the
> meeting. Also, would it be useful to work out a list of *must discuss*
> questions before the meeting?
> 
> I think the graduation review meeting should be just about that, doing a
> final review. Getting to the graduation meeting with open questions
> means the project wasn't followed closely enough throughout the
> incubation period. Regardless of this, I still think project's sync
> meetings with the TC would be more fruitful if we had a better structure
> that would allow everyone to clear out existing doubts.
> 
> ## Keep feedback constructive
> 
> This point here is more a heads up for the whole community and not
> specific to the graduation process.
> 
> We all agree that the more constructive we are, the easier it'll be to
> find the right solution. The more constructive we are, the less painful
> the process will be and most importantly the less burned we'll all be at
> the end of the journey.
> 
> We are all humans and we get caught up in discussions and it's even
> harder when we're defending our own opinions. This sometimes leads us to
> nonconstructive communication, which leads to frustration and no
> solution at all.
> 
> There were a couple of things that I think affected the communication
> during this process, especially during the meetings so I wrote a list of
> what I think are good things to keep in mind while having these kind of
> discussions:
> 
> - Prefer questions that have specific answers or lead to a better
> solution. Asking questions without correct answers - questions that
> regardless what the given answer is, it won't be good - affects the
> communication. Furthermore, that kind of questions are not really
> helpful and waste everybody's time.
> 
> - Communicate disagreements/errors avoiding accusations. Assuming good
> faith and understanding that we all make mistakes helps a lot with this
> specific point.
> 
> - Propose (possible) solutions when concerns/problems are raised.
> 
> - Disagreement != enemy. I'm friends of *many* folks that disagree with
> me and that's probably what makes the friendship even more fun.
> 
> What I'm trying to get at is that discussions, disagreement and opinions
> are good if we know how to keep them constructive an if we actually get
> something out of it.
> 
> 
> 
> # Things we've learned:
> 
> As a project/team we've made some mistakes and we've definitely learned
> a lot. Here's a list of things we did and worked out good and some that
> I believe we, as project/team, could've done better:
> 
> ## Communicate project's mission/goals properly
> 
> This was probably one of the things that caused the project more
> trouble. We failed at presenting the project's goals at the very
> beginning and once we updated the mission/goals, although it was
> communicated, we didn't make sure it was clear for everyone.
> 
> Projects aiming to be integrated should *always* communicate
> periodically with members of the TC and the overall community. I'd
> advice everyone aiming to gather the community's attention to request
> periodical meetings with the TC (at least 1 every 2 months) or, if
> that's not possible, communicate with the TC members individually.
> 
> It's also a good idea to send an email, periodically, sharing the
> project status and to keep technical discussions in the mailing list.
> 
> In other words, make some noise.
> 
> ## If you want to graduate from incubation, you gotta integrate with the
> OpenStack ecosystem.
> 
> We got to the first graduation review (back in January, I think) with a
> barely working gate job, which didn't test the storage driver we
> recommended for production. This among other areas that lacked of proper
> interaction with the rest of our community, was a sign of immaturity.
> Some areas that we should have taken more care of before our first
> graduation attempt are:
> 
> * Integration with the OpenStack ecosystem
> * Support for drivers that would've been good for most deployments
> * Better communication of the project status.
> 
> The sooner the project integrates with all the OpenStack ecosystem, the
> better. It'll give the project enough time to test things, adopt
> libraries and it'll give the community enough time to adopt the project
> and rely on it. In addition to that, you also get to use/rely on our
> great Zuul.
> 
> ## Have liaisons for everything
> 
> At some point, we realized that we weren't scaling enough as a team to
> work on all the points we had to work on and we decided to split our
> tasks in a way to would make each one of the team members responsible
> for a specific area (pretty much as proposed in the czar thread[0]).
> 
> Subdividing tasks as we did helped with getting all these things done.
> We had better cross-project communication, we're all focused on 1 thing
> and we're also updated in a weekly basis. Here's a list of things we had
> (and still have) liaisons for:
> 
> - QA/infra
> - Docs
> - Oslo
> - client library
> - We all do bug triage
> - ... hopefully I'm not forgetting anything
> 
> As mentioned in other sections, QA/Infra is a time consuming task. The
> sooner that step is made the better. It's definitely not a one-time
> thing, gates need to be monitored and kept stable.
> 
> I'd also recommend taking care of Docs sooner rather than later ;)
> 
> As far as the client library goes, we have this rule that works out most
> of the time. The rule is that whoever is working on a feature that is
> exposed through the API must also work on a patch for the client
> library. This adds more review work and slows down the feature but it
> helps keeping the client updated. If a feature is not supported by the
> client library, it basically doesn't exist.
> 
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2014-August/043812.html
> 
> # Conclusion
> 
> My conclusion and perhaps final proposal on this email is that the
> incubation period of each project should be accompanied by a well
> defined plan that would help the team and the TC understand where the
> project is standing. In addition to this, we need to make sure incubated
> projects are followed by TC members that can help the project stay on
> track and that will also help the team to overcome issues as they come.
> Last but not least, I think project's progress and mission should be
> revisited constantly to make sure they are both going towards the agreed
> goal during the incubation meeting.
> 
> Ok, I think the email is long enough. I'd love to discuss the points
> aforementioned further and work on a way to make this process smoother
> and easier for everyone.
> 
> Cheers,
> Flavio
> 
> --
> @flaper87
> Flavio Percoco
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>