karelz / githubissues Goto Github PK

So that you don't have to read all alerts one by one when you come back from vacation

Area labels or queries in general differ between repos. Allow them to be specific per-repo.

Each issue should have:

1. Area label (exactly 1)
2. Issue type label (exactly 1)
3. Milestone set

Bonus:
4. How many issues don't have "up for grabs"
5. How many issues marked as "up for grabs" don't have MS employee reply (assuming it contains explanation what to do next)

Bonus 2:
6. Stale Design Discussions
7. Issues assigned to community / anyone for long time without any progress

Automatically set:

• Milestone (based on base branch)
• Owners based on area owner label

Create scripts, and saved data (at 8-9am every day) for:

• Daily bug status reports - \\clrmain\public\GitHubIssuesTracker\Scripts\Reports\CoreFX_CoreCLR_CoreSetup\GenerateReport.bat
• Weekly untriaged reports - \\clrmain\public\GitHubIssuesTracker\Scripts\Untriaged\UntriagedReport_SendEmails.bat

Tool to tag new issues and issues moved between alert-queries. Has to be manually removed when triaged ...
Unclear if we truly want it

Depends on #60

• Add scripts on clrmain to do catchup reports for particular time frame
• Change 'alerts' emails report template to point to the script with how-to

Service run by Infra team.

Support issue filters per repo to enable partial repo reports.

Also, add prefix to textual query

We check that there is at most 1 area path, we need special report for 0 area paths.

Create summary of a set of data points to capture issues which were created and gone in the meantime ...

Motivation: Easier import into XLSX

Replaces non-linked tables in 'report'.

New (optional) option:

• /out_csv my_file_prefix

Potential settings:

• 1hr (today's default)
• 4hr/24hr
• list of specific hours (e.g. 2x per day setting)

Not covered: Quiet days (weekends)

• 1. Replace all hardcoded links to issues/queries - corefx (fixed in #50)
• 2. Replace repo in the HTML template (fixed in #50)
• 3. Report on multiple issue files (from corefx and coreclr repos) (fixed in #50)
• 4. Set up downloading coreclr data - depends on #3

Report on all 2.0 issues across multiple repos. Separate it by teams.

Note: Add support for empty query (always returns true).

Add also Milestone column (or something like that)

Motivation: All 2.0 bugs across multiple repos (CoreFX, CoreCLR)
Summary breakdown to areas/alert queries (with number of issues per area)

• Defined by list of areas/alert queries

One email or HTML (we can copy-paste it manually)

Send weekly report with all issues in area which has not been answered by MS employee (or area owner - should it be a config?) for last ~3 days.

Bonus: also for closed issues

Requires these transforms on Expression.Simplified/Expression.Normalized:

• ExpressionMultiRepo has to be able to combine 2 (like ExpressionNot)
• ExpressionMultiRepo has to bubble up in ExpressionAnd and ExpressionOr

Notes:

• Rename Expression.Simplified to Expression.Normalized
• Hint: For Expression.Copy use Expression.Normalized

The hard-coded queries for columns should be defined via config XML.

Queries with OR (i.e. GetGitHubUrl() == null) will not breakdown into subqueries across multiple repos.
Allow further breakdown.

To enable pulling more data from GitHub (may be required for multi-repo support)

• Add the tool and data on clrmain
• Add scripts to run the reports on latest data
  1. 'untriaged' report
  2. 'query' report
  3. 'report' report
• Change the report templates to point to the tool
  1. Untriaged - how to rerun report on latest data

Motivation: Useful for tracking work/progress per team/organization

Infrastructure (CoreCLR) - no milestone query has 0 without link.

Create samples and docs for usage on GitHub

The weekly digest (#4) would ideally cover also closed issues.

We need to find a way how to query only closed issues which have been commented in last X days.

Move the hardcoded values added in #13 to separate config files.

1. Issues assigned to community / anyone for long time without any progress

• Enables per-user configuration (#7 and #8) via PRs
• Distributed addition of new alerts

Advanced info in untriaged report:

1. How many issues don't have "up-for-grabs"
2. How many issues marked as "up-for-grabs" don't have any MS employee reply (assuming it contains explanation what to do next)

Allow configuration to be per-user (all alerts), or to be specific for a specific alert & user combo,

Useful to exclude some queries from weekly untriaged notices, or in definition of repo owners vs. non-owners.

Great UI: https://octobox.io/ ... could we piggyback on it?
Maybe inject another source of notifications (based on queries and settings like label/milestone changes per query)?

It would also allow us to enable notifications for all issues in your queries, without explicitly subscribing to the issues (which is pain).

Additional ideas:

• Team per-repo queries (for people with write permissions)
• Personal queries
• Option to monitor any label/milestone changes in a query

GitHub issue tracking in insufficient for daily developer job on large repo like CoreFX, CoreCLR, Roslyn, VSCode, etc.

GitHub provides:

• Notifications about comments (incl. Closing) for issues you subscribed to.
• Notifications about comments where you are mentioned explicitly.
• Unusable for large repos: Notifications for all issues in the repo = madness, no one uses that

Missing features:

1. Notifications about new issues/PRs in your area -- supplemented by email alerts from command line tool
   • Scenario: As area owner, you want to know which new issues were 'sent' to your area, which new PRs are in your area, so that you can participate in triage/code review.
   • Still not ideal: No customization which notifications to get. No per-user/alert cadence customization. No catch up after vacation.
   • Note: Even external folks today want this, they work around it today by sending notifications to Twitter, e.g. @corefxissues and @dotnetissues -- everyone tools around these things
2. Notifications about comments in your area (when you didn't manually subscribe to the issue)
   • Scenario: As area owner, you want to be auto-subscribed to all issues which are currently in your area(s), so that you don't have to do it manually. Bonus: Works also on 'Closed' issues when customers start commenting and asking on them (it happens quite often).
3. Notifications about label/milestone changes for issues in your area.
   • Scenario: As key area owner, you want to make sure the bugs don't get triaged out/marked in harmful way silently, without you knowing.
4. Notifications about label/milestone changes for issues you are subscribed to.
   • Scenario: As interested person, you want to make sure the bugs don't get triaged out/marked in harmful way silently, without you knowing.
5. Notifications about PRs which touch files/directories you monitor
   • Scenario: As owner of source code, you want to know when anyone makes changes to them.
6. Option to choose which notifications are via web UI and/or email alerts (like on GitHub)

Most of the missing features [2], [3] [4] and [5] are not smoothly doable in current form of the alerts tool. The tool reached its limits.
We need to invest in new tooling (2.0) ideally with web-based UI, similar to OWA email and https://octobox.io. More details on architecture and requirements are here: #9

Similar requirements are for any large repo - VSCode, CoreCLR, Roslyn, Google repos, etc. Everyone creates their own one-off half-baked tooling. It would be nice to habe just one which works for all (open source even).

Example: is:issue is:open milestone:2.0.0 (label:area-System.Data OR label:area-System.Data.SqlClient)

Solution: Normalize should create proper DNF form. Or recognize the pattern.

Motivation:

• To read older data snapshots for reports
• To compensate for repos which are not (or can't) migrate to unified labels

Bonus: Scope renaming to specific repo (repo attribute)

Benefits from DNF form in #42

Motivation: Old data form dotnet/wcf and dotnet/cli repos