issue triage and github labels

[Brian Grant]

We discussed the issue of how to sustainably triage issues at the dev summit.

Notes:

• https://docs.google.com/document/d/1klHgGFKtSPHGNlG24LDb5-ornBUtZLcUnEjF8XKXDes/edit
  
• https://docs.google.com/document/d/1cJhpjRcXpTmTWQswEfBqSbrfqrawtD9ZlWW30Q3BWv4/edit?ts=5824c735

About 100-250 issues are filed per week:

https://github.com/kubernetes/kubernetes/pulse

Triaging and routing those issues to the right people has been difficult for a single person to sustain, both at the project level and even at the SIG level, since disproportionate numbers of issues are routed to a small number of areas of the project, and area/SIG leads are among the busiest people on the project to impose this burden upon.

Additional background leading up to creation of the ML issue categorizer:

https://docs.google.com/document/d/1V38RVkQe3gRs0qBgFse3hweo4mq0ArtisnNsw5u1C8g/edit#

The automated categorizer hasn't ever been tuned. There are known issues, such as ensuring the categorizer doesn't match on terms in the issue template, such as the word "kubectl".

In general, any new process/tool isn't likely to work perfectly out of the gate. What we need is someone willing to work on the process for a sustained period of time, until it seems workable.

Also, our current set of labels has grown organically over time:

https://github.com/kubernetes/kubernetes/labels

Some specific recommendations:

