Difference between revisions of "Operations/Tags"
(→Previous Meetings) |
(→What are Tags?) |
||
Line 50: | Line 50: | ||
==What are Tags?== | ==What are Tags?== | ||
+ | * Explained at a high level in http://ttx.re/the-way-forward.html | ||
* 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. | * 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 | * Particularly, any tag that is not a 'perfect' result should have a bug report or some other information on steps to fix it |
Revision as of 00:30, 22 May 2015
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 providing useful information about OpenStack software projects.
Activities
- 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.
Volunteers
- 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?
- Explained at a high level in http://ttx.re/the-way-forward.html
- 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