When a change is not ready to be approved, show the rule for the
earliest date on which it could be.
Change-Id: Ib7f1b3e491fd078fb6697580018f3b05658bd422
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
I have asked Mohammed to serve as vice chair, and he has agreed.
Change-Id: Ifdc2cf103330bb4539910975bcb725adb09af1c4
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
We currently make no provision for the chair to be able to delegate or
otherwise share their responsibilities. This change defines a new vice
chair role to give us a way to designate someone to act in a
supporting role for the active chair and to take over in the chair's
absence so that business does not need to halt when the chair is
unavailable.
Change-Id: I3e520eb0d900bc3d0552afbb5bcb9fd13fd0d09c
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Require new repositories to exist in the gerrit project data managed
by the infra team before they can be added to governance.
Change-Id: Ic465e415d5253d2a918c3cd3ec8861f672360834
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
I have been using this script to apply the house rules to governance
changes to help track when they are ready to be approved. I thought it
would be good to share it for others to be able to see and review the
work.
Change-Id: I41e3338858f546705e78ce5428a09dfe3b904947
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
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
As part of planning out the python3 transition we realized that in
order to have a self-testing patch in each repository to switch the
documentation build to use python3, we would need to include some
information in the repository that the job would read to decide which
version of python to use. After considering several options, we
realized that this requirement meant we had set the API for the
documentation jobs at the wrong "level" of the stack.
This patch restores the use of tox for building documentation in the
standard project testing interface. Rather than using the "venv"
environment, it specifies a new environment for "docs", based on the
common pattern we have in most projects to provide that as a
convenience for developers.
The Python-specific notes about adding the environment as a
convenience are removed, since it is now required.
Change-Id: Ibdee118f30972e9dc67952b921f493e9c1a116ff
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
This commit adds new TripleO Ansible roles to governance
Depends-On: Ib02f9ef8fc9172c65851c1fa30ad51114a4c7e0e
Change-Id: Ie8aea149d97b77bdfd8455d3e36e97bb47510afc
blueprint: ansible-tasks-to-role
Team diversity tags (single-vendor and diverse-affiliation) no
longer provide useful context for our users:
- As projects mature and feature development activity is more
limited, a lot of projects were flapping between states
depending on a couple commits or reviews, cross-project work
or community goals activity.
- In teams where a single individual ends up picking up the bulk
of core reviewing duties, the diversity tags incentivized them
to limit their activity.
- Data was based on Stackalytics, which is not a highly reliable
data source. Basing tags on raw data is not a great idea. Raw
diversity data should be used to raise flags for further
analysis (with context) rather than jumping to conclusions.
- Binary tags can't reflect the complexity of that data.
Single-vendor does not mean the same for PowerVMStackers and
for Keystone. Trends are actually more important than value
at a single point in time.
- Organizational diversity is just one factor of fragility for
project teams. Individual fragility (where the bulk of the
work is done by one person) is actually more prevalent those
days.
Change-Id: I1f1e55a7605ddff572b7b674c58ab419a7fc913f
The Release Management Team has retired the
openstack-infra/release-tools repository, so it should no longer be
tracked as an official deliverable. Move it to the legacy
deliverables list.
Change-Id: Idd17c32bdc851d60d0c9b3815880d07b465418eb
Depends-On: https://review.openstack.org/579185
Add a script that computes team fragility for (past or
current) development cycle, on two axis: corporate diversity
fragility (impact if the most active company abandons the
team), and individual fragility (impact if the most active
individual abandons the team).
The script orders them from most fragile to least fragile.
It's based on imperfect Stackalytics data, so any insight
from that analysis should be investigated deeper before
considering it "real".
Change-Id: If3e481af23c3b9d1a12f538e96c3b3c32f543a02
The PTI reference implies that the docs build job will output rendered
documents to doc/build when it is in fact doc/build/html. Fix up the
doc accordingly to avoid confusing the next guy as I myself was
confused.
Change-Id: I7c3e189cb29164c4934e809e5a64e938307fb320
This adds a note to reflect IRC discussions around how goal tracking
should be handled for past cycle goals.
Change-Id: I2652d97e28457652543413b2113b9a76d49f03b1
Use the max width of all rows to determine
width of the svg generated, rather than taking
the last element's width; this will work regardless
of whether there are 4 badges in the last row.
Change-Id: Ibc427bca0acdab119c0c2b358bba04eec7418327
Adjuant is a service built to help manage certain elements of operations
processes by providing micro APIs around complex underlying workflow. It
started life as a system to manage sign ups to a public cloud, and grew
into a more generic and flexible system into which deployers can add
useful APIs for their users to consume.
The project history can be found on the docs[1], as well as some guide
lines which explain what the scope of the project is, and how we manage
how vague it is[2]. Then there is a section going over what is built
into Adjutant[3].
The project was built to be integrated from the beginning with
OpenStack, using KeystoneMiddleware for auth, will be moving to oslo
policy in the near future, and we hope to switch to using the
OpenStackSDK for all OpenStack API interactions.
Adjutant meets all of the new project requirements easily. The source
is Apache License 2.0, and all libraries used are opensource. While the
project was started internally at Catalyst we use Launchpad for bug and
blueprints tracking and all of us are developers already working
upstream with OpenStack. Code review and gated testing is done on the
OpenStack infrastructure, and the goal is always to support features in
other projects first (see guide-lines doc[2]). We want to build Adjutant
to be useful to the community and have taken care to build ways to keep
company specific logic out of the service by providing plugin mechanisms.
Catalyst Cloud[4] is a company dedicated to opensource, and we always
prefer working with others to achieve a goal that works for everyone
rather than writing internal only solutions. Almost all our work is
opensource where applicable, and we are active in the community.
Catalyst Cloud runs Adjutant in production (very near to master), and we
know of at least another company using it for password resets, as well
as interest from a few more. For Catalyst Cloud it handles our full
automated sign up process, and we run almost all of the default Tasks as
defined in the core codebase for user management.
[1]: https://adjutant.readthedocs.io/en/latest/history.html
[2]: https://adjutant.readthedocs.io/en/latest/guide-lines.html
[3]: https://adjutant.readthedocs.io/en/latest/features.html
[4]: https://catalystcloud.nz/
Change-Id: I0d119fa26b7ed8969870ad0c3f405e0ac3df98e3
We want each goal to have a champion, so update the template to
mention that.
Change-Id: I896615dfa8c3528fe8cd005f015e4ee0ac4472d3
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Track each current TC member's E-mail address next to their name and
IRC nick in the members roster and include it in the rendering on
the governance site, to make them easier for community members to
figure out how to contact in private when needed. We've included TC
candidate contact E-mail addresses in the elections repository for
many cycles, but not recorded them in governance once elected. The
addresses themselves are far from secret and are already "published"
in our election results records, so there's little to be gained by
omitting them from governance.
Change-Id: If7c22f056d33e874b606c48d86d1e4236eae8a99
Display each current PTL's tracked E-mail address next to their name
and IRC nick. We've been tracking PTL contact E-mail addresses in
the governance repository for many cycles, but not presenting them
on the rendered
https://governance.openstack.org/tc/projects/<team>.html team detail
pages. The addresses themselves are far from secret and are already
"published" in the YAML version of our projects list, so there's
little to be gained by obscuring them from/in the HTML version.
Change-Id: I55d0ea058f645e8ba91cfc186eee00488ddbedcb
Story: #2001923
Task: #14450
Per the past year of discussions, culminating in the most recent
mailing list thread[*], it's apparent that providing a consistent
solution for storage of key material and similar secrets by security
features of various OpenStack services is in the best interests of
the project. By providing this guarantee in the base services set,
projects don't need to worry about implementing insecure fallback
alternatives or needlessly duplicating functionality to cope with
the lack of an already-available solution.
[*] http://lists.openstack.org/pipermail/openstack-dev/2018-May/130567.html
Change-Id: Ia46211f41726d5671bf28a632d17fc56965b6fcc
