Open Stack

I think it actually relies upon the new team to actively reaching out to
the existing team. The new team cannot be lazy and wait for something
happen for them, they have to keep reaching out and believe me the core
developers from the existing official project will lend a hand in the end :)

For Cyborg, I didn't even rush the application for an official project
status. We've had more than one year just discuss the necessity and
usefulness of the project, because I was not sure as well at the time if we
are overlapping with something Nova or other project is already doing or we
are just dreaming up some use cases.

It turns out by conducting active and long discussions , we've got more
than enough help from the Nova team :) I believe this is the team that is
famous for their busy schedule, but the core developers helped tramendously
because we are the one that is actively reaching out.

SO back to topic, for TC's role, it should be to help the new team to find
a productive way to actively get in contact with any related existing
teams, not to put pressure on the existing projects :)

On Mon, Apr 23, 2018 at 10:39 PM, Doug Hellmann <doug at doughellmann.com>
wrote:

> Excerpts from Zhipeng Huang's message of 2018-04-21 07:06:30 +0800:
> > As the one who just lead a new project into governance last year, I
> think I
> > could take a first stab at it.
> >
> > For me the current requirements in general works fine, as I emphasized in
> > my recent blog [0], the four opens are extremely important. Open Design
> is
> > one of the most important out the four I guess, because it actually will
> > lead to the diversity question. A team with a single vendor, although it
> > could satisfy all the other three easily, could not have a good open
> design
> > rather well.
> >
> > Another criteria (more related to the mission statement specifically) I
> > would consider important is the ability to demonstrate (1)its scope does
> > not overlap with existing official projects and (2) its ability to
> actively
> > work with related projects. The cross project collaboration does not have
> > to be waited after the project got anointed, rather started when the
> > project is in conception.
>
> In the past we have had challenges with existing teams having time,
> energy, or interest in working with new teams. These issues are
> often, but not always, outside of the control of the new teams.
> What role can, or should, the TC play in mediating these situations?
>
> Doug
>
> >
> > Well I guess that is my two cents :)
> >
> > [0] https://hannibalhuang.github.io/
> >
> >
> >
> > On Sat, Apr 21, 2018 at 5:26 AM, Doug Hellmann <doug at doughellmann.com>
> > wrote:
> >
> > > [This is meant to be one of (I hope) several conversation-provoking
> > > questions directed at prospective TC members to help the community
> > > understand their positions before considering how to vote in the
> > > ongoing election.]
> > >
> > > We are discussing adding at least one new project this cycle, and
> > > the specific case of Adjutant has brought up questions about the
> > > criteria we use for evaluating new projects when they apply to
> > > become official.  Although the current system does include some
> > > well-defined requirements [1], it was also designed to rely on TC
> > > members to use their judgement in some other areas, to account for
> > > changing circumstances over the life of the project and to reflect
> > > the position that governance is not something we can automate away.
> > >
> > > Without letting the conversation devolve too much into a discussion
> > > of Adjutant's case, please talk a little about how you would evaluate
> > > a project's application in general.  What sorts of things do you
> > > consider when deciding whether a project "aligns with the OpenStack
> > > Mission," for example?
> > >
> > > Doug
> > >
> > > [1] https://governance.openstack.org/tc/reference/new-projects-
> > > requirements.html
> > >
> > > ____________________________________________________________
> ______________
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
> >
> >
> > --
> > Zhipeng (Howard) Huang
> >
> > Standard Engineer
> > IT Standard & Patent/IT Product Line
> > Huawei Technologies Co,. Ltd
> > Email: huangzhipeng at huawei.com
> > Office: Huawei Industrial Base, Longgang, Shenzhen
> >
> > (Previous)
> > Research Assistant
> > Mobile Ad-Hoc Network Lab, Calit2
> > University of California, Irvine
> > Email: zhipengh at uci.edu
> > Office: Calit2 Building Room 2402
> >
> > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhipeng at huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipengh at uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180423/733dfbe9/attachment.html>