• We should eliminate unused and little-used labels
• We should rename component/* and dependency/* labels to area/*
• We should create additional area labels for areas listed on https://github.com/kubernetes/kubernetes/wiki
• We should create sig/* labels for each SIG. Where appropriate team/* labels exist (e.g., team/node), they should be renamed. Perhaps we could keep company-related team labels, for the top-10 contributing companies or something like that.
• We should create an explicit mapping of area/* to sig/* labels. Historically, responsibilities have shifted over time (e.g., as new SIGs are created), so learning the most appropriate sig/* labels from past usage doesn't work well, for both bots and humans
• We should create separate github teams for general notifications and for round-robin issue assignment for each SIG. (And maybe for PR notifications, also.)
• With O(100) maintainers, we need a policy about creation of new labels. In particular, I'd like to:
• require approval of new label prefixes from people in top-level OWNERS
• ban creation of new unprefixed labels
• ban creation of labels for individuals
• prefix labels applied to PRs by the bot, such as with prbot/ (perhaps exempting lgtm and approved)
• delete most other unprefixed labels
• encourage SIGs to create labels prefixed by sig/*/ or area/*/
• encourage use of github projects for fine-grain management
• Deprecate non-P0 priorities; use milestones and blocker/non-blocker labels instead

As for initial routing to SIGs, we could try to improve the automatic classifier, and/or round-robin assign new issues among a largish group of people (say, 10-20). 

Additionally, many issues are filed by contributors and by bots. We could require that issues filed by maintainers are pre-routed, that issues filed by org members at least contain text that indicates the appropriate SIG (which we could add to the issue template), and that we have enough information for bots to do the routing at creation time.

[Brian Grant]

On Monday, November 14, 2016 at 4:40:05 PM UTC-8, Brian Grant wrote:

We discussed the issue of how to sustainably triage issues at the dev summit.

Notes:

• https://docs.google.com/document/d/1klHgGFKtSPHGNlG24LDb5-ornBUtZLcUnEjF8XKXDes/edit
  
• https://docs.google.com/document/d/1cJhpjRcXpTmTWQswEfBqSbrfqrawtD9ZlWW30Q3BWv4/edit?ts=5824c735

About 100-250 issues are filed per week:

https://github.com/kubernetes/kubernetes/pulse

Triaging and routing those issues to the right people has been difficult for a single person to sustain, both at the project level and even at the SIG level, since disproportionate numbers of issues are routed to a small number of areas of the project, and area/SIG leads are among the busiest people on the project to impose this burden upon.

Additional background leading up to creation of the ML issue categorizer:

https://docs.google.com/document/d/1V38RVkQe3gRs0qBgFse3hweo4mq0ArtisnNsw5u1C8g/edit#

The automated categorizer hasn't ever been tuned. There are known issues, such as ensuring the categorizer doesn't match on terms in the issue template, such as the word "kubectl".

In general, any new process/tool isn't likely to work perfectly out of the gate. What we need is someone willing to work on the process for a sustained period of time, until it seems workable.

Also, our current set of labels has grown organically over time:

https://github.com/kubernetes/kubernetes/labels

Some specific recommendations:

• We should eliminate unused and little-used labels
• We should rename component/* and dependency/* labels to area/*
• We should create additional area labels for areas listed on https://github.com/kubernetes/kubernetes/wiki
• We should create sig/* labels for each SIG. Where appropriate team/* labels exist (e.g., team/node), they should be renamed. Perhaps we could keep company-related team labels, for the top-10 contributing companies or something like that.

I think the following area/ labels should be converted to sig/ labels:

• area/auth -> sig/auth
• area/autoscaling -> sig/autoscaling (assuming that SIG still exists)
• area/cluster-federation -> sig/federation
• area/cluster-lifecycle -> sig/cluster-lifecycle
• area/networking -> sig/network
• area/performance -> sig/scalability
• area/platform/openstack -> sig/openstack
• area/scheduling -> sig/scheduling
• area/service-catalog -> sig/service-catalog
• area/storage -> sig/storage
• team/CSI API Machinery SIG -> sig/api-machinery
  
• team/node -> sig/node
• team/rktnetes -> sig/rktnetes
• team/sig-aws -> sig/aws
• team/test-infra -> sig/testing
• team/windows -> sig/windows
• team/workloads -> sig/apps

[Justin Santa Barbara]

So this is a bit extreme (and I know it is not entirely correct), but I would like to propose the following:

• We pick a "point person" for each label, and we bulk assign any issue that doesn't have an assignment to that person.  This is probably a bot.
  
• Each point person makes a pass and updates the area where the area is wrong - and then unassigns themselves in that case.  We re-run the person-assign bot to reassign those tasks
• The assignee is not responsible for fixing the issue, but is responsible for driving it to a conclusion.  Or for reassigning that responsibility.
• We turn off the auto-tagger until it no longer reassigns tags that have been removed.  (e.g. https://github.com/kubernetes/kubernetes/issues/35166)
  
• We do manual area assignment until we can get the auto tagger working again
  

I know that this feels like a big amount of work for people, but I started on this on AWS and I actually feel much better for very little time spent.  I consider it the "getting things done" approach - we are currently just letting these issues be a big deal in our minds, but if we use the issue tracker to track them there aren't that many.  There are a few thousand, which is probably a few dozen for each active contributor?  And I believe bgrant still knows all the numbers off by heart.

Our issues contain very valuable information IMO, but I do not believe they will be overwhelming when directed appropriately.  There are obviously a lot of issues on AWS, so I have sought help (and received it) from the storage team on some of the AWS EBS issues, and without that we wouldn't have got it under control.  But we've also made a lot of progress through information in the issues, and there are likely more nuggets in our untriaged issues.  I've certainly found a few easy things that we should address in 1.6 in AWS just this morning (and closed a bunch of issues!)  If there is an area where the issues are overwhelming we need to address that (e.g. the removal of the cluster directory).

Concretely I think we need the following:

1. Buy-in / volunteers for each area
   
2. An auto-assigner bot that assigns unassigned issues by area
   
3. Some form of issue metrics system so we can see whether the system is working
   
4. The autotagger needs to be fixed to not reapply labels
   
5. Volunteers to do manual area assignment until autotagger is back online
   
6. I think we need a way to influence the autotagger so that I can easily add exceptions / logic to the rules (e.g. regex)
   

Consider me a volunteer :-)

Justin

[Ihor Dvoretskyi]

> I think the following area/ labels should be converted to sig/ labels:

• area/auth -> sig/auth
• area/autoscaling -> sig/autoscaling (assuming that SIG still exists)
• area/cluster-federation -> sig/federation
• area/cluster-lifecycle -> sig/cluster-lifecycle
• area/networking -> sig/network
• area/performance -> sig/scalability
• area/platform/openstack -> sig/openstack
• area/scheduling -> sig/scheduling
• area/service-catalog -> sig/service-catalog
• area/storage -> sig/storage
• team/CSI API Machinery SIG -> sig/api-machinery
  
• team/node -> sig/node
• team/rktnetes -> sig/rktnetes
• team/sig-aws -> sig/aws
• team/test-infra -> sig/testing
• team/windows -> sig/windows
• team/workloads -> sig/apps
  

Brian, totally agree with this suggestion. All "area"&"team" labels have to reflect the actual SIG; that is responsible for the specific area. I would suggest having the same "team" labels in the kubernetes/kubernetes repo as we have in the kubernetes/features repo - https://github.com/kubernetes/features/labels.

Let me suggest having this discussion open until the end of the week, collecting the suggestions and making the final decision on Friday EOD - I will convert the labels during the weekend (non-business time for most of the community people).

--
You received this message because you are subscribed to the Google Groups "kubernetes-wg-contribex" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-contribex+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-wg-contribex@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-contribex/79189b58-0510-42d1-9eee-7eea21f76367%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Brian Grant]

On Tuesday, November 15, 2016 at 1:17:24 PM UTC-8, Justin Santa Barbara wrote:

So this is a bit extreme (and I know it is not entirely correct), but I would like to propose the following:

• We pick a "point person" for each label, and we bulk assign any issue that doesn't have an assignment to that person.  This is probably a bot.
  
• Each point person makes a pass and updates the area where the area is wrong - and then unassigns themselves in that case.  We re-run the person-assign bot to reassign those tasks

One person is insufficient for the areas with larger numbers of issues, and I believe we need a group of people even for initial routing, for redundancy if nothing else. I suggest round-robin assignment, and reassignment in the event of a lack of response.

• The assignee is not responsible for fixing the issue, but is responsible for driving it to a conclusion.  Or for reassigning that responsibility.

Or at least for classifying the issue as a feature request or code improvement, which may not be immediately resolved or closed. 

• We turn off the auto-tagger until it no longer reassigns tags that have been removed.  (e.g. https://github.com/kubernetes/kubernetes/issues/35166)
  

I believe it uses the presence of a team/ label to indicate that the issue has been triaged. We'll need to convert this to sig/ labels. 

• We do manual area assignment until we can get the auto tagger working again
  

This was discussed in my first post, but we need to tune the classifier by manually correcting issues and retraining it if it's ever going to work. If feasible, I'd also like to be able to assign low-confidence issues to humans for dispatching. Additionally, I think we could require issues filed by community members to be pre-routed.

I know that this feels like a big amount of work for people, but I started on this on AWS and I actually feel much better for very little time spent.

Our past process was:

• build cop routed all new issues to teams and redirected support issues to stackoverflow (in addition to their other duties: ensuring submit queue is healthy, reverting PRs that broke the build, etc.)
• team TL triaged new issues: requested clarification from author, determined priority, assigned bug fixes, etc.

Problems with the process:

• the initial routing (of 100-250 issues/week) was too much work on top of other duties
• the team-level triage was too much work on top of other duties
• we had to change from notification-driven workflows to polling-based ones since github notifications have become essentially worthless due to their volume
• many issues were routed to the wrong teams
• team responsibilities shifted over time, making old labels incorrect
  
• appropriate teams for bugs were often non-obvious
• not all issues fell under any team's responsibilities (e.g., build issues)
• we didn't have the capacity to address the vast majority of issues

Also discussed in this doc: https://docs.google.com/document/d/1V38RVkQe3gRs0qBgFse3hweo4mq0ArtisnNsw5u1C8g/edit#

 I consider it the "getting things done" approach - we are currently just letting these issues be a big deal in our minds, but if we use the issue tracker to track them there aren't that many.  There are a few thousand, which is probably a few dozen for each active contributor?

I think the hard part is getting the right issues routed to the right contributors, and adequately incentivizing those contributors to actually work on those issues. Lack of progress on auto-assigned test failures is an example of how routing to the wrong person and lack of sufficient priority causes issues to languish. 

 

 And I believe bgrant still knows all the numbers off by heart.

Sadly, I can't keep track of everything that's going on any longer.

 

Our issues contain very valuable information IMO, but I do not believe they will be overwhelming when directed appropriately.  There are obviously a lot of issues on AWS, so I have sought help (and received it) from the storage team on some of the AWS EBS issues, and without that we wouldn't have got it under control.  But we've also made a lot of progress through information in the issues, and there are likely more nuggets in our untriaged issues.  I've certainly found a few easy things that we should address in 1.6 in AWS just this morning (and closed a bunch of issues!)  If there is an area where the issues are overwhelming we need to address that (e.g. the removal of the cluster directory).

Concretely I think we need the following:

1. Buy-in / volunteers for each area
   
2. An auto-assigner bot that assigns unassigned issues by area
   
3. Some form of issue metrics system so we can see whether the system is working
   

We need metrics for the ongoing OWNERS work, also, so that we can tune the PR auto-assigner, as well as to identify unresponsive and/or overloaded reviewers. 

2. The autotagger needs to be fixed to not reapply labels
   
3. Volunteers to do manual area assignment until autotagger is back online
   
4. I think we need a way to influence the autotagger so that I can easily add exceptions / logic to the rules (e.g. regex)
   

Consider me a volunteer :-)

Thanks. 

[Brian Grant]

On Tuesday, November 15, 2016 at 1:49:55 PM UTC-8, Ihor Dvoretskyi wrote:

> I think the following area/ labels should be converted to sig/ labels:

• area/auth -> sig/auth
• area/autoscaling -> sig/autoscaling (assuming that SIG still exists)
• area/cluster-federation -> sig/federation
• area/cluster-lifecycle -> sig/cluster-lifecycle
• area/networking -> sig/network
• area/performance -> sig/scalability
• area/platform/openstack -> sig/openstack
• area/scheduling -> sig/scheduling
• area/service-catalog -> sig/service-catalog
• area/storage -> sig/storage
• team/CSI API Machinery SIG -> sig/api-machinery
  
• team/node -> sig/node
• team/rktnetes -> sig/rktnetes
• team/sig-aws -> sig/aws
• team/test-infra -> sig/testing

Refinement: Jeff suggested changing team/test-infra to area/test-infra, to distinguish it from area/test, and we should just create a new sig/testing label. 

• team/windows -> sig/windows
• team/workloads -> sig/apps
  

Brian, totally agree with this suggestion. All "area"&"team" labels have to reflect the actual SIG; that is responsible for the specific area. I would suggest having the same "team" labels in the kubernetes/kubernetes repo as we have in the kubernetes/features repo - https://github.com/kubernetes/features/labels.

I prefer the sig/* form to the team/* form. Eventually all parts of the project need to be covered by community SIGs rather than teams from individual contributing companies.

 

Let me suggest having this discussion open until the end of the week, collecting the suggestions and making the final decision on Friday EOD - I will convert the labels during the weekend (non-business time for most of the community people).

Please don't change any of the labels yet. The auto-assigner bot currently depends on the current labels, and we also have to update the automation that copies the labels to each repo:

https://github.com/kubernetes/kubernetes/blob/master/labels.yaml

https://github.com/kubernetes/contrib/blob/master/labels.yaml

https://github.com/kubernetes/kubernetes.github.io/blob/master/labels.yaml

[Brian Grant]

We've disabled the auto-assigner.

Once we settle on which labels we want, we'll need to update the labels.yaml files and document how they should be used.

https://github.com/kubernetes/kubernetes/issues/34255

[David Oppenheimer]

Sorry I didn't have time to read this whole thread but I want to vote strongly against automatically assigning issues and PRs. PRs should only be assigned upon explicit acceptance by the individual (or self-assigning it to themself).

Adding a label for an area/team/whatever, @ mentioning someone, etc. is all fine. But I have 28 code reviews assigned to me right now and I expect I will review zero of them in the remainder 2016.

Assigning something to someone does not cause them to work on it any sooner, and it gives a misleading signal.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-contribex+unsubscr...@googlegroups.com.

To post to this group, send email to kubernetes-wg-contribex@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-contribex/79189b58-0510-42d1-9eee-7eea21f76367%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "kubernetes-wg-contribex" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-contribex+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-wg-contribex@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-contribex/ba4c196d-da00-4aeb-acbf-4668f8537306%40googlegroups.com.

[Daniel Smith]

I also want to toss a -1 for assigning to people for the purpose of triage, as people will lose the things they are actually working on in the noise.

Instead, consider making a github user "triage-me" and assign to them. Triagers can look at the list of issues assigned to that account.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-contribex/ba4c196d-da00-4aeb-acbf-4668f8537306%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "kubernetes-PM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-pm+unsubscribe@googlegroups.com.
To post to this group, send email to kubern...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-pm/CAOU1bzfYqZx6-fmdriWZVEkg9ZnPP_fZ1fFovDwYLf0XzOSy9g%40mail.gmail.com.

[Justin Santa Barbara]

I think I jumped straight into mechanics without stating my reasoning - sorry.

I believe the core problem that we have now is that we don't have anyone who is responsible for getting issues under control, yet it is too much work for one person.  I propose as solution that every issue should have someone responsible for it at all times.

Whether we do that by assignment in github or not I don't mind; it makes sense to me, but I think there are many ways that people work with github.  If we accurately label issues with teams, I think that would work also, as long as each team has a way of making sure that someone is driving each issue towards closure.

I don't believe this is a complete solution - I expect we'll need e.g. a "backlog" or "ideas" label.  But I think that will arise naturally, driven by the people that own the issues. 

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-contribex+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-contribex/79189b58-0510-42d1-9eee-7eea21f76367%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "kubernetes-wg-contribex" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-contribex+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-contribex/ba4c196d-da00-4aeb-acbf-4668f8537306%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "kubernetes-PM" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-p...@googlegroups.com.

[Brian Grant]

On Wed, Nov 16, 2016 at 10:18 PM, Brian Grant <brian...@google.com> wrote:

We've disabled the auto-assigner.

Once we settle on which labels we want, we'll need to update the labels.yaml files and document how they should be used.

We'll disable the label-creation feature today. We'll need to manually (or maybe one of the github CLIs can do it?) rename the labels in order to preserve label assignments, update the labels.yaml files, and then turn the automation on again. Entirely new labels could be created via labels.yaml, however.

 

https://github.com/kubernetes/kubernetes/issues/34255

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-contribex+unsubscr...@googlegroups.com.

To post to this group, send email to kubernetes-wg-contribex@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-contribex/79189b58-0510-42d1-9eee-7eea21f76367%40googlegroups.com.

[Brian Grant]

On Thu, Nov 17, 2016 at 1:35 AM, David Oppenheimer <davi...@google.com> wrote:

Sorry I didn't have time to read this whole thread but I want to vote strongly against automatically assigning issues and PRs. PRs should only be assigned upon explicit acceptance by the individual (or self-assigning it to themself). 

Adding a label for an area/team/whatever, @ mentioning someone, etc. is all fine. But I have 28 code reviews assigned to me right now and I expect I will review zero of them in the remainder 2016.

Assigning something to someone does not cause them to work on it any sooner, and it gives a misleading signal.

You're saying we should stop auto-assigning PRs? What alternative do you suggest?

Will respond about issue assignment in response to Daniel. 

[Brian Grant]

On Thu, Nov 17, 2016 at 10:17 AM, Daniel Smith <dbs...@google.com> wrote:

I also want to toss a -1 for assigning to people for the purpose of triage, as people will lose the things they are actually working on in the noise.

I'm not proposing that we assign issues to random people, nor to maintainers, nor to SIG/project/team leads (in general). We need dedicated groups of people for triaging issues. We're beyond the scale where the triage for the whole project can be done by a single person.

Instead, consider making a github user "triage-me" and assign to them. Triagers can look at the list of issues assigned to that account.

I don't see how that would help parallelize the effort.

[David Oppenheimer]

On Thu, Nov 17, 2016 at 11:44 AM, Brian Grant <brian...@google.com> wrote:

On Thu, Nov 17, 2016 at 1:35 AM, David Oppenheimer <davi...@google.com> wrote:

Sorry I didn't have time to read this whole thread but I want to vote strongly against automatically assigning issues and PRs. PRs should only be assigned upon explicit acceptance by the individual (or self-assigning it to themself). 

Adding a label for an area/team/whatever, @ mentioning someone, etc. is all fine. But I have 28 code reviews assigned to me right now and I expect I will review zero of them in the remainder 2016.

Assigning something to someone does not cause them to work on it any sooner, and it gives a misleading signal.

You're saying we should stop auto-assigning PRs? What alternative do you suggest?

Assign to a SIG and @ mention someone who should review it but don't assign it to them until they ack.

[David Oppenheimer]

On Thu, Nov 17, 2016 at 11:47 AM, David Oppenheimer <davi...@google.com> wrote:

On Thu, Nov 17, 2016 at 11:44 AM, Brian Grant <brian...@google.com> wrote:

On Thu, Nov 17, 2016 at 1:35 AM, David Oppenheimer <davi...@google.com> wrote:

Sorry I didn't have time to read this whole thread but I want to vote strongly against automatically assigning issues and PRs. PRs should only be assigned upon explicit acceptance by the individual (or self-assigning it to themself). 

Adding a label for an area/team/whatever, @ mentioning someone, etc. is all fine. But I have 28 code reviews assigned to me right now and I expect I will review zero of them in the remainder 2016.

Assigning something to someone does not cause them to work on it any sooner, and it gives a misleading signal.

You're saying we should stop auto-assigning PRs? What alternative do you suggest?

Assign to a SIG and @ mention someone who should review it but don't assign it to them until they ack.

To clarify: apply a SIG label and @ mention someone who should review it but don't assign it to them until they ack.

[Brian Grant]

On Thu, Nov 17, 2016 at 11:47 AM, 'David Oppenheimer' via kubernetes-wg-contribex <kubernetes-...@googlegroups.com> wrote:

On Thu, Nov 17, 2016 at 11:44 AM, Brian Grant <brian...@google.com> wrote:

On Thu, Nov 17, 2016 at 1:35 AM, David Oppenheimer <davi...@google.com> wrote:

Sorry I didn't have time to read this whole thread but I want to vote strongly against automatically assigning issues and PRs. PRs should only be assigned upon explicit acceptance by the individual (or self-assigning it to themself). 

Adding a label for an area/team/whatever, @ mentioning someone, etc. is all fine. But I have 28 code reviews assigned to me right now and I expect I will review zero of them in the remainder 2016.

Assigning something to someone does not cause them to work on it any sooner, and it gives a misleading signal.

You're saying we should stop auto-assigning PRs? What alternative do you suggest?

Assign to a SIG and @ mention someone who should review it but don't assign it to them until they ack.

Mentions aren't going to work, IMO. There is no reasonable way for me to search PRs I've been mentioned on (just via bigquery, maybe), and certainly not ones that haven't been picked up by someone else. 

I agree we need an ack/nack mechanism, as well as dashboards to provide visibility into assignment imbalances, a larger reviewer pool, and a multi-stage review process. We've been working on improvements to PR workflow in contrib-ex. Let's not use this thread for discussing PR workflow further. I'd like to keep it focused on issue management.

I also started another thread about splitting notification threads, which may help with issue management.

 

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-contribex+unsub...@googlegroups.com.

To post to this group, send email to kubernetes-wg-contribex@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-contribex/CAOU1bzcP9R7fT-zwU3WaQTQf%3DcsarU%3DSoxMWOYOjTH2qZFf1pg%40mail.gmail.com.

[David Oppenheimer]

On Thu, Nov 17, 2016 at 11:52 AM, Brian Grant <brian...@google.com> wrote:

On Thu, Nov 17, 2016 at 11:47 AM, 'David Oppenheimer' via kubernetes-wg-contribex <kubernetes-wg-contribex@googlegroups.com> wrote:

On Thu, Nov 17, 2016 at 11:44 AM, Brian Grant <brian...@google.com> wrote:

On Thu, Nov 17, 2016 at 1:35 AM, David Oppenheimer <davi...@google.com> wrote:

Sorry I didn't have time to read this whole thread but I want to vote strongly against automatically assigning issues and PRs. PRs should only be assigned upon explicit acceptance by the individual (or self-assigning it to themself). 

Adding a label for an area/team/whatever, @ mentioning someone, etc. is all fine. But I have 28 code reviews assigned to me right now and I expect I will review zero of them in the remainder 2016.

Assigning something to someone does not cause them to work on it any sooner, and it gives a misleading signal.

You're saying we should stop auto-assigning PRs? What alternative do you suggest?

Assign to a SIG and @ mention someone who should review it but don't assign it to them until they ack.

Mentions aren't going to work, IMO. There is no reasonable way for me to search PRs I've been mentioned on (just via bigquery, maybe), and certainly not ones that haven't been picked up by someone else. 

mentions:davidopp no:assignee 

 

[Brian Grant]

On Thu, Nov 17, 2016 at 12:19 PM, David Oppenheimer <davi...@google.com> wrote:

On Thu, Nov 17, 2016 at 11:52 AM, Brian Grant <brian...@google.com> wrote:

On Thu, Nov 17, 2016 at 11:47 AM, 'David Oppenheimer' via kubernetes-wg-contribex <kubernetes-wg-contribex@googlegroups.com> wrote:

On Thu, Nov 17, 2016 at 11:44 AM, Brian Grant <brian...@google.com> wrote:

On Thu, Nov 17, 2016 at 1:35 AM, David Oppenheimer <davi...@google.com> wrote:

Sorry I didn't have time to read this whole thread but I want to vote strongly against automatically assigning issues and PRs. PRs should only be assigned upon explicit acceptance by the individual (or self-assigning it to themself). 

Adding a label for an area/team/whatever, @ mentioning someone, etc. is all fine. But I have 28 code reviews assigned to me right now and I expect I will review zero of them in the remainder 2016.

Assigning something to someone does not cause them to work on it any sooner, and it gives a misleading signal.

You're saying we should stop auto-assigning PRs? What alternative do you suggest?

Assign to a SIG and @ mention someone who should review it but don't assign it to them until they ack.

Mentions aren't going to work, IMO. There is no reasonable way for me to search PRs I've been mentioned on (just via bigquery, maybe), and certainly not ones that haven't been picked up by someone else. 

mentions:davidopp no:assignee 

I always get a 500 response on this query for my github id.

[David Oppenheimer]

https://github.com/kubernetes/kubernetes/pulls?utf8=%E2%9C%93&q=is%3Apr%20is%3Aopen%20mentions%3Adavidopp%20-assignee

works for me

[Brian Grant]

On Thu, Nov 17, 2016 at 10:37 AM, Justin Santa Barbara <jus...@fathomdb.com> wrote:

I think I jumped straight into mechanics without stating my reasoning - sorry.

I believe the core problem that we have now is that we don't have anyone who is responsible for getting issues under control, yet it is too much work for one person.  I propose as solution that every issue should have someone responsible for it at all times.

We need to handle different types of issues differently. 

I don't want issues assigned when no near-term work is planned, but I also don't want to immediately close feature requests, cleanup proposals, etc. that nobody is working on in the current release. 

 

Whether we do that by assignment in github or not I don't mind; it makes sense to me, but I think there are many ways that people work with github.  If we accurately label issues with teams, I think that would work also, as long as each team has a way of making sure that someone is driving each issue towards closure.

We need metrics on open issues by SIG, by type (bug, feature, etc.), and maybe by milestone -- at least how many and how long they've been open (at multiple percentiles).

Parts of the project that don't currently fall into any SIG (e.g., the build) will need to find a home.

 

I don't believe this is a complete solution - I expect we'll need e.g. a "backlog" or "ideas" label.

Yes. Features, debt, proposals, etc., as per the notification thread.

 

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-contribex+unsubscr...@googlegroups.com.

To post to this group, send email to kubernetes-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-contribex/79189b58-0510-42d1-9eee-7eea21f76367%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "kubernetes-wg-contribex" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-contribex+unsubscr...@googlegroups.com.

To post to this group, send email to kubernetes-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-contribex/ba4c196d-da00-4aeb-acbf-4668f8537306%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "kubernetes-PM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-p...@googlegroups.com.
To post to this group, send email to kubern...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-pm/CAOU1bzfYqZx6-fmdriWZVEkg9ZnPP_fZ1fFovDwYLf0XzOSy9g%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "kubernetes-wg-contribex" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-contribex+unsub...@googlegroups.com.

To post to this group, send email to kubernetes-wg-contribex@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-contribex/5704638b-d5cb-4162-91b1-b4b0c6a56367%40googlegroups.com.