Add team:single-vendor tag

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

reference/projects.yaml

@@ -9,6 +9,8 @@ astara:
     load balancing, vpn) for connecting and security multi-tenant OpenStack
     environments.
   url: https://wiki.openstack.org/wiki/Astara
+  tags:
+    - team:single-vendor
   deliverables:
     astara:
       repos:
@@ -316,6 +318,8 @@ cloudkitty:
     is to fit in-between the raw metrics from OpenStack and the billing system
     of a provider for chargeback purposes.
   url: https://wiki.openstack.org/wiki/CloudKitty
+  tags:
+    - team:single-vendor
   deliverables:
     cloudkitty:
       repos:
@@ -380,6 +384,8 @@ congress:
     services in order to monitor, enforce, and audit policy over
     dynamic infrastructure.
   url: https://wiki.openstack.org/wiki/Congress
+  tags:
+    - team:single-vendor
   deliverables:
     congress:
       repos:
@@ -410,6 +416,8 @@ cue:
     To provide a multi-tenant service that offers scalable and reliable
     provisioning and management capabilities for off-the-shelf message brokers.
   url: https://wiki.openstack.org/wiki/Cue
+  tags:
+    - team:single-vendor
   deliverables:
     cue:
       repos:
@@ -556,6 +564,8 @@ freezer:
     This is achieved by supporting multiple and parallel media
     to store backups.
   url: https://wiki.openstack.org/wiki/Freezer
+  tags:
+    - team:single-vendor
   deliverables:
     freezer:
       repos:
@@ -1765,6 +1775,8 @@ monasca:
     services that can be used by both operators and tenants to gain
     operational insight and visibility, ensuring availability and stability.
   url: https://wiki.openstack.org/wiki/Monasca
+  tags:
+    - team:single-vendor
   deliverables:
     monasca:
       repos:
@@ -2113,6 +2125,8 @@ OpenStackAnsible:
     Deploying OpenStack from source in a way that makes it scalable
     while also being simple to operate, upgrade, and grow.
   url: https://wiki.openstack.org/wiki/OpenStackAnsible
+  tags:
+    - team:single-vendor
   deliverables:
     openstack-ansible:
       repos:
@@ -2455,6 +2469,8 @@ Packaging-deb:
     email: zigo@debian.org
    mission: >
      Maintain packages for Debian (and other deb based distributions) as a community.
+   tags:
+     - team:single-vendor
    deliverables:
      deb-openstack-pkg-tools:
        repos:

reference/tags/index.rst

@@ -19,6 +19,7 @@ Team Description Tags
    :maxdepth: 1
 
    team_diverse-affiliation
+   team_single-vendor
 
 Project Assertions Tags
 =======================

reference/tags/team_single-vendor.rst

@@ -0,0 +1,90 @@
+::
+
+  This work is licensed under a Creative Commons Attribution 3.0
+  Unported License.
+  http://creativecommons.org/licenses/by/3.0/legalcode
+
+.. _`tag-team:single-vendor`:
+
+==================
+team:single-vendor
+==================
+
+This tag communicates that a given project team is currently driven by a
+single organization.
+
+This tag exists in the 'team' category, which as the name implies,
+covers information about the team itself.
+
+
+Application to current projects
+===============================
+
+It's worth pointing out that the criteria used for this tag is applied across
+all git repositories managed by a team.
+
+.. tagged-projects:: team:single-vendor
+
+Script used to apply this tag:
+http://git.openstack.org/cgit/openstack/governance/tree/tools/validate_tags.py
+
+
+Rationale
+=========
+
+Knowing that a given project is produced by a team essentially from a single
+organization is a critical factor in the decision to deploy a project, as it
+changes the dynamics of who you trust to continue to deliver this project.
+
+In particular, such a project could be abandoned due to the budgeting
+decisions of a single party. Additional steps (like engaging early on with
+that single party) could be taken before investing significantly on such a
+project.
+
+
+Requirements
+============
+
+The tag applies to any project team where one organization represents >=90% of
+any of the following over the prior six months:
+
+* the sum of all commits merged into any of the git repositories managed by the
+  team
+
+* the sum of all reviews done against patches submitted to any of the git
+  repositories managed by the team
+
+* the sum of all reviews done by core reviewers against patches submitted to any
+  of the git repositories managed by the team
+
+* the union of the memberships of the core review teams associated with the git
+  repositories managed by the team
+
+The application of this tag to new projects should be updated around the same
+time as the 6 month release. But the removal of this tag should happen shortly
+after it does not apply to a given project.
+
+Based on how requirements are defined, this tag is only applicable for projects
+where their primary deliverables are represented by commits and reviews in git.
+
+
+Tag application process
+=======================
+
+The criteria for this tag is objective. The TC could approve any future
+updates to the tag definition and otherwise defer application of the tag. A
+method for delegating this is TBD, so in the meantime, we default back to the
+following process:
+
+Anyone may propose adding or removing this tag to a set of projects by
+proposing a change to the openstack/governance repository. The change is
+reviewed by the Technical Committee and approved using standard resolution
+approval rules, including discussion at at least one Technical Committee
+public IRC meeting.
+
+
+Deprecation
+===========
+
+There is no deprecation period required for this tag.  It can be added or
+removed at any time.

