Clarify new project requirements for community engagement
From discussions on the mailing list[1] it seems that there is support for the idea that projects that being with a code drop present a higher risk of failing to attract interest outside of the initial developers. This change aims to clearly communicate the TC's position to projects considering applying to join OpenStack, by explicitly stating both that code drops may be required to demonstrate traction in the community, and that no such requirement for community engagement exists in general. [1] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129703.html Change-Id: I8ee9bb08ee143402e2b8240e3cbe6ba5b0684596
This commit is contained in:
parent
0a90d65df3
commit
fa0a930642
@ -88,6 +88,16 @@ candidate projects may ask the Technical Committee for an early answer on
|
||||
the question of alignment with the OpenStack Mission, before the project is
|
||||
set up on OpenStack development infrastructure.
|
||||
|
||||
If the project has not followed the 4 Opens since its inception - i.e. it was
|
||||
seeded with the release of a pre-existing code base - then the TC may look for
|
||||
evidence of active engagement from the community, beyond the original authors.
|
||||
If the community did not get the opportunity to contribute to the earliest
|
||||
decisions (which are usually the hardest to change), then a lack of subsequent
|
||||
community engagement is of greater concern, as it may indicate that the project
|
||||
only meets the needs of a single organisation. Projects that have always
|
||||
followed the 4 Opens are not subject to any particular standard of community
|
||||
engagement.
|
||||
|
||||
Once a project has joined OpenStack, it may create additional source code
|
||||
repositories as needed at the discretion of its Project Team Lead (PTL) without
|
||||
prior approval from the TC as long as the additional source code repositories
|
||||
|
Loading…
Reference in New Issue
Block a user