Collect stats about issues to triage.

[jlewi]

• Use variables with the query to fetch issues

• Add a new download function to download issues

• Write issues to files using multi-line pretty printed json; write the items
  as an array of items.

• To compute stats we need to fetch information about the times at which
  various events occurred so we can determine when an issue was triaged.

• We can then plot the number of untriaged issues as a function of time.

Related to kubeflow/community#280

---

This change is 

[review-notebook-app]

Check out this pull request on ReviewNB: https://app.reviewnb.com/kubeflow/code-intelligence/pull/32

You'll be able to see notebook diffs and discuss changes. Powered by ReviewNB.

[jlewi]

/assign @abcdefgs0324
/assign @hamelsmu

[jlewi]

@abcdefgs0324 @hamelsmu ping; could one of you take a look at this please.

[hamelsmu]

Wow I never got the first ping .... it was buried in many other notifications. I don't know how you deal with this as a maintainer

[hamelsmu]

@jlewi can you annotate the notebook a bit more with some prose? specifically triage.ipynb

Example:

• Want to know what you are intending to do with the Kanban board
• Want to know what you are expecting to see with the line plot and your observations or what it means to you
• A preview of some of the data you are pulling or some descriptive statistics that give some color of what the data is

[jlewi]

@hamelsmu I think I answered your first 2 questions;

For your last

A preview of some of the data you are pulling or some descriptive statistics that give some color of what the data is

I wasn't quite sure what data and statistics to illustrate. The raw data is GitHub issues. We then preprocess this to compute a pandas dataframe with data about when it was opened and when it was triaged (if it was triaged).

Any suggestions?

[hamelsmu]

@jlewi its not necessary anymore, there is enough context from the rest of the updated markdown that I understand what is going on now.

One nit is that you have INFO level logging spamming the notebook, otherwise:
/lgtm

I guess you could use this graph on how Issue Label Bot helped start to gain control over issues?

[hamelsmu]

@jlewi one more nit, it might be useful if you include the business logic of what counts as triage in the notebook from kubeflow/community#280

Just copy and paste the below from that issue

Here's my initial proposal

The following needs to be true for an issue to be considered triaged

It has one the labels ("bug", "question", "enhancement")
It has a priority
If its P0/P1 it should be added to a kanban board
It has at least one "area" label
I will create a simple script that iterates over our issues and does the following

Adds untriaged issues to a project used for triaging issues

I think a project is better than a label because we can potentially use cards to keep track of an issue; e.g. if there is some question about an issue and it needs to be discussed at the community meeting
Add a comment on the issue explaining what criterion are missing for the issue to be considered triaged

[hamelsmu]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: hamelsmu

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [hamelsmu]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment