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
Turn on flake8 for code style checks, like in our other repos. Fix or
explicitly ignore various issues to allow the linter job to pass.
Change-Id: I7bfd8cf5e9c00dfa83c0393a4307fd54d2113047
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Yaml.load() return Python object may be dangerous if you receive
a YAML document from an untrusted source such as the Internet.
The function yaml.safe_load() limits this ability to simple Python
objects like integers or lists.
Reference:
https://security.openstack.org/guidelines/dg_avoid-dangerous-input-parsing-libraries.html
Change-Id: Icf559f9c8b37c6f564c820fde79c85a77ba4f839
The release:has-stable-branch is useless and should be retired:
- The git repository is the true source of information whether
a given repo has stable branches or not. The tag is therefore
redundant, and often inaccurate (since it's not necessarily
updated when a project creates stable branches).
- Having "stable" branches does not mean that the repository
applies the common stable branch maintenance policy. This
tag therefore does not convey any useful information for our
downstream users. Whether a project follows stable policy or
not is now described using the stable:follows-policy tag.
Change-Id: I7d7d24db0de4728977218f9b7fadc060f69c2e55
Objectively communicates when project teams are driven by a single
organization, so that this fact can be taken into account in project
adoption decisions.
Change-Id: I399046ab7c3266b08c2a48382abfb89c33aab146
The diversity script had a single function that gathered a bunch of
stats from stackalytics and also determined whether the diversity
criteria was met. Split the policy check out. This is just a bit of
refactoring in preparation for adding some additional stats and policy
checks based on this code.
While we're at it, rename the script to 'teamstats', since this will
soon be looking at more than diversity.
Change-Id: I7993249b14cbb94a4700de10fc31bc0cd0394cf7
Signed-off-by: Russell Bryant <rbryant@redhat.com>
Our current projects.yaml file lists project teams and git
repositories associated to those. However, things we publish
as a single "thing" may be represented by multiple code
repositories. For example, a "neutron" release is actually made
of openstack/neutron and openstack/neutron-*aas. A "sahara"
release is actually made of openstack/sahara, openstack/sahara-extra
and openstack/sahara-image-elements. Those are all tagged at the
same time with the same version number, and published together
as a single "deliverable".
This change proposes to encode this layer in the projects.yaml file.
It also proposes to apply tags to the deliverable level rather than
at git repository level. Tags are meant to apply to things that are
consumed by our users, not to the technical pieces that help us
build those things. Note that for most projects have single-repo
deliverables and won't really look different. See Sahara and Neutron
in the proposed file to see examples of multi-repo deliverables.
Since this introduces a breaking change in the file format, we also
take the opportunity to simplify the YAML format: since tags no
longer have attributes they can be listed as an array rather than
as a dictionary, sparing us the useless "name:" part.
Change-Id: I2aa729d1b4278743a5e99b41178dc2d11b3e1348
Add tools/validate_tags.py framework to automatically validate the usage
of tags in reference/projects.yaml. This is only for tags that can be
enforced pragmatically.
This is not intended for gating purposes, rather to make the process of
updating projects.yaml easier.
Supports both team and repository based tags.
Updated diversity.py to work with validate_tags
Change-Id: Id477bfcfccb4dbf5f03f328273c9487ccc48e054
Thierry Carrez