Skip to content

2024 Issue/PR Grooming - review, categorization, assignment #235576

New issue
Jump to bottom
New issue
Jump to bottom
Open
Open
2024 Issue/PR Grooming - review, categorization, assignment#235576
Assignees
joaomorenorebornixkarthiknadigkieferrmalexdimasbatten
Labels
plan-itemVS Code - planned item for upcoming
@rebornix

Description

@rebornix
rebornix
opened on Dec 8, 2024

The number of issues that we receive every months across all our repositories is large enough so that despite our best efforts to triage and close issues we fall behind as soon as we carve out time for some focussed, uninterrupted development time. Now it's the time to focus on housekeeping and bring our issue database to a great shape. You can track our progress on https://joaomoreno.github.io/vscode-github-stats/.

Priorities for the December 2024 Housekeeping

  1. Bring our issue database back into great shape
  2. Reduce the number of open bugs by fixing them

Note: Don't distract yourself with fixing issues if your part of the issue database is not yet in great shape. Clearly, we'll use common sense, i.e. we'll make easy fixes on the fly if they take us a couple of minutes. We'll not make the fix if it takes us two hours. Also, refrain from engaging in debt reduction work until the issue database is organized and the number of open bugs is down.

Review Guidelines

In the first pass we review all issues across all our repositories. During review please make sure:

  • to close obsolete/fixed issues and mark duplicates as appropriate,
  • that each issue has a type label
  • that each issue is assigned to a feature area
  • that bugs you fix in December are assigned to the December milestone. Be conservative, see above.
  • to close out-of-scope feature requests assign the *out-of-scope label. There is no value in keeping issues open that don't have any realistic chance of being addressed.
  • close bugs as "won't fix" if there is a cost-benefit imbalance. It's not that we don't care about users who are affected by an issue but, for example, if the fix is so involved that we risk regressions for many, fixing is not a reasonable choice.

Otherwise the normal rules apply:

  • assign the important label to issues that
    • result in data loss
    • a breakage of extension
    • critical security, performance issues
    • UI issue that makes a feature unusable
  • issues that the community can take up should be labeled as help-wanted
  • if issues are suitable for beginners you can also add the good-first-issue label and add code pointers that help beginners to get started with a PR
  • feature requests that should be implemented as extensions should be labeled extensions-candidate and be closed

Tracking

Please make sure that you also housekeep in our satellite repositories.

Issues assigned to you

Issues assigned to feature areas but without owner

Other issues

  • ensure we don't have any issues assigned to people who are no longer on the team @rebornix

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

Labels

plan-itemVS Code - planned item for upcoming

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions