Open Stack

On 23/04/15 17:14 +0100, Chris Dent wrote:
>
>This might be a bit presumptuous, but why not give it a try...
>
>This cycle's TC elections didn't come with a set of prepackaged
>questions and though the self-nomination messages have included some
>very interesting stuff I think it would be useful to get answers
>from the candidates on at least one topical but open-ended
>question. Maybe other people have additional questions they think
>are important but this one is the one that matters to me and also
>captures the role that I wish the TC filled more strongly. Here's
>the preamble:
>
>There are lots of different ways to categorize the various
>stakeholders in the OpenStack community, no list is complete. For
>the sake of this question the people I'm concerned with are the
>developers, end-users and operators of OpenStack: the individuals
>who are actively involved with it on a daily basis. I'm intentionally
>leaving out things like "the downstream".
>
>There are many different ways to define "quality". For the sake of
>this question feel free to use whatever definition you like but take
>it as given that "quality" needs to be improved.
>
>Here's the question:
>
>What can and should the TC at large, and you specifically, do to ensure
>quality improves for the developers, end-users and operators of
>OpenStack as a full system, both as a project being developed and a
>product being used?

Thanks for bringing this up, Chris.

First and foremost, sorry for my late answer. I just got back from a
trip w/ limited internet access.

With the latest changes in governance model, I believe we need to be
very observant of the changes happening in our community. As I
mentioned in my candidacy, new projects will start showing up and
they'll want to join the OpenStack organization. While this is
amazing, we need to have a "scalable" - yes, hard to do - way to guide
those projects whenever it's needed.

Therefore, I believe one thing we need to do is improve the
communication between the TC and the commuity. I've heard a couple of
times from members in our that it's sometimes hard to communicate with
the TC and most of the times, it's not clear for them when certain
topics should/shouldn't involve the TC. This, to me, is cause by a
lack of communication between the TC and the community. Either we're
failing to explain what the TC is there for or the communication
channels between the TC and the rest of the community are not good
enough.

Note that I've emphasized "comunication" and not a very specific plan
towards quality. The reason being that I believe that a good
communication between the TC and the rest of the community will help
with defining those guidelines I mentioned before and a good workflow
that would help projects to improve their quality and that would also
help developers to improve their experience in the community.

Staying out of the way of projects sounds exciting but we still need
to be almost-silent observers/actors in project's lifes to make sure the
right people/projects are talking to each other.

I'm a big believer in collaboration and I think that we should strive
for it as much as possible and the TC should be there to help.

This all will improve the quality of our projects in the long run as
we'll be developing experiences that will be available for other
projects to consume.

That was from a TC perspective. Now, from a project perspective, I
believe the TC needs to be vigilant and ensure that projects have all
the tools and resources to be productive and independent. This goes
along with what I said above. New groups have been born that should
help improving different areas - API WG, for example - and these
groups need to communicate with the rest of the community. We sould
encourage folks from different projects to be part of these groups and
contribute.  Pretty much like we encourage folks to be part of Oslo,
or at the very least follow its developments.

Thanks for reading,
Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150427/b2aa5be1/attachment.pgp>