Docs: Remove outdated and unused issue labels

[BillWagner]

There are a number of labels that we've added to our repository that are no longer used, duplicates of other labels, or redundant.

while creating #15283 I created this list.

• C# / VB Diagnostics: This has no issues, and likely won't. Update: This is used for all compiler warnings and errors, and command line options.
• Older releases:
  
  
  
  • .NET Core 2.1: It's an old release.
  
  
  • .NET Core 2.2. Also an old release.
  
  
  • .NET Framework 4.7.2. Also an old release.
  
  
• assigned-to-author Only three issues, all in ML.NET. Is this useful?
• backlog: Temporarily used as a substitute for the backlog milestone, which won't accept new issues. Are either useful?
• content-model: We don't apply this anymore.
• All the "content" labels. We don't apply these anymore:
  
  
  
  • Content - concepts
  
  
  • Content - How to guide
  
  
  • Content - Overview
  
  
  • Content - Quick start
  
  
  • Content - Samples
  
  
  • Content - Tutorials
  
  
• doc-idea. We've used both "doc-idea" and new-content to represent tasks that create new articles. We think we'll standardize on "new-content".
• doc-provided: Was used in reporting. It's not anymore.
• easy: We've used the "up for grabs" instead of this label recently. All these issues already have "up for grabs".
• example-request: We haven't applied this in months.
• external. These should be relabeled with the "docs-experience" label and closed.
• All the "repo" labels. We don't apply them consistently.
  
  
  
  • docs
  
  
  • dotnet-api-docs
  
  
  • ml-api-docs
  
  
  • roslyn-api-docs
  
  
  • samples
  
  
• Gobal: VB Language Features: Unused.
• Low CSAT - HPV: We're not tracking this statistic now.
• Under investigation: We've been using the "waiting on feedback" label instead. These issues should be relabeled using that label.
• multiple-topics: Is this useful?
• not-repro: There's only one issue with this label. Do we use it?
• port-docs: We had used this to track docs we were importing from MSDN. Is it still useful?
• product-question: These should all be reassigned to the new "support-request" label.
• Project: We started using this to track projects and facilitate discussion on projects. Very few comments occured here. It's likely not useful.
• signed-off: We used this in the run-up to content freeze. We're not freezing this time.
• style-guide: We don't generally apply this label.
• triaged: The absence of the "Not triaged" label suffices.
• WIP: We're using the WIP GitHub application instead.

[BillWagner]

Note for all those on the Assigned list:

• If you use any of the labels in the list, add a comment with labels you want to keep.
• If you have no concerns with this list, up vote it using the reactions.
• After you've reviewed the list, un-assign youself so I know you've reviewed the list.

I plan on removing unused labels toward the end of next week.

[wadepickett]

Looks good to me, thanks Bill. In the future for identifying issues related to major sub-areas of the repo we could look at automating that on issue creation, or just rely on back end reporting if it is only useful internally.

[Thraka]

• new-content: This has been replaced by doc-idea. One of them should be removed.

  I think (@wadepickett correct me) that the general guidance is to NEVER use doc-idea ever again. So we should keep new-content

• All the "repo" labels.

  Just FYI, the ML and ROSLYN labels are in the automation tool based on content path, the others are not but I remember them being there in the past.

[wadepickett]

@Thraka, doc-idea. Yes that is correct. I took that offline with Bill before removing myself from the issue since it seemed like an internal item to iron out.

For the sub-areas, thanks for the info. I mistakenly thought the sub-area labels being removed were part of the automation set, but were not working for some reason, so we still needed a solution. Sorry I jumped to that conclusion. I should have thought it through for more than 2 seconds. :)

[BillWagner]

@Thraka On the automation: Before removing the labels, the rules for the labeler need to be examined to make sure none are automatically added abck.

[ChrisMaddock]

I personally like multiple-topics as I use it to find issues that can be scripted. 🙂 It's another one that could be applied more consistently though...maybe it should be replaced with something better identifying 'bulk change' issues?

[BillWagner]

I like the "bulk-changes" label.
Good suggestion @ChrisMaddock

[BillWagner]

I made two updates tonight:

1. The "C# / VB Diagnostics" is the label we've been using for compiler warnings / errors and command line args for both C# and VB. This should stay.
2. Instead of removing "new-content", we propose removing "doc-idea" and using "new content" for issues that create new articles.

[mairaw]

My two cents:

