CS Effort: ASP.NET / IIS / EF All Repos

[wadepickett]

Parent tracking for all CS efforts for all ASP.NET / IIS / EF repos.

This effort will likely span more than one monthly sprint. It is expected however that we start triaging right away.

NOTE ON SCHEDULE for just GUID hits: We do not have specifics for addressing GUID hits yet as of 8/9/24. I am assigning it to September for the tracking item for GUIDS so we don't forget it and look again to see if we have more details, but it may or may not be something we handle in September. The plan is to use DocuTune to remediate as many of the GUID hits as possible, so when we do have instructions for this, it will include reviewing PRs from DocuTune fixes. More info expected late August.

For details see: SFI info in Teams

CS effort for repo: AspNetCore.Docs

• [x] GUIDS:

• [x] 0: Done, all good here.

• [x] ROPC: 0: Done, all good here.

• [x] Global: 0: Done, all good here.

• [ ] Image scans: 59 images

CS effort for repo: AspNetDocs

• [ ] GUIDS: 2 files

• [ ] Global: 3 Files

• [ ] ROPC: 86 files

• [ ] Image scans: 859 images

CS effort for repo: IIS-docs and MicrosoftDocs/IIS.Administration-docs

GUIDS: 0: Done All good here for both repos.

ROPC:

• [ ] 107 files in IIS-pr

• [x] 0 in IIS.Administration-docs

• [x] Global: 0: Done All good here for both repos.

Image scans:

• [ ] 512 images in IIS-docs

• [ ] 1 image in IIS.Administration-docs

CS effort for repos: dotnet_EntityFramework_Docs dotnet_EntityFramework_ApiDocs

• [x] GUIDS: 0: Done. All good here for both repos.

• [x] Global: 0: Done. All good here for both repos.

ROPC:

• [ ] 35 Files in EntityFramework.Docs

• [ ] 0 in EntityFrameworkApiDocs

Image scans:

• [ ] 10 images in EntityFramework.Docs

• [x] 0 images in EntityFramework_ApiDocs

---

Associated WorkItem - 302690

[Rick-Anderson]

@wadepickett add internal links to the CS effort, what's required, etc.

[wadepickett]

I was keeping those internal, you have them. But if you want them here I will. Generally, I always do, but not for CS related. There will be internal tracking links in a moment for each of these. I will have the details there, and that will be a great place for discussions about how we are addressing them.

I was hoping to see the sfi- labels show up and then I can reQuest with the right parents. I don't see them yet however.

[wadepickett]

@tdykstra and @Rick-Anderson, I thought the new labels sfi-ropc and sfi-admin would show up by now and was intending to assign them for the individual "sfi-" related GitHub issues for global, ropc, etc. Andy PR'd a few days ago. But they don't seem to be available yet. Are we waiting until later to make them available or maybe I am missing something embarrassingly obvious?

Andy added these a few days ago: { "Label": "sfi-ropc", "ParentNodeId": 271716 }, { "Label": "sfi-admin", "ParentNodeId": 271716 }

[wadepickett]

Please disregard, I see the labels just needed to be added through the GitHub UI. done.

[wadepickett]

Reminder: For details see: SFI info in Teams

Also included there are word docs that had specific instructions on how to deal with each type that are due to triage and fix so far.

[Rick-Anderson]

@wadepickett @tdykstra container issues like this shouldn't have reQUEST so I removed seQUESTered and added mapQuest. ~ I don't think mapQuest is currently working.~

It's working: is:open is:issue label:mapQuest

I add mapQuest and a few seconds later it's removed, ~so I guess it's working. No new label to tell you it worked.~

[Rick-Anderson]

@wadepickett closing as we've completed the triage.

[wadepickett]

@Rick-Anderson "Closing". Thanks, that is fine. Originally it was just created as a parent to keep track of everything involved with this effort, not just triage. So I stated up front at the very top "This effort will likely span more than one monthly sprint." However, I should not have set a "ReQuest" label, you are right, it should not have been represented in ADO.

[tdykstra]

@wadepickett @tdykstra container issues like this shouldn't have reQUEST so I removed seQUESTered and added mapQuest.

So should we delete the associated AzDO work item 302690?

[wadepickett]

@wadepickett @tdykstra container issues like this shouldn't have reQUEST so I removed seQUESTered and added mapQuest.

So should we delete the associated AzDO work item 302690?

I updated the AzDO work item to just state it was tracking just the triage portion and it is closed.

I wasn't finding this earlier on AzDO because it was not assigned to me. I think for a while, request was ignoring who was assigned and setting everything to you Tom? Or maybe I just did that by mistake. I saw you assigned to several of my github issues that I hit request for last month. I will doubler check that as I go forward.

[wadepickett]

@Rick-Anderson & @tdykstra

We decided at some point I was handling all the Images fro every repo correct? It seems to me we did, which I am fine doing and working through right now starting at the the most severe (sev 0) in every repo and working down from there. I can figure those out, but for ROPC I wasn't always sure what our correct answer should be.

...Going through all the rest of the SFI issues I created to make sure they are cleaned up and represent how we ended up doing things.