test-requirements.txt

@@ -2,3 +2,4 @@
 sphinx>=1.1.2,!=1.2.0,<1.3
 oslosphinx>=2.2.0  # Apache-2.0
 PyYAML>=3.1.0
+requests-cache

tools/teamstats.py

@@ -17,10 +17,14 @@ import sys
 import time
 
 import requests
+import requests_cache
 import yaml
 
 import base
 
+# Since the stackalytics is slow and we can call it twice, cache the results
+requests_cache.install_cache(backend='memory', expire_after=60)
+
 s = requests.session()
 
 six_months = int(time.time() - 30*6*24*60*60)  # 6 months ago
@@ -136,9 +140,9 @@ def get_diversity_stats(project):
     return team_stats
 
 
-def get_diversity(team):
+def is_diverse(team):
     team_stats = get_diversity_stats(team)
-    is_diverse = all((
+    diversity = all((
         (team_stats['commits_top'] <= 50),
         (team_stats['reviews_top'] <= 50),
         (team_stats['core_reviews_top'] <= 50),
@@ -148,7 +152,18 @@ def get_diversity(team):
         (team_stats['core_reviews_top2'] <= 80),
         (team_stats['core_reviewers_top2'] <= 80),
     ))
-    return is_diverse
+    return diversity
+
+
+def is_single_vendor(team):
+    team_stats = get_diversity_stats(team)
+    multi_vendor = all((
+        (team_stats['commits_top'] < 90),
+        (team_stats['reviews_top'] < 90),
+        (team_stats['core_reviews_top'] < 90),
+        (team_stats['core_reviewers_top'] < 90),
+    ))
+    return not multi_vendor
 
 
 def print_diversity(team):
@@ -173,13 +188,25 @@ class ValidateDiversity(base.ValidatorBase):
     @staticmethod
     def validate(team):
         """Return True of team should have 'team:diverse-affiliation'"""
-        return get_diversity(team)
+        return is_diverse(team)
 
     @staticmethod
     def get_tag_name():
         return "team:diverse-affiliation"
 
 
+class ValidateSingleVendor(base.ValidatorBase):
+
+    @staticmethod
+    def validate(team):
+        """Return True of team should have 'team:single-vendor'"""
+        return is_single_vendor(team)
+
+    @staticmethod
+    def get_tag_name():
+        return "team:single-vendor"
+
+
 def main():
     filename = os.path.abspath('reference/projects.yaml')
     with open(filename, 'r') as f:

tools/validate_tags.py

@@ -34,6 +34,7 @@ import urllib
 # List of modules to validate team based tags
 team_validators = [
     teamstats.ValidateDiversity,
+    teamstats.ValidateSingleVendor,
 ]
 
 # List of modules to validate repository based tags