This adds a requirement to remove all users except opensatckci from the
list of project maintainers in PyPi according to solution made on TC
meeting [1]
[1] https://meetings.opendev.org/meetings/tc/2023/tc.2023-02-01-16.00.html
Change-Id: I3c7d74f98adecc9d60764fe00308f1eca1f5da66
Now that we have the OpenStack project map, it is clear that our
description of the required scope for new projects really only
encompasses the main 'OpenStack' bucket on the map, when we have in
practice included several other classes of projects and always intended
to continue doing so.
https://www.openstack.org/assets/software/projectmap/openstack-map.pdf
This change documents the allowed purposes of new projects, using the
categories defined in the project map to describe them.
Change-Id: I02e91254fea83acbdb694dffefc7d864f0bad105
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
Release management of official projects is handled by
the Release Management team through the openstack/releases
repository. Set the expectation early on that official
projects will have to drop direct tagging (or branching)
rights in their Gerrit ACLs once they are made official.
Needed-By: https://review.openstack.org/557733
Change-Id: Iade3f85d133892464e4c9f21ce2977ca0dd8930d
In I631e2597bf818c5e4b2f813da14764d2cb55d0ce the TC passed
resolutions/20170718-allow-scheduling-meetings-on-team-channels which
allows teams to host meetings in per-project IRC channels.
However the new-projects-requirements still stated that meeting needed
to be held in one of the central meeting channels. This change updates
that document in light of the resolution.
Change-Id: Ib8febcc6b80bc36833f2040b1cc1c5eb15841655
As we look at alternatives to regular IRC meetings, lets move the
requirement for meetings.
To smooth the transition we keep the requirement that if any meetings
happen they are kept open.
Change-Id: I3242d256aeea75183acf9f848fbf1526d099ac87
Add some clarifications on the project addition process,
in particular mention the possibility to ask the TC for
an early read on the adequation of project scope with the
OpenStack mission, and link the process from the projects
team list for easier discovery.
Change-Id: I26aa7e76a71992c93a3e1e284b09d8a56046e8e2
One of the outcomes of the discussion at the leadership training session
earlier this year was the idea that the TC should set some
community-wide goals for accomplishing specific technical tasks to get
the projects synced up and moving in the same direction.
This patch includes the proposed process for managing those goals, a
template for describing a goal, the placeholder for goals for the Ocata
cycle, and a tool for mechanically generating part of the documents.
I had help with reviews and drafts of some portions of this text from a
bunch of other folks including jroll, dtroyer, johnthetubaguy, spamaps,
mordred, ttx, notmorgan, thingee, and amrith.
Change-Id: I46cc66eafe9dbcfda94fb6a1a8c66c2ca77de45a
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
From an upstream perspective, I see us as being in the business
of providing open collaboration playing fields in order to build
projects to reach the OpenStack Mission. We collectively provide
resources (infra, horizontal teams, events...) in order to enable
that open collaboration.
An important characteristic of these open collaboration grounds
is that they need to be a level playing field, where no specific
organization is being given an unfair advantage. I expect the teams
that we bless as "official" project teams to operate in that fair
manner. Otherwise we end up blessing what is essentially a trojan
horse for a given organization, open-washing their project in the
process. Such a project can totally exist as an unofficial project
(and even be developed on OpenStack infrastructure) but I don't
think it should be given free space in our Design Summits or
benefit from "OpenStack community" branding.
So if, in a given project team, developers from one specific
organization benefit from access to specific knowledge or hardware
(think exclusive access to proprietary hardware or software that
the open source code primarily interfaces with), then this project
team should be rejected under the "open community" rule.
This requirement (like all requirements in this document) is meant
to be interpreted by humans on a case-by-case basis. In particular,
there is a grey area around drivers for proprietary solutions that
requires human judgment here. As a rule of thumb, if the open
implementation was unusable open core bait to lure people into
using the one and only proprietary driver, it would be a problem.
If the open implementation was fully functional and nothing
prevented adding additional proprietary drivers to the code base,
there would be no problem.
Change-Id: I0cd689afb8ddb7a269b9ce378e4c6647652f6977
As seen from the current PTL election, the elections isn't something
that was right away understood by some project's initial PTLs. This
stresses more about the participation in the election is required and
where to find those projected election dates.
Change-Id: Ie7df8538aaebcb4c0b329bbc3dd99b211c6dd9cf
The recent application by the Kosmos project [1] prompted a discussion
on whether or not a project should apply to the TC right away or if it
should have some amount of history of operating as an OpenStack project
first. The consensus on that application was that we should wait and
let the project get going first.
This patch updates the new projects requirements to clarify this point.
As noted by ttx on [1], this guideline will henceforth be known as
"the Kosmos jurisprudence".
[1] https://review.openstack.org/#/c/223674/
Change-Id: Ifc964d09ea2107e3ecd95f9579543bcb77f457d0
Signed-off-by: Russell Bryant <rbryant@redhat.com>
Also be clearer that the gate we want has to be on the OpenStack
infra, not in some random other place, and finally, move the ability
to make new repos from being a 'requirement' to being separate prose.
Change-Id: I38e545f8539195d79d6dfb42a8ec0d8eca435ccd
The new project requirements previously contained prose which was
ambiguous or misleading about when it's okay to apply to the TC for
creation of a project team. New projects with any size team working
on software at any stage of development are welcome to apply.
Change-Id: I8d80681caccee7570303c46fe603426f76254af0
A recent change incorrectly described PTL as being a "Technical"
lead but it currently stands for "Team" lead.
Change-Id: I10a2a7a63e268ac46f5279d064786654e15dcf95
The 2014-12-02 OpenStack project structure reform resolution
indicates that using "#openstack-meeting channels for their team
meetings" is a one-of-us criterion for being considered an OpenStack
project. Clarify this point in the new project application
requirements. Also spell out that this means the meetings are held
in public for all to participate, and the logs are published
somewhere so that anyone can review them later.
Change-Id: Ia34e9bb1d2db3094f61968b2bb9a7849f2bc7fd9
Some OpenStack projects are adding git repos at a moderate pace
and generally the TC is rubber-stamping them as long as the PTL
approves. Explicitly codify that this is desirable -- the TC
doesn't really care how many git repos it takes to accomplish a
task, so as long as a new repo fits within the existing mission
statement, indicate that it is permissible to add it without
prior TC approval.
This is not strictly a "new project requirement", however, this
document seems to be the best existing place to add it as it
relates to project creation.
Change-Id: I34acfe4ffe5a0af6a941e70a5315a07d036e6c24
To better convey the intent of the requirement, just say that we
would like projects to use similar technology, but acknowledge this
is a subjective requirement and avoid mentioning oslo specifically.
Change-Id: I65bf84b07c9dfe5df19e67a4374311d1c633a9e0
Move from a program-driven project structure (which prevented
competition and innovation) to a project-based structure. Introduce
new simple objective requirements for future OpenStack projects.
Remove incubation process (keeping old incubation/integration
requirements doc around as a reference until it's converted into a set
of representative tags).
This change is heavily based on a previous proposal by Doug Hellmann
(see https://review.openstack.org/#/c/131422/1)
Change-Id: Ida9f60d8cbd0dcf48669b82e619fc4016ee0bcb7
Dmitriy Rabotyagov