settingsLogin | Registersettings

[openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

0 votes

The OpenStack community wants to encourage collaboration by emphasizing
contributions to projects that abstract differences between
vendor-specific products, while still empowering vendors to integrate
their products with OpenStack through drivers that can be consumed
by the abstraction layers.

Some teams for projects that use drivers may not want to manage
some or all of the drivers that can be consumed by their project
because they have little insight into testing or debugging the code,
or do not have the resources needed to manage centrally a large
number of separate drivers. Vendors are of course free to produce
drivers to integrate with OpenStack completely outside of the
community, but because we value having the drivers as well as the
more general support of vendor companies, we want to encourage a
higher level of engagement by welcoming vendor-specific teams to
be a part of our community governance.

Our Requirements for New Projects list [0] includes a statement
about establishing a "level and open collaboration playing field"

The project shall provide a level and open collaboration playing
field for all contributors. The project shall not benefit a single
vendor, or a single vendors product offerings; nor advantage
contributors from a single vendor organization due to access to
source code, hardware, resources or other proprietary technology
available only to those contributors.

This requirement makes it difficult to support having teams focused
on producing a deliverable that primarily benefits a single vendor.
So, we have some tension between wanting to collaborate and have a
level playing field, while wanting to control the amount of driver
code that projects have to manage.

I'm raising this as an issue because it's not just a hypothetical
problem. The Cisco networking driver team, having been removed from
the Neutron stadium, is asking for status as a separate official
team [1]. I would very much like to find a way to say "yes, welcome
(back)!"

To that end, I've been working with fungi and ttx to identify all
of our options. We've come up with a "spectrum", which I will try
to summarize here but please read the associated governance patches
for the full details. (Please note that although we've split up the
work of writing the patches, each author may not necessarily support
all of the patches he has submitted.)

  1. A resolution reaffirming the "level playing field" requirement,
    and acknowledging that it effectively precludes official status
    for teams which only develop drivers for proprietary systems
    (hard black) [2]

    This would have the immediate effect of denying the Cisco team's
    request, as well as precluding future requests from similar teams.

  2. A resolution reaffirming the "level playing field" requirement,
    and acknowledging that it does not necessarily preclude official
    status for teams which only develop drivers for proprietary
    systems (soft black) [3]

    This would allow driver-specific teams for systems as long as
    those drivers can be developed without access to proprietary
    information. The TC would have to consider how this applies to
    each team's request as it is evaluated.

  3. A resolution and policy change removing the "level playing field"
    requirement (hard white) [4]

    This would completely remove the problematic wording from the
    governance documents (eliminate the restriction on benefiting a
    single company and consider access to specific information for
    some contributors to not be a problem).

  4. A resolution and policy change loosening the "level playing field"
    requirement (soft white) [5]

    This would add an exception to the existing wording in the
    governance documents to exempt teams working only on drivers.
    They would still be subject to all of our other policies, unless
    similar exceptions are included.

  5. Consider driver teams to be a completely different animal, defined
    in drivers.yaml instead of projects.yaml (grey option) [6]

    This establishes drivers as second-order objects that are necessary
    for the success of the main projects, and for which requirements
    can be loosened. It would establish a new category of team without
    the level playing-field requirement and some of the other team
    requirements that seem not to apply to driver teams because they
    are essentially a public facet of a single vendor.

  6. A resolution requiring projects that consume drivers to host all
    proposed drivers. (red option) [7]

    This would require teams with projects providing driver interfaces
    to also host, in some form, drivers from vendors that ask for
    hosting. The drivers would not need to be in the main project
    repo, but would need to be in a repository "owned" by the project
    team. Project teams would not be considered responsible for the
    quality of the resulting drivers. Contributors to the driver
    repos would be considered part of the electorate for team PTL.

  7. A resolution proposing to allow driver-teams, without specifying
    any implementation details. [8]

    This may go along with option 2, 3, 4, or 5. It may also be used
    as the basis for an alternative proposal if we have missed an
    approach.

We also need to consider while making the situation better that we
not have a huge proliferation of these new teams. For example, some
resources given to teams are finite (CI resources, space at PTGs
and Summits, foundation staff support, cross-project team support).
We also don't want to encourage driver authors to move their code
out of projects that are willing to host them just because they
can. Therefore, it is likely that even if we do allow driver teams
in some form (options 2, 3, 4, and 5), they will have fewer rights
than teams building abstraction layers that use the drivers.

Again, these options are presented to give a more complete picture
and not because we necessarily support all of them (obviously, some
of them are clearly in conflict). I'll post my personal opinions
in a follow up message to avoid editorializing here.

Doug

[0] http://governance.openstack.org/reference/new-projects-requirements.html - requirements for new projects
[1] https://review.openstack.org/363709 - Add networking-cisco back into the Big Tent
[2] https://review.openstack.org/403834 - Proprietary driver dev is unlevel
[3] https://review.openstack.org/403836 - Driver development can be level
[4] https://review.openstack.org/403838 - Stop requiring a level playing field
[5] https://review.openstack.org/403839 - Level playing fields, except drivers
[6] https://review.openstack.org/403829 - establish a new "driver team" concept
[7] https://review.openstack.org/403830 - add resolution requiring teams to accept driver contributions
[8] https://review.openstack.org/403826 - add a resolution allowing teams based on vendor-specific drivers


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Nov 28, 2016 in openstack-dev by Doug_Hellmann (87,520 points)   3 4 12
retagged Jan 26, 2017 by admin

36 Responses

0 votes

On 11/28/2016 01:33 PM, Doug Hellmann wrote:
I'm raising this as an issue because it's not just a hypothetical
problem. The Cisco networking driver team, having been removed from
the Neutron stadium, is asking for status as a separate official
team [1]. I would very much like to find a way to say "yes, welcome
(back)!"

These questions are to the Cisco networking team.

What value do you think you derive from being an official OpenStack
project team?

What value do you believe OpenStack users would get from you being an
official OpenStack project team?

If you are not accepted as an official OpenStack project team, what
actual impact would that have on OpenStack users, if any?

Thanks in advance for your answers.

Best,
-jay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 28, 2016 by Jay_Pipes (59,760 points)   3 11 14
0 votes

Doug Hellmann wrote:
[...]
5. Consider driver teams to be a completely different animal, defined
in drivers.yaml instead of projects.yaml (grey option) [6]

This establishes drivers as second-order objects that are necessary
for the success of the main projects, and for which requirements
can be loosened. It would establish a new category of team without
the level playing-field requirement and some of the other team
requirements that seem not to apply to driver teams because they
are essentially a public facet of a single vendor.

My preference goes to this option.

I think it's important to continue to say that all OpenStack projects
are expected to be developed as a fair and open collaboration. This is
the reason why we are here. However, some teams work on implementing
drivers for those projects, using established plug-in points to enable
external software, proprietary solutions or hardware to work with
OpenStack. Those drivers are an integral part of the success of our
openly-developed projects, but by their very nature we can't enforce the
same level playing field over proprietary driver development. As a
community, we need those drivers for the success of our mission.

This option basically says that we welcome those driver teams as a part
of our community, while recognizing that they are a different animal. In
this specific and narrow case (second-order objects that implement a
pluggable extension point defined by an OpenStack project) we accept a
different set of team requirements (removing the level playing field
principle). Tracking those teams and their requirements separately
ensures that this deviation is not affecting the message for the main
projects.

An alternative would be the "soft white" option, but I think that if
those teams have different requirements and very limited scope, it's
simpler to list them separately rather than put them all in the same
file. It avoids diluting the "open collaboration" message we send to the
main projects.

I would also be fine with the the "soft black" option (which is
basically repeating the current situation).

Regards,

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 29, 2016 by Thierry_Carrez (57,480 points)   3 8 13
0 votes

I'll rank my preferred solutions, because I don't actually like any of
them.

Excerpts from Doug Hellmann's message of 2016-11-28 13:33:56 -0500:

  1. A resolution requiring projects that consume drivers to host all
    proposed drivers. (red option) [7]

    This would require teams with projects providing driver interfaces
    to also host, in some form, drivers from vendors that ask for
    hosting. The drivers would not need to be in the main project
    repo, but would need to be in a repository "owned" by the project
    team. Project teams would not be considered responsible for the
    quality of the resulting drivers. Contributors to the driver
    repos would be considered part of the electorate for team PTL.

Ideally this question wouldn't even need to be discussed because
teams would accept all drivers, in some form, because they recognize
the importance of contribution of drivers to the success of their
project and OpenStack as a whole. The result would be some drivers
in-tree and others in a separate repository, as described in option
6, without the TC requiring teams to accept the code. This would
encourage collaboration and stem the proliferation of extra teams,
which forestalls some of the issues we're anticipating with resources
at the PTG, Summit, etc.

I understand that the actual social interactions within some teams,
and between teams and contributors from vendors, hasn't been ideal,
but I'm still not convinced that the current path is the right
solution. It will not encourage anyone who is not contributing to
the common parts of a project to do so, and it sets the wrong tone
for the necessary future interactions that happen between contributors
discussing code at driver API boundaries.

The proposal Sean has for the Cinder team to allow a "class 2"
driver type that is basically marked as unsupported by the core
team seems like it's a good compromise and something we could do
in all projects to help users understand the support level of all
the drivers they use (with some of the implementation details to
be worked out).

  1. A resolution and policy change removing the "level playing field"
    requirement (hard white) [4]

    This would completely remove the problematic wording from the
    governance documents (eliminate the restriction on benefiting a
    single company and consider access to specific information for
    some contributors to not be a problem).

If there's no general agreement that teams should host driver
contributions, then I would prefer option 3, which simplifies our
rules instead of adding more. The TC can recognize when a single-vendor
project does not benefit the overall community, and reject it on
those grounds, while allowing driver development teams. We can manage
PTG space and other scarce resources using similar judgment.

  1. Consider driver teams to be a completely different animal, defined
    in drivers.yaml instead of projects.yaml (grey option) [6]

    This establishes drivers as second-order objects that are necessary
    for the success of the main projects, and for which requirements
    can be loosened. It would establish a new category of team without
    the level playing-field requirement and some of the other team
    requirements that seem not to apply to driver teams because they
    are essentially a public facet of a single vendor.

If we feel the need to codify the differences between two types of
teams, then I'll help refine some version of option 5 to do that.

Doug

[0] http://governance.openstack.org/reference/new-projects-requirements.html - requirements for new projects
[1] https://review.openstack.org/363709 - Add networking-cisco back into the Big Tent
[2] https://review.openstack.org/403834 - Proprietary driver dev is unlevel
[3] https://review.openstack.org/403836 - Driver development can be level
[4] https://review.openstack.org/403838 - Stop requiring a level playing field
[5] https://review.openstack.org/403839 - Level playing fields, except drivers
[6] https://review.openstack.org/403829 - establish a new "driver team" concept
[7] https://review.openstack.org/403830 - add resolution requiring teams to accept driver contributions
[8] https://review.openstack.org/403826 - add a resolution allowing teams based on vendor-specific drivers


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 29, 2016 by Doug_Hellmann (87,520 points)   3 4 12
0 votes

On 11/29/2016 08:03 AM, Doug Hellmann wrote:
I'll rank my preferred solutions, because I don't actually like any of
them.

Just curious...what would you "actually like"?

Chris


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 29, 2016 by Chris_Friesen (20,420 points)   3 17 26
0 votes

Excerpts from Chris Friesen's message of 2016-11-29 09:09:17 -0600:

On 11/29/2016 08:03 AM, Doug Hellmann wrote:

I'll rank my preferred solutions, because I don't actually like any of
them.

Just curious...what would you "actually like"?

Chris

My preference is to have teams just handle the drivers voluntarily,
without needing to make it a rule or provide a way to have teams
that only work on a driver. That's not one of the options we proposed,
but the results are like what we would get with option 6 (minus the
precedent of the TC telling teams what code they must manage).

Doug


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 29, 2016 by Doug_Hellmann (87,520 points)   3 4 12
0 votes

On 28/11/16 13:33 -0500, Doug Hellmann wrote:
5. Consider driver teams to be a completely different animal, defined
in drivers.yaml instead of projects.yaml (grey option) [6]

This establishes drivers as second-order objects that are necessary
for the success of the main projects, and for which requirements
can be loosened. It would establish a new category of team without
the level playing-field requirement and some of the other team
requirements that seem not to apply to driver teams because they
are essentially a public facet of a single vendor.

  1. A resolution requiring projects that consume drivers to host all
    proposed drivers. (red option) [7]

    This would require teams with projects providing driver interfaces
    to also host, in some form, drivers from vendors that ask for
    hosting. The drivers would not need to be in the main project
    repo, but would need to be in a repository "owned" by the project
    team. Project teams would not be considered responsible for the
    quality of the resulting drivers. Contributors to the driver
    repos would be considered part of the electorate for team PTL.

These two are my preferred options so far. They both recognize drivers and allow
for this drivers to officially exist in the community. I like the idea of having
the drivers and services under the same team. I'd prefer them to have one PTL
and for there to be more interactions between driver owners and the rest of the
service team.

One thing that worries me about #6, which #5 solves, is that it doesn't clearly
identify drivers. We've had problems in the past communicating the status of
projects to other members, operators and end users. I'm worried that the quality
and stability of some of these drivers would affect a project's "reputation" (so
to speak). Proposal #6 says that project teams must host these drivers but they
are not really accountable for the drivers if they don't live in-tree (note this
could happen even for drivers that are in-tree).