• Love the idea of bulk-changes instead of multiple topics. I think it has a more clear intent.
• Older releases: the two issues from 2.2 are currently in progress. I'd keep it until the two issues are finished. 2.1, 4.7.2 and 4.8 ok to delete.
• backlog: given that every new issue comes with the label not triaged, we could assume that something that was not added to a milestone and that doesn't have the Not Triaged label is our backlog. That logic doesn't apply to older issues. I don't like this label so ok to delete it. I just wish the milestone would work :-)
• content-model and Content - X: delete
• easy is a complement to up-for-grabs. I use those to advertise issues that are beginner friendly on Twitter, for example. GitHub standardized those as "good first issue" and "help wanted". Either set is fine to me, but I think we should keep some version of this.
• example-request: I still use that and recently applied at https://github.com/dotnet/dotnet-api-docs/issues. I want a way to identify issues that are requests for code fixes or new examples. I'm open to a better label name but I'd like to keep this.
• external: I'm really on the fence on this one because it's not only about docs-experience (we could mark as such for the minimum required set though). .NET marketing site issues, the ECMA spec issue, repo location are external but not really docs-experience. We usually try to resolve some of them and we keep them open until a resolution occurs. If we're simply closing them, how do we track these external things that are not applicable to be ported to MicrosoftDocs/feedback?
• repo labels: yes, not consistent usage. By default, it's assumed that the issue is to be resolved in the repo where the issue is filed. I add that for bulk issues that need to be done across multiple repos or to clearly indicate that the fix needs to be done in the samples repo.
• Under investigation is different than waiting on feedback. Under investigation is when I'm doing the action vs. waiting for the answer from an expert. Once the investigation is concluded, the label is removed.
• not-repro: 39 issues were closed as not-repro. Certainly we get just a few that we can't repro. We'd label as doc-bug but say it in the text that we couldn't repro?
• port-docs: not useful anymore.
• product-question: oh boy, I'm losing track of the minimum set! I personally prefer product-question since these issues sometimes become a doc-enhancement once I get the feedback from the product team (for example, after the product team answers the question, I then identify that the info is not covered in the docs but it should). I'm assuming that support-request would simply be closed given we're not supposed to provide support?
• Project: delete. not Useful.
• signed-off: I'd delete and re-add if we need it for a new release.
• style-guide; we used to apply this to issues when we had dreams of a perfect world. We barely have time to keep up with this sort of PR nowadays. Mark these as doc-enhancement.
• triaged: agree. Delete.
• WIP: agree. Delete.

There's also the Information Architecture label that was used to track internal housekeeping tasks. Should we delete that too? I never liked this name.

[BillWagner]

@Thraka Did you have more feedback? Or should I un-assign you?

[Thraka]

I agree with what Maira said. Nothing else to add.

[BillWagner]

Consolidating all the feedback on this into a task list below:

• [x] Rename easy: as "good first issue" to encourage first time contributors.

• [x] Rename multiple-topics to "bulk-changes"

• [x] Replace new-content with doc-idea

• [x] Replace Under investigation with "waiting on feedback".

• [x] Remove .NET Core 2.1

• [x] Remove .NET Framework 4.7.2
• [x] Remove assigned-to-author.
• [x] Remove backlog: Temporarily used as a substitute for the backlog milestone, which won't accept new issues.
• [x] Remove content-model/
• [x] Remove Content - concepts
• [x] Remove Content - How to guide
• [x] Remove Content - Overview
• [x] Remove Content - Quick start
• [x] Remove Content - Samples
• [x] Remove Content - Tutorials
• [x] Remove repo docs
• [x] Remove repo dotnet-api-docs
• [x] Remove repo-ml-api-docs
• [x] Remove repo-roslyn-api-docs
• [x] Remove repo-samples
• [x] Remove Goal: VB Language Features
• [x] Remove Low CSAT - HPV
• [x] Remove not-repro.
• [x] Remove port-docs
• [x] Remove Project.
• [x] Remove triaged.
• [x] Remove WIP.

[natke]

These sound like sensible recommendations to me.

Natalie

[mairaw]

A few comments:

• I wouldn't remove the repo labels yet.
  
  
  
  • Can we make sure that the ones marked as dotnet-api-docs are either mirrored in API docs too or moved (if it's only relevant to that repo)?
  
  
  • For repo-samples, can we perhaps rename the example-request to something that indicates samples related work more broadly? That way, we could replace repo-samples with the renamed label?
  
  
  • For roslyn-api-docs, should we transfer the issues to the code repo and change the settings to send the feedback there?
  
  
• For Projects, before removing, we should analyze if they simply should be closed because we have a tracking project in place.

Other than that, looks fine to me.

[Thraka]

One label we removed a while back was the "forum" label. This is an org label, should it be added back in?

[BillWagner]

For repo-samples, can we perhaps rename the example-request to something that indicates samples related work more broadly? That way, we could replace repo-samples with the renamed label?

I renamed "example-request" to "sample-code" and removed the repo label.

[BillWagner]

All the outdated labels have been addressed.

Closing this.