Where to post OS API bugs?

[andrewleader]

We've been discussing the topic of where OS API bugs should be posted... for example, where should developers report WinRT OS APIs that are callable from desktop apps but have a bug? Or Win32 APIs that have a bug? We've seen bugs like #1874 and #1852 that are cases of this.

We have a few options...

• Option 1: The WindowsAppSDK repo is for WinAppSDK + OS API bugs that affect desktop apps
  • Pros: Can easily share/discuss bugs that affect desktop apps... which might be resolved by new WinAppSDK APIs anyways
  • Cons: WinAppSDK repo becomes inflated with bugs that technically aren't its bugs (and that ship on a separate ship cycle)
• Option 2: The WindowsAppSDK repo is for WinAppSDK bugs only, Feedback Hub for OS bugs
  • Pros: WinAppSDK repo stays focused on only WinAppSDK
  • Cons: Can be difficult to discuss/discover/report bugs
• Option 3: The WindowsAppSDK repo is for WinAppSDK bugs only, we create separate repos for WinRT OS and Win32
  • Pros: WinAppSDK repo stays focused on only WinAppSDK, can still easily share/discuss bugs that affect desktop apps, and those bugs can be captured in their separate ship cycles since it's a separate repo
  • Cons: Multiple repos to search through

What are people's votes? Vote each option from 1 to 5 stars with 5 stars being the best... You can copy/paste the table below to share your answer!

Options | Vote | Reasoning
--|--|--
Option 1 (all in WinAppSDK): | (1-5 stars) | (Explanation)
Option 2 (WinAppSDK + FB Hub): | (1-5 stars) | (Explanation)
Option 3 (WinAppSDK + repos): | (1-5 stars) | (Explanation) 

[riverar]

Options	Vote	Reasoning
Option 1 (all in WinAppSDK/OS):	⭐	"UWP" encompasses COM, WinRT, and Win32 APIs, some of which are decades old. All of these APIs would then fall into the "OS APIs" bucket and be bug candidates. Filling the repo with OS bugs would make it more difficult to gauge WinAppSDK readiness, find WinAppSDK relevant issues, and I can only imagine, consume large amounts of maintainer time that could be spent on WinAppSDK issues.
Option 2 (WinAppSDK + FB Hub):	⭐⭐	Keeping this repository focused on WinAppSDK-specific bugs frees the maintainers from having to triage OS issues. Feedback Hub is an OK alternative, but only if Microsoft commits to actually reading those reports. (It's my understanding the Developer Platform > API Feedback category/sub-category is not currently monitored.) These reports are, however, very difficult to find/share; Feedback Hub also makes use of region-based partitions which could render feedback completely invisible/inaccessible to other developers. There's also no discourse ability.
Option 3 (WinAppSDK + repos):	⭐⭐⭐⭐	Same benefits as Option 2, but with a transparent, developer-focused area to file bugs. Microsoft would need to commit resources to triaging those repositories. (It would be difficult to bring in external folks to assist as well.) Stray issues could easily get transferred to this repository from all repositories under the Microsoft org.

[lmadhavan]

Options	Vote	Reasoning
Option 1 (all in WinAppSDK):	⭐⭐⭐	This seems like the simplest option given the current state of things. It frees the developer from having to figure out whether an issue is specific to UWP/WinAppSDK or something lower level (WinRT/COM/Win32), which can sometimes be confusing. For example, the official documentation still lists WinRT APIs under UWP even though they can be used in desktop apps.
Option 2 (WinAppSDK + FB Hub):	⭐	I'm not a huge fan of Feedback Hub and I wasn't even aware that there was a section for API issues there, I always thought it was exclusively for end user feedback. I'm sure there are other developers in a similar boat who wouldn't really be looking at Feedback Hub for API issues.
Option 3 (WinAppSDK + repos):	⭐⭐⭐⭐⭐	This seems like the ideal long-term solution as it best reflects the actual structure of the products. WinUI and Win2D already have their own repositories and the boundaries of those products are fairly clear. With some effort, the documentation and messaging around the remaining products can be cleaned up and then it should be clear which issues are specific to WinAppSDK and which ones are general OS issues.

[andrewleader]

Thanks for the feedback folks! Based on the thumbs up, it looks like nearly everyone is strongly preferring Option 3. We're going to evaluate this in January when more folks return from vacation and see what we can do. No promises about anything happening, but at least we know what the community would prefer, which is the first step toward making progress on this topic! Thank you so much!

[mrlacey]

I guess I've learned a lesson here: Don't create an issue in a repo unless I'm certain it's in the right repo, and check the whole internet/GitHub for other reports of an issue first too.

[andrewleader]

@mrlacey I don't think that's the takeaway... if you create an issue in the wrong repo, teams that manage the repo will simply inform you and either move the issue for you, or close it and tell you where you should post it. It's not the end of the world and it's okay if you or someone else accidentally creates an issue in the "wrong" repo :) but to get your issues addressed fastest, it'd be best if you create them in the right repo after learning the right repo.

[mrlacey]

But creating a good repro takes ages! I have created accidental duplicate issues in the past and wasted hours in the process. I'm not saying everyone should do the same, it was more a note for myself as much as anything else.

[michael-hawker]

I definitely would lean towards 1. Having everything related to Windows APIs in one place makes it easier for folks to find existing issues. It's also unclear if something is related to the platform or a specific SDK when working on things. And if there's new stuff coming or should be used, folks here would know that the best.

This is where issue templates and auto-labeling could be handy to help differentiate them in the case folks know ahead of time what part of the platform an issue pertains to.

[micolous]

I saw this discussion was referenced for a platform bug, but while it looks like consensus was achieved some time ago, was anything finalised?

There are also APIs like WebAuthn, which already had a public repository (which would align with "Option 3"), but it doesn't presently accept issues or discussions. There's a contact email address, but unlike the discussions here, that's all 1:1, so its users can't even help each other out.

Thanks!

[mdtauk]

OS API bugs/requests/asks should have a public forum for upvoting and triaging. Like the new Product board that was added.

A place where the users/developers/community can help with prioritisation.

[JaiganeshKumaran]

The real problem with Feedback Hub is that it is too limited. You can't edit feedback, you can't use rich formatting and you can't see feedback from all countries and languages (only feedback from your own country and language, as well as English).

[DrusTheAxe]

Good feedback for FeedbackHub :-) @RDMacLachlan can you pass along word?

[riverar]

It's by design don't waste your time. And feedback hub is regularly wiped per policy making it a terrible location for OS bugs.

[DarranRowe]

When it comes to API feedback, I have gotten into the habit of just linking to a GitHub repo. That takes care of the vast majority of the deficiencies since the formatting is taken care of by GitHub itself. It is also useful to communicate the ever so useful minimal reproduction sample too. The README.md file can also be used to add any of the extra details that any character limit may inhibit.

This makes me wonder about me looking for ways to game the system.

[OrbintSoft]

So in the end what is the correct place to report windows OS API bugs? I tried to report this issue here #4955, but they closed saying I reported in the wrong repository.

I can report it Feedback Hub, but it will never get attention from developer, it's a good tool for an average user to give windows feedback, but it's not a serious tool report bugs in the API, report source code and start a constructive technical discussion.

[DrusTheAxe]

@RDMacLachlan what's the current recommendation?