The above is all to say that I'd feel more comfortable with proposal #6 if it
would provide a way to communicate that these repos are drivers, that they are
maintained by a subset of the bigger team, etc. This is something #5 solves by
clearly saying that some driver teams are different. This separation is not only
useful from a community perspective but also for managing these projects/repos.
It allows for setting a new set of rules instead of adding exceptions to the
existing ones.

What I don't like about #5 is that increases the complexity of the process for
adding new projects and it may make communication between these teams more
difficult. It will force the creation of tiny teams w/ all the things required
for teams to exist (PTL elections, ATC management, extra ATC, and what not).

At this point I think I'm leaning more towards #5 because it acknowledges these
drivers are useful but they are essentially managed by a different team, which
is something that #6 doesn't do.

I'll try to come up with some proposals to have #6 communicate this, unless it
was left out on purpose.

Thank you all for working on this,
Flavio

--
@flaper87
Flavio Percoco


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Nov 29, 2016 by Flavio_Percoco (36,960 points)   3 8 11
0 votes

On 2016-11-28 13:33:56 -0500 (-0500), Doug Hellmann wrote:
[...]
1. A resolution reaffirming the "level playing field" requirement,
and acknowledging that it effectively precludes official status
for teams which only develop drivers for proprietary systems
(hard black) [2]
[...]
2. A resolution reaffirming the "level playing field" requirement,
and acknowledging that it does not necessarily preclude official
status for teams which only develop drivers for proprietary
systems (soft black) [3]
[...]
3. A resolution and policy change removing the "level playing field"
requirement (hard white) [4]
[...]
4. A resolution and policy change loosening the "level playing field"
requirement (soft white) [5]
[...]
[2] https://review.openstack.org/403834 - Proprietary driver dev is unlevel
[3] https://review.openstack.org/403836 - Driver development can be level
[4] https://review.openstack.org/403838 - Stop requiring a level playing field
[5] https://review.openstack.org/403839 - Level playing fields, except drivers
[...]

