Open Stack

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?

[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.

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