During discussion in below review, there were thought
to make CHAIR.rst file a official reference doc so that
we can update and refer it our formal polciies
- https://review.opendev.org/c/openstack/governance/+/896150
I think it make sense to make it more official doc so that we
refer and keep it up to date.
Change-Id: I8c582c51af89bb654079d9f2ef8674951a049760
We have the release based runtimes documented in this repo and
published. However, The link to them from within the PTI page is
easily missed. This change adds a specific runtimes index page and
links to that from the reference section of the governance homepage.
The list included in the PTI page uses the default ascii sorting i.e.
2023.1, 2023.2, 2024.1, Stein, ..., Zed
The change also updates this list to follow the release order.
Change-Id: I0b8cd23986f6abb168486f8cf2a8c30e2a1b30e9
As discussed in PTG[1], we need to define the process
for the TC chair nomination and election.
This commit adds one of the proposal discussed in the PTG
which is to record the nomination in governance repo.
[1] https://etherpad.opendev.org/p/tc-2023-1-ptg#L486
Change-Id: Ia29b92b41ddd7cccda5d9daa317ac4bb0af907ff
At the October 2021 PTG and April 2022 PTG we discussed the need to for
something like "technical preview" state for the e.g. new OpenStack
projects which don't meet all requirements for being official OpenStack
project (see Skyline for example).
This patch adds framework for such projects. It's called "emerging
technology" state which can be set for new projects.
It also defines "inactive" state for the existing, not well maintained
projects.
Change-Id: I32a07f8bb46723f36c1bf846644b6aa768778a4f
TC is more connected with project teams with the
weekly meeting and PTG TC+Leadership interaction sessions.
Also, TC liaisons did not work the way we expected it. In Zed
PTG, we decided to remove it.
- https://etherpad.opendev.org/p/tc-zed-ptg
Change-Id: I08702b015245df35d40e08fa08a3269cc6bb1cac
We are late by 3 week for PTL and 4 week for TC
election this time, Let's record this exception
and also agreement in TC.
I will add another review to link this exception
doc to TC charter speed up this exception let's
vote on this first as chrater change need more votes.
Change-Id: I4731e9bbd082824e72e307cc5c0d59e9ba93d439
Follwing discussions about the lack of onboarding
that has happened the last couple TC elections, this
guide will provide the information that these and new
members going forward need to be successful.
Change-Id: I25e78420824b5bc34fff3b71bae6e0451a8a20d2
Create a single governance body to represent all contributors
to OpenStack (developers, operators and end users of the software).
The User Committee is defined in the OpenStack Foundation
bylaws, and amending those is very costly (in time, money and
effort). Luckily, the bylaws defer most of the UC details to a
User Committee charter, which contents are modifiable by the
User Committee itself.
This change adds a minimal User Committee charter that implements
the User Committee as a subcommittee of the Technical Committee.
This allows to operate as a single group without requiring costly
bylaws changes to be implemented first.
Change-Id: I8614f650bbc4176929caf15304cdefaed070c3f6
Without this patch, one might wonder which team owns the "OpenStack" name in
an external service.
This should clarify the current ownership for a few known services.
Change-Id: I88996e3302f9bee7c3ab81bd0f5017f300590616
During OpenStack history we have added a lot of OpenStack project
teams, and while we have dropped a few along the way, we do not
have a clear set of considerations to take into account in that
process.
In particular, relying purely on activity levels to consider
dropping projects has proved unproductive in the past, as well
as encouraging people to step up for less-strategic abandoned
projects.
Here is a set of guidelines we should use in future such discussions.
Change-Id: I2c798a6d52a2666657dce201a7c02561d2f4d4ed
For this release, it came to our attention we don't
have a document detailing the little ins and outs after
joining the TC. This document, based on Doug Hellmann's
email in March 2019, details a few of the steps when a new
TC is elected, and edited based on latest CHAIR information.
Signed-Off By: Alexandra Settle <asettle@suse.com>
Co-Authored-By: Jean-Philippe Evrard <jean-philippe@evrard.me>
Co-Authored-By: Nate Johnston <nate.johnston@redhat.com>
Change-Id: I7b4faba2f69badc14272daf5a8587c728d4d7f57
The previous 'Help Most Needed' list was presenting information in a way
that focused on the desires of the community rather than the value that
sponsoring organisations can generate - for both themselves and the
commons. Replace the list with a new list of 'Upstream Investment
Opportunities', and a process to keep them current by removing them
after they have been on the list for between 6 months and a year, so
that the submitter is forced to reaffirm their interest and the TC is
forced to re-evaluate the relevancy.
Since the current 'Help Most Needed' entries are generally not written
in a style emphasising the value to a business of investing, the initial
list is empty and will be filled as the TC evaluates business cases
according to its new criteria and understanding of the needs of
potential contributing organisations.
To preserve the existing information, the contents of the current 'Help
Most Needed' list appear as the 2018 upstream investment opportunites.
Links to the old list will temporarily redirect here until such time as
the new entries are in place, at which point we can redirect to the main
page with the latest index.
Change-Id: I65fef701dc2e3d50aa84e7ee79b068c78346c846
Following the discussion at the Forum in Denver and the TC meeting
at the PTG (also in Denver) one of the outcomes[1] of those discussions
was to propose a lightweight framework for popup teams.
To avoid repeating past failures in cross-project work, this proposal
pushes forward a relatively low barrier to entry, with the TC making an
early decision on whether the team objective sounds like a good idea
for OpenStack, rather than approving detailed implementation specs. It
focuses on supporting the popup teams rather than "blessing" them.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006225.html
Change-Id: I39a4c3814ec3442c60c91055b41b0876976aaeab
There are a lot of misconceptions around what the role of the
Technical Committee is in OpenStack governance. Create a living
document to clarify that.
Change-Id: I4700ce494bb2f1158e56dfb23110db219d5e2dfb
Set out a vision for OpenStack clouds that clarifies, in long form, the
meaning of the mission statement at a technical level. Define what we
mean by 'cloud', describe how OpenStack must be different from other
cloud offerings, and list the design goals that we hope the OpenStack
system as a whole will achieve.
Change-Id: Ie988d87365cd2e190f2c6c13ee178f1590e4642d
We should not wait to have 5 areas needing help to publish the
list, nor always have 5 areas on the list.
Change-Id: I664cfc6faeaf15b8adcbc47ceb490e6435d164b1
Election officials never formally derived their authority from
governance documents, which created a bit of a loophole. It also
made election orgnization a bit ad-hoc at the last minute. In
Sydney our usual victims for the election official roles asked
for a more official definition of their role that would let them
do more long-term planning of election and tooling improvements.
This document proposes the creation of TC working groups (to match
the concept of UC working groups), and sets up the election officials
as one of those working groups.
Change-Id: I1e25a9324dafd23e08b388b966b48103537ac56e
We want to make it clear that the vision document is a point-in-time
document, and not meant to be updated as a living document. We will
produce new visions in the future.
Change-Id: I34117506468a78c42968acc8dacb7bfc40a8e613
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
A lot of people, especially contributors and organizations that are new
to OpenStack, are seeking guidance on how to make useful, strategic
contributions to OpenStack. While some of those strategic priorities are
long-standing and well-known, in the absence of a formal list blessed by
the Technical Committee a lot of contributors are turning to
Stackalytics to guess what a useful contribution is. Beyond wasted
resources and being annoying to core reviewers, this results in a
failure to drive those new contributors to what could be extremely
useful contributions, and prevents them to step up in the community.
In order to address that, this change establishes a "top 5" list of
areas where help is wanted. At this stage we'll leave it up to
Foundation staff to promote (through keynotes, web pages and blog
articles) the contributors and organizations who step up to help in
those areas. This list will send a clear signal to folks who are looking
at things like Stackalytics and tell them where exactly their effort is
valuable for the community as a whole. Folks on the Technical Committee
will help guide the work, monitor progress and report back to the wider
audience.
Change-Id: I91a24de4f812319d45709e7c65210c6bc49b3213
Co-Authored-By: Davanum Srinivas <davanum@gmail.com>
The following is a vision document that was created by the Technical
Committee. It imagines what the TC and the OpenStack community look
like 2 years out. The goal is to paint a picture of where we want to
be, to help us all know if we're doing things to get us there.
Change-Id: Ifde9f19cfa07c62320e2ce09f6d5e803357aa0b4
Introduce the concept of "base services" (external services that
OpenStack components can assume will be present in any OpenStack
installation) and list current base services.
This is intended to reflect the current situation. Changes to the
list should be proposed as subsequent patches.
You can find a more detailed analysis and rationale for this change
in the Architecture WG analysis:
http://git.openstack.org/cgit/openstack/arch-wg/tree/active/base-services.rst
Change-Id: I77ffc000d895c3d8eb27b3b821c6c63f9dd2f675
This patch adds a reference document explaining the process for adding a
new language to the OpenStack ecosystem. Early discussions of the
content in this patch happened in a ML thread[0].
[0] http://lists.openstack.org/pipermail/openstack-dev/2016-November/106877.html
Change-Id: I7202b619dae60facf27eff35f5e99e018c01858c
Beyond the Four Opens, the OpenStack community (and the Technical
Committee as its direct representation) operates on a lot of
unwritten principles, which were transmitted by oral tradition
by the elders and appear from time to time as a snippet of wisdom
in the middle of a TC meeting.
It is more than time for us to document those principles, to make
them clearer to everyone and harder to ignore. To give credit where
due, the bulk of this document was written by Monty Taylor, with
input from a number of other folks including (but not limited to)
the list of co-authors below.
Change-Id: I0134b0aa9b512ee61fbb908d23e7260ff2491bba
Co-Authored-By: Monty Taylor <mordred@inaugust.com>
Co-Authored-By: Doug Hellmann <doug@doughellmann.com>
Co-Authored-By: John Garbutt <john@johngarbutt.com>
Licensing requirements under the big tent have been unclear at best.
The Foundation bylaws impose some of them, but their interpretation
was left as an exercise to the reader. The TC traditionally came up
with rules for dependencies (through the requirements repository
README) but those were mostly unchecked. Finally, we need flexibility
for the project infrastructure, which should be able to run any
open source solution that fits.
After much back and forth with the Foundation legal counsel on what
could be acceptable under the bylaws, we agreed that the following
proposal was acceptable, and compatible with the current situation.
I propose we add it as a reference document to our governance
repository so that it's easier to point prospective projects to it,
and to track changes in the list of acceptable licenses over time.
Change-Id: I7ed11388e43bd5fcf2e8e6595c353429300387d5
The project's stance on the Four Opens is currently in the wiki, which
isn't a great place for such an important piece of information. We
should make it a bit more official.
Change-Id: I96ccb0ef823aca95b1fd0e7c2e1be3207ad52d00
Render the YAML file contents as the list of official teams and create a
directive to render the list of projects with a given tag to avoid
having to update that data in two places.
Change-Id: I7c6effe6e440f2147f8c68df090152e716c38fba
This is generally based on our current process, but makes it clear
that the release name is entirely selected by the community.
Change-Id: Ibd2c6060da2742dd62bbb121a80e6cbfeabedcd0
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
For seamless transition between the previous project structure and the
upcoming one, import the old 'integrated-release' concept as a tag. When
this concept will have been fully split into more meaningful tags, this
tag will be discontinued.
Change-Id: I5a190a2d0d190f459d69f530e966fa094b235939
A template for proposing new tags in the project taxonomy. See next
change in the patchseries for a practical example.
Change-Id: If843e0166583aa9709c19ef4825f3a851a20ede4
Update index page for the governance.openstack.org TC docs publication
website, in order to match content from the wiki page.
This will allow to deprecate the "reference" nature of the wiki page and
make it more about the meeting and the process to propose changes.
Change-Id: I7745156d91aa2e1a4b45160bd7f721ce541ab175
This text was approved by the PPB way back in OpenStack's history. There
are several things which have changed and have not been recorded in it,
and there is a new change that should be made. For now, this is verbatim
what was voted on in the past. Changes will follow to update to current
reality.
Change-Id: I9b5e0e5a52aab1d00497d2e8a75e9c9b249a27e9
Add a memberstable directive that knows how to parse
the membership roster and add it to the sphinx document
tree to be rendered.
Change-Id: I099c7c061d6f51c8a2678d35aeddde4f436df25c
Create index pages with toctree entries to load the existing
documents so they are all linked together.
Add titles to some of the documents that did not have them to
make them work with sphinx.
Change-Id: I0d44cfe1a75ab7df07e0efc989eb7cf161d9bf78
Ghanshyam Mann