I proposed these because I have a strong preference not to bury the
problem in additional bureaucracy. Either we determine that we want
to recognize the developers writing drivers as an official part of
our community and need to reinterpret/adjust our policies because
they're in conflict with our intent, or we decide that the intent of
our policy necessarily precludes official recognition for driver
teams. Without addressing this issue at its source, we're sort of
avoiding addressing it at all.

I'm not really a fan of the more complex solutions proposed, since
they don't seem (to me) to address the fundamental issue. I feel
like the "Big Tent" only remains true to its design if we have one
kind of team in it. As soon as we begin to define second-class teams
that are still in some way "official" we're back to much of the same
conflict and tension which drove us to our current governance model
in the first place.

The scaling concerns from allowing too many "small" teams who only
develop drivers should be dealt with as a separate issue. There are
plenty of other small, single-affiliation developer teams working
within our community and I think whatever solutions we come up with
for scaling limited resources in the tent shouldn't single out
driver development as the cause.

I think we also need to look harder at the reasons for driver-only
developer teams seeking official status. If it's because they want
to be part of the community and help collaborate with the rest of
us, then as long as they can do that consistent with our overall
goals and ideals I think that's great and we should welcome them as
one of us. If the reason is because they feel it raises the profile
of their products within the OpenStack ecosystem or conveys an
implication of better OpenStack support on their platforms, then we
should work harder as a community to dispel that notion (even if it
means we need to actively sabotage the "tent" as a marketing
platform) and find other places for companies to advertise the level
of OpenStack support their customers should expect.
--
Jeremy Stanley


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Nov 29, 2016 by Jeremy_Stanley (56,700 points)   3 5 7
0 votes

