Re: Issue triage in GitHub, and backlog

0 views
Skip to first unread message

Brian Grant

unread,
Feb 22, 2019, 10:18:31 AM2/22/19
to Sahdev Zala, Jordan Liggitt, Federico Bongiovanni, kubernetes-PM, Tim Hockin, kubernetes-sig-contribex, kubernetes-sig-leads

On Fri, Feb 22, 2019 at 6:59 AM Sahdev Zala <sahdev...@gmail.com> wrote:

Hello Tim and all,


I don’t have a better approach but some thoughts:

  • We have a triage specific labels https://github.com/kubernetes/kubernetes/labels?utf8=%E2%9C%93&q=triage and we should use them as go through the issue backlog. Hopefully, many of the issues from backlog will move out of SIG-net to a more appropriate place as they might be a support question or mislabeled in the first place as you noticed. 
  • Since most issues usually fall under few major SIGs, it would be great if SIG-net and other major SIGs create a triage role in the SIG who primarily try not build up a big backlog in the first place or coordinate efforts to handle backlog as needed. 
  • We are creating a small team in the ContribEx to help with the issue triage as a Triage Captain role (Paris, Nikhita and myself so far in the team, I think). Paris and Nikhita can tell more about the role but I am mentioning this here for reference. Also, as this team starts their brainstorming, they possibly can learn and provide some help with the case you mentioned. 
  • Hopefully, as SIG-net start work on backlog exercise, fejta-bot will close few or more issues :). (I like the auto-closing of inactive issues and I would like to discuss more on reducing the overall time for auto-closing issues, but that’s something we can discuss separately toward future triage process improvements.)
Thanks! 

Regards,
Sahdev

On Thu, Feb 21, 2019 at 6:36 PM 'Tim Hockin' via kubernetes-sig-leads <kubernetes...@googlegroups.com> wrote:
Hey all,

SIG-net wants to finally undertake issue triage in GitHub.  We have a
backlog.  I know for a fact there are issues tagged sig-net that are
not ours and that there are issues not tagged as sig-net that are.

Before I undertake triage of several hundred issues, I wanted to see
what everyone else is doing?  Do we have decent approaches to getting
through this backlog?  Especially if it has to be done in multiple
sessions.

The naive approach would be to open GitHub's UI, search for all the
terms that might be network-related, label them as "maybe-net", and
then do a first pass just for in/out decisions.  Then label everything
that is "in" as "untriaged" and go through that list over the course
of several sessions.

That sounds painful.  Do we have better approaches?

Tim

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-leads" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-l...@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-sig-leads/CAO_RewY2zUitW%3DHDckoANQHRMKDq%3DBdcLneM8pZ2SY_927N9KA%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-sig-contribex" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-con...@googlegroups.com.
To post to this group, send email to kubernetes-s...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-contribex/CAB_1j%3Di5X%3DqBVM9OOFzji%3DJQ3Kn_uCB2NGNzSvm0F2GSdjU6jw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages