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

reference/new-projects-requirements.rst

@@ -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