{"action":"created","issue":{"url":"https://api.github.com/repos/kubernetes/kubernetes/issues/18780","labels_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/18780/labels{/name}","comments_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/18780/comments","events_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/18780/events","html_url":"https://github.com/kubernetes/kubernetes/issues/18780","id":122588786,"number":18780,"title":"Proposal: Split issue Priority into Importance and Urgency","user":{"login":"quinton-hoole","id":10390785,"avatar_url":"https://avatars.githubusercontent.com/u/10390785?v=3","gravatar_id":"","url":"https://api.github.com/users/quinton-hoole","html_url":"https://github.com/quinton-hoole","followers_url":"https://api.github.com/users/quinton-hoole/followers","following_url":"https://api.github.com/users/quinton-hoole/following{/other_user}","gists_url":"https://api.github.com/users/quinton-hoole/gists{/gist_id}","starred_url":"https://api.github.com/users/quinton-hoole/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/quinton-hoole/subscriptions","organizations_url":"https://api.github.com/users/quinton-hoole/orgs","repos_url":"https://api.github.com/users/quinton-hoole/repos","events_url":"https://api.github.com/users/quinton-hoole/events{/privacy}","received_events_url":"https://api.github.com/users/quinton-hoole/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/kubernetes/kubernetes/labels/priority/P2","name":"priority/P2","color":"fbca04"},{"url":"https://api.github.com/repos/kubernetes/kubernetes/labels/team/control-plane","name":"team/control-plane","color":"d2b48c"}],"state":"open","locked":false,"assignee":{"login":"goltermann","id":9358478,"avatar_url":"https://avatars.githubusercontent.com/u/9358478?v=3","gravatar_id":"","url":"https://api.github.com/users/goltermann","html_url":"https://github.com/goltermann","followers_url":"https://api.github.com/users/goltermann/followers","following_url":"https://api.github.com/users/goltermann/following{/other_user}","gists_url":"https://api.github.com/users/goltermann/gists{/gist_id}","starred_url":"https://api.github.com/users/goltermann/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/goltermann/subscriptions","organizations_url":"https://api.github.com/users/goltermann/orgs","repos_url":"https://api.github.com/users/goltermann/repos","events_url":"https://api.github.com/users/goltermann/events{/privacy}","received_events_url":"https://api.github.com/users/goltermann/received_events","type":"User","site_admin":false},"milestone":null,"comments":14,"created_at":"2015-12-16T19:56:54Z","updated_at":"2016-01-29T17:25:00Z","closed_at":null,"body":"cc @thockin @goltermann @bgrant0607 @smarterclayton\r\n \r\nStatus Quo\r\n=========\r\nCurrently we apply a single **Priority** label to every issue, and (somewhat inconsistently) use that as a work queue mechanism for the project.  Each person in theory tries to work on a priority/P0 issue, and if there are none of those, or they're all already being worked on, or the person does not have the required skills to work on any of the P0 issues, they try to work on a P1 issue, P2 issue, etc.\r\n\r\nProblems with this approach\r\n======================\r\nThe core problem with that approach is that the two orthogonal concepts of **Urgency** (how soon we'd like something done), and **Importance** (how important we think it is in the long term that something gets done) are munged together into a single **Priority** value, and in the process we lose a very important signal.  \r\n\r\nMore specifically, without explicit steps to avoid this, it becomes too easy to focus too much attention on supposedly urgent issues and not enough on truly important, but less urgent issues.  Sometimes a similar distinction is made between **tactical** and **strategic** work.\r\n\r\nThis phenomenon has been well documented elsewhere, and is pretty main-stream thinking in management science, e.g. [Covey's Time Management Grid](http://www.usgs.gov/humancapital/documents/TimeManagementGrid.pdf).\r\n\r\nAnother practical problem with a combined **Priority** value is that it tends to be more volatile than the the individual **Importance** and **Urgency** values (when we get time to work on a P2 issue, it becomes a P1 issue. When a P1 issue starts blocking other important stuff like merge-bot it becomes a P0 issue etc, etc).  So priority values need to be updated a lot, and easily become inaccurate over time.  So while the Priority method involves fewer labels, and is therefore theoretically easier to understand, and less work to maintain, in practise people get very confused by it (is this thing a high priority because it's urgent, or because it's important?  Why are you working on this thing that is not a top priority?  Because we think it's strategically important. etc).  And they spend a lot of time prioritizing and re-prioritizing things, rather than getting things done.\r\n\r\nProposed Alternative\r\n=================\r\nAssign independent **Importance** and **Urgency** values to each issue.  This places every issue in one of 4 quadrants:\r\n\r\n- **Quadrant 1: Import and Urgent** - clearly these should be worked on in preference to all else.  If we apply enough effort to important stuff in advance of it becoming urgent, it tends not to end up in this quadrant.  In a happy world this quadrant is empty.\r\n- **Quadrant 2: Important but not Urgent** - this is the stuff that often doesn't get done, and causes big problems down the line.  Make sure that we do it in preference to the stuff below wherever practical.\r\n- **Quadrant 3: Urgent but not Important** - time-pressured distractions.  These are often fallout from not doing enough important stuff in quadrant 2 above.  \r\n- **Quadrant 4: Not Important and not Urgent** - just ignore this stuff - it's of low value.\r\n\r\nIn practise I think that we need more than binary values for Importance and urgency.  A scale of 0..3 as we use for priorities seems sensible, although we could possibly reduce this to 0..2.\r\n  \r\nMigration Plan\r\n===========\r\nGiven the number of issues that we already have that have a priority label assigned to them, it could be a real pain to have to manually apply a the proposed new Importance and Urgency labels to them instead (and deprecate the Priority labels). But there is a potential short-cut as follows:\r\n\r\n1. Use the existing priority label to automatically assign an Importance label to each issue.  So high priority items become important items in the new world.\r\n1. Assign low urgency labels to everything by default.\r\n\r\nOver time, new issues will get the right labels, and old issues will have their importance and urgency labels corrected (e.g. increase an issue's importance or urgency to get it into a release).\r\n\r\nThoughts? Unless anyone has objections, I'll implement it after appropriate consultation.\r\n\r\n\r\n \r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/kubernetes/kubernetes/issues/comments/176871729","html_url":"https://github.com/kubernetes/kubernetes/issues/18780#issuecomment-176871729","issue_url":"https://api.github.com/repos/kubernetes/kubernetes/issues/18780","id":176871729,"user":{"login":"thockin","id":5595220,"avatar_url":"https://avatars.githubusercontent.com/u/5595220?v=3","gravatar_id":"","url":"https://api.github.com/users/thockin","html_url":"https://github.com/thockin","followers_url":"https://api.github.com/users/thockin/followers","following_url":"https://api.github.com/users/thockin/following{/other_user}","gists_url":"https://api.github.com/users/thockin/gists{/gist_id}","starred_url":"https://api.github.com/users/thockin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/thockin/subscriptions","organizations_url":"https://api.github.com/users/thockin/orgs","repos_url":"https://api.github.com/users/thockin/repos","events_url":"https://api.github.com/users/thockin/events{/privacy}","received_events_url":"https://api.github.com/users/thockin/received_events","type":"User","site_admin":false},"created_at":"2016-01-29T17:25:00Z","updated_at":"2016-01-29T17:25:00Z","body":"That was really my point.  If we use milestones as an urgency indicator,\nthe existing P0..P3 labels become a spectrum of importance.  Maybe it's too\ngranular, but I actually get value from P0 vs P1 vs P2.  I could lose P3\n\nOn Fri, Jan 29, 2016 at 9:17 AM, Brian Grant <notifications@github.com>\nwrote:\n\n> I am not in favor of an urgency label. Milestones should be used to\n> reflect urgency.\n>\n> Feel free to rename priority labels to importance, but that's shuffling\n> deck chairs, IMO.\n>\n> —\n> Reply to this email directly or view it on GitHub\n> <https://github.com/kubernetes/kubernetes/issues/18780#issuecomment-176868740>\n> .\n>\n"}}