Excerpts from Flavio Percoco's message of 2016-11-29 17:19:15 +0100:

On 28/11/16 13:33 -0500, Doug Hellmann wrote:

  1. Consider driver teams to be a completely different animal, defined
    in drivers.yaml instead of projects.yaml (grey option) [6]

    This establishes drivers as second-order objects that are necessary
    for the success of the main projects, and for which requirements
    can be loosened. It would establish a new category of team without
    the level playing-field requirement and some of the other team
    requirements that seem not to apply to driver teams because they
    are essentially a public facet of a single vendor.

  2. A resolution requiring projects that consume drivers to host all
    proposed drivers. (red option) [7]

    This would require teams with projects providing driver interfaces
    to also host, in some form, drivers from vendors that ask for
    hosting. The drivers would not need to be in the main project
    repo, but would need to be in a repository "owned" by the project
    team. Project teams would not be considered responsible for the
    quality of the resulting drivers. Contributors to the driver
    repos would be considered part of the electorate for team PTL.

These two are my preferred options so far. They both recognize drivers and allow
for this drivers to officially exist in the community. I like the idea of having
the drivers and services under the same team. I'd prefer them to have one PTL
and for there to be more interactions between driver owners and the rest of the
service team.

One thing that worries me about #6, which #5 solves, is that it doesn't clearly
identify drivers. We've had problems in the past communicating the status of
projects to other members, operators and end users. I'm worried that the quality
and stability of some of these drivers would affect a project's "reputation" (so
to speak). Proposal #6 says that project teams must host these drivers but they
are not really accountable for the drivers if they don't live in-tree (note this
could happen even for drivers that are in-tree).

