Jump to: navigation, search


< Operations
Revision as of 00:17, 22 May 2015 by Fifieldt (talk | contribs) (Created page with "=Ops Tags Team= Moderators: Tim Bell, Jonathan Proulx, Subbu Allamaraju, Tom Fifield ==Mission== A team to define tags for ops, allowing users to make better decisions by pro...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Ops Tags Team

Moderators: Tim Bell, Jonathan Proulx, Subbu Allamaraju, Tom Fifield


A team to define tags for ops, allowing users to make better decisions by providing useful information about OpenStack software projects.


  • Induct and coordinate volunteers to achieve the objectives of the team.
  • Manage the process for adding new tags in the ops:* namespace.
  • Manage any disputes related to ops:* tag value assignment
  • Continuously assess ops:* tag values as projects change.
  • Conduct the ops:* tag assessment for new projects as they are released.


  • tom@openstack.org - can help think of tags, organise meetings, and also validate tags against projects
  • subbu@subbu.org
  • richard@raseley.com
  • jim.meyer@hp.com
  • jbajin@verisign.com
  • matt@nycresistor.com
  • kevin.carter@rackspace.com
  • jon@jonproulx.com
  • jkeating@bluebox.net
  • abearfield@bluebox.net
  • sridhar_basam@cable.comcast.com
  • ctracey@bluebox.net
  • cperry@bluebox.net
  • jeb@hp.com
  • chricker@cisco.com
  • mdorman@godaddy.com
  • mkassawara@gmail.com
  • manojsh3@cisco.com
  • msaidelk@cisco.com
  • karl.harris@sungardas.com
  • stefano@openstack.org
  • jaypipes@gmail.com
  • jgb@bitergia.com - would like to contribute mainly on how to map some tags to software development metrics
  • berendt@b1-systems.de
  • tim.bell@cern.ch
  • thierry@openstack.org
  • mizuno.shintaro@lab.ntt.co.jp

Previous Meetings

What are Tags?

   When applied to a project, Tags are comprised of a name (eg "Ops:Deployment-Widespread", "Ops:Config-Recipes-Available", "Ops:Packaged"), a value (eg "92%", "yes", "Ubuntu, Redhat and SUSE") and if applicable a description of why the project has that value.
   Particularly, any tag that is not a 'perfect' result should have a bug report or some other information on steps to fix it
   All tags are advisory only. They're RFC-style: IETF, not IEEE :)
   Tags should easily facilitate caveats. Eg due to 2011 Tohoku earthquake, SmartTraveller lists Japan as still fine to visit, but has a sub-note saying "Fukushima area: do not travel" (http://smarttraveller.gov.au/zw-cgi/view/Advice/Japan ). For example, for a tag related to neutron, maybe neutron itself is fine but there might be some special thing about the linuxbridge driver that is important to note.
   Early tags we're starting with should be simple and non-controversial. There is great potential to define more subjective tags, however these should be left until after the first set are completed.
   The lack of a particular tag should not be a barrier to someone using the code