The above is all to say that I'd feel more comfortable with proposal #6 if it
would provide a way to communicate that these repos are drivers, that they are
maintained by a subset of the bigger team, etc. This is something #5 solves by
clearly saying that some driver teams are different. This separation is not only
useful from a community perspective but also for managing these projects/repos.
It allows for setting a new set of rules instead of adding exceptions to the
existing ones.

What I don't like about #5 is that increases the complexity of the process for
adding new projects and it may make communication between these teams more
difficult. It will force the creation of tiny teams w/ all the things required
for teams to exist (PTL elections, ATC management, extra ATC, and what not).

At this point I think I'm leaning more towards #5 because it acknowledges these
drivers are useful but they are essentially managed by a different team, which
is something that #6 doesn't do.

I'll try to come up with some proposals to have #6 communicate this, unless it
was left out on purpose.

I agree that clearly documenting who supports each driver, and how
tightly integrated that team is with the core team will be important.
That will be the case no matter what solution we pick (even saying
that drivers aren't official isn't going to avoid questions about
how well supported a driver is). I left the details of how to do
that up to the individual teams, since I know some are already
working on it.

Doug

Thank you all for working on this,
Flavio


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 29, 2016 by Doug_Hellmann (87,520 points)   3 4 12
0 votes

On 29/11/16 10:28, Doug Hellmann wrote:
Excerpts from Chris Friesen's message of 2016-11-29 09:09:17 -0600:

On 11/29/2016 08:03 AM, Doug Hellmann wrote:

I'll rank my preferred solutions, because I don't actually like any of
them.

Just curious...what would you "actually like"?

Chris

My preference is to have teams just handle the drivers voluntarily,
without needing to make it a rule or provide a way to have teams
that only work on a driver. That's not one of the options we proposed,
but the results are like what we would get with option 6 (minus the
precedent of the TC telling teams what code they must manage).

I don't have a lot of background on why the driver was removed from the
Neutron stadium, but reading between the lines it sounds like you think
that Neutron made the Wrong Call, and that you would like, in order of
preference:

a) Neutron to start agreeing with you; or
b) The TC to tell Neutron to agree with you; or
c) To do an end run around Neutron by adding it as a separate project

Individual projects (like Neutron) have pretty wide latitude to add
repositories if they want, and are presumably closer to the issues than
anyone. So it seems strange that we're starting with a discussion about
how to override their judgement, rather than one about why we think
that's necessary.

What are the obstacles to the Neutron team agreeing to host these
drivers? Perhaps the TC is in a position to remove some of those
obstacles? That seems preferable to imposing new obligations on projects.

cheers,
Zane.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 29, 2016 by Zane_Bitter (21,640 points)   4 6 9
0 votes

On 2016-11-29 11:27 AM, Jeremy Stanley wrote:
I think we also need to look harder at the reasons for driver-only
developer teams seeking official status. If it's because they want
to be part of the community and help collaborate with the rest of
us, then as long as they can do that consistent with our overall
goals and ideals I think that's great and we should welcome them as
one of us. If the reason is because they feel it raises the profile
of their products within the OpenStack ecosystem or conveys an
implication of better OpenStack support on their platforms, then we
should work harder as a community to dispel that notion (even if it
means we need to actively sabotage the "tent" as a marketing
platform) and find other places for companies to advertise the level
of OpenStack support their customers should expect.

I think Jeremy raises a very important point here. What is the
motivation on the part of the driver-only teams?

I personally assumed far too much collaborative intent when I got
involved with supporting the path to third party testing for drivers. My
eyes have since been opened. While there are a few driver maintainers
that are motivated to be collaborative and help others (thank you so
much) they are far from the norm.

I've taken some time away from keyboard to navel gaze a bit and been
quite enjoying it. I've been able to think about some of the material
offered to us during the leadership training in June, particularly
thinking about groups that are successful in creating an environment of
collaboration. I found that one of the most important aspects of groups
that do create and maintain a collaborate atmosphere for all concerned
is the ability to ensure that all concerned are motivated to create a
collaborative environment. Businesses offered as case studies in the
literature provided by Zingermans, create a reciprocally beneficial
collaborative environment through rigorous filtering during interview
and selection processes as well as a commitment to help people move
along should it be evident that they are not motivated by collaborative
intent. OpenStack can't apply the process but it can align with the
spirit of the intent, should OpenStack continue to want to create a
collaborative environment for all concerned.

Some may feel excluded and that is their choice, as long as there is
always a door way in for those that make the choice of having their
actions motivated by collaboration for the benefit of all concerned.

Thank you,
Anita.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 29, 2016 by Anita_Kuno (21,320 points)   3 3 4
...