Announcing Cleanup of Stale Issues #8638
Replies: 11 comments 16 replies
-
|
What about WinUI 2/system XAML issues on this repo? |
Beta Was this translation helpful? Give feedback.
-
|
All issues are being treated the same. WinUI 2 has had many updates as well. If your issue is still present, just add a comment. |
Beta Was this translation helpful? Give feedback.
-
|
Also, can you send a message in the affected threads, like stale bot does, to give a chance to users who might not see this to keep their issue alive. |
Beta Was this translation helpful? Give feedback.
-
|
Every issue that gets a message would no longer appear dormant. Closing dormant issues with a boilerplate message about why it was closed would have the same effect as leaving a message, and the issues can be reopened afterward. As much as I don't like the idea of closing 1000 - 2000 open yet dormant issues, if this is what it takes to get things on track, then so be it. |
Beta Was this translation helpful? Give feedback.
-
|
Just make sure they're closed as "Not planned" instead of "Completed". |
Beta Was this translation helpful? Give feedback.
-
|
@kmgallahan Unfortunately, the original filler of the issue cannot reopen it by themselves if it was closed by an employee. |
Beta Was this translation helpful? Give feedback.
-
|
@sylveon That is the point of the boilerplate closing message - stating why it was closed and how to have it reopened (@'ing Bob, et.al) |
Beta Was this translation helpful? Give feedback.
-
|
The standard github stale action is being used since they have already solved the items mentioned (and more). |
Beta Was this translation helpful? Give feedback.
-
|
I'm kind of disappointed with this. I have 29 open issues, all of them over a year old and the oldest 3.5 years old. They are all system XAML (or WinRT) bugs or design flaws. I'm not aware of any of any of them having been fixed, although at lot of them are marked needs WinUI 3 so it's possible. I don't have time to test them all again now, especially as I haven't started using WinUI 3 yet (it's still not mature enough for me to migrate plus in need the startup performance of NativeAOT, and it's a really big job). If you're going to close them without triage, please at least label them as 'Closed but might not be fixed'. |
Beta Was this translation helpful? Give feedback.
-
https://github.com/microsoft/microsoft-ui-xaml/issues/created_by/benstevens48 Open 10 tabs, leave a comment saying "Keep alive", close all, and repeat 2 more times. It's a one time thing and should take ~5 min unless you consider if each issue ought to remain open or not. You leave high-quality issues, so I think they should all remain open. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, thanks. I was thinking I ought to triage them first, but I don't have time for that, so I'll probably just follow your advice. |
Beta Was this translation helpful? Give feedback.
-
|
According to the .NET community about the direction of Native AOT, unfortunately I found out that it may take dotnet 9 to bring this technology to WinUI3 (the above is my personal guess with some issues). |
Beta Was this translation helpful? Give feedback.
-
|
Are the issues tagged Maybe a slightly different deadline for them - considering the newest one is from 2 years ago, it shouldn't be much trouble (I hope :)) to leave a comment on the inactive ones, and make the deadline for them be something like a few weeks. |
Beta Was this translation helpful? Give feedback.
-
|
Please don't close all my XAML Compiler bug reports. |
Beta Was this translation helpful? Give feedback.
-
|
You need to comment on them to avoid it |
Beta Was this translation helpful? Give feedback.
-
|
If MS can't fix one of their main intellectual properties - the should open the sources. I think I can hack it working for me. "Ugly" of course - but I don't care as the required XAML compiler workarounds are too... |
Beta Was this translation helpful? Give feedback.
-
|
"We haven't been following publicly reported issues and they've gotten out of hand. To fix it, we better just delete them all." That's absolutely not how to manage a project. You are not only wasting all of our time (from years past) opening issues and following them. But you are missing potentially quite valuable feedback. The reason several issues are years old and "stale" is not because they are no longer issues. It's because no one in Microsoft did anything with them. That is your failing and a mismanagement of the project. If you were even remotely competent at triaging issues you would assign someone to go through and at least capture high value feedback before they are bulk closed by a bot. |
Beta Was this translation helpful? Give feedback.
-
|
So? Nothing happened after the announcement? |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
This response is completely kneejerk and, frankly, lazy. What other company would tell their users to verify things are still a problem? Use your own damn resources we've already provided our valuable time to Microsoft to document bugs - QA at msft is clearly nothing like the old days. It's been clear for a very long time that no one at Microsoft is working on this repository publicly. In the early days, WinUI developers would reply to issues that were raised and there was an effort to triage the cases. How many developers are working on WinUI at Microsoft? 2? 3 including an intern? The whole project trajectory is embarrassing and it's insane to think that this framework is this underdeveloped when it's at least a 12 years old (first developer preview of Windows 8 was in 2011). Look at how much Android and iOS have iterated since then. I have 14 open issues dating back to 2019. A lot relate to the half baked "desktop" support including default controls and proper modal experiences. You guys need to do better and rebuild community confidence in this project. Personally I'm glad I had the foresight to abstract platform dependencies in the early days so I can move to any UI platform supported from C# using MVVM. Really hope for a change in attitude but I won't hold my breath. The fact Microsoft want LOB applications written in WinUI but don't support the established WPF validation (or any validation pattern) is not workable. And in case you haven't noticed, enterprise devs are pretty much the only developers making Windows applications these days. |
Beta Was this translation helpful? Give feedback.
-
|
I no longer care about the future of WinUI, having moved back into Web, mobile development and distributed computing. Hence why I didn't bother to reply to any of the notifications of tickets being closed, which are all of them quite current and closing them won't change the bad state of WinUI versus UWP development. Native AOT still isn't on parity with .NET Native. C++/CX has been deprecated since 2016, and C++/WinRT is a joke in regards of development experience, no Visual Studio tooling for IDL files, we have to manually merge generated code into the existing code base as we incrementally have to update XAML and WinRT components, a development experience similar to using ATL back in 2000, and there is no roadmap to move beyond C++17 ever. It wouldn't be half as bad, if there wasn't the whole thing about being how great it is that WinRT/WinUI is implemented in C++, and forcing several workflows, like 3D Media (super easy in WPF), to make use of C++ and such archaic tooling. Meanwhile on Apple and Google platforms, there are nice Swift and Java/Kotlin bindings for all use cases, even if the implementation is in C, Objective-C, C++. With designers! The excuse that reflection is needed or that C++/CX needs extensions is a joke on us, as VC++ always had plenty of extensions and it isn't as if UWP/WinRT are some kind of cross platform framework that needs to be portable to another operating systems. Speaking of which, I would advise the WinUI folks to spend some time actually using C++ Builder and Qt/QtCreator/Qt Design Studio, to finally learn what a modern wow framework for C++ looks like, with 30 years of history. Win2D on WinUI 3.0 still doesn't have feature parity with Win2D on UWP. No designer in sight, plenty of bugs while Microsoft keeps porting key applications into PWA, WebWidgets or Electron. After all the rewrites that we had to go through since Windows 8 was introduced, the downgrade in developer experience from UWP to WinUI, you will really need to do a major action to win back those of us that deeply belived in the platform, only to be burned multiple times by UWP/WinRT management. Besides closing tickets, think on how to rebuild bridges, and prove that WinUI isn't yet another Silverlight, XNA,... |
Beta Was this translation helpful? Give feedback.
-
|
I didn't have time to test my issues during the working week, but there are some bugs definitely still present: #6350 Should I open a new issue, or would you reopen it? |
Beta Was this translation helpful? Give feedback.
-
|
That issue is fixed in 1.5. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
I've reopened these items, except for one that I posted a question to determine what action is appropriate. Thanks for posting this! |
Beta Was this translation helpful? Give feedback.
-
|
Please also consider allowing us to build the XAML compiler and open pull requests for changes to it. |
Beta Was this translation helpful? Give feedback.
-
Update:
There are a lot of things going on (1.3.3 released last week, putting finishing touches on 1.4 Preview 2, etc), but we needed to give an update on this process.
We have marked the issues that would be impacted using a new label "no-issue-activity". That was done to not overlap with any existing items and to make queries easier. The marking was done using the standard github action, which gets the benefits of state management, notifications, proper closing, and making it so the issues are not closed by a team member (all issues brought up in the comments).
In total, there were about 1500 issues identified over multiple runs of the workflow that occurred last Thursday through Saturday. So far, around 7% of those have been updated, which causes the stale label to be removed. Those will remain open. The issues were set for a 5-day holding period before they are closed, which means the first closings will happen tomorrow.
As stated below, we should not have gotten ourselves into this state, but this is a purposeful process we are pursuing to get out of the hole and into a better place.
If one of your issues was marked and you are still seeing it on current releases, add a comment and we will keep it.
Thanks for your support and understanding
The WinUI Team
FAQ:
Is this going to be a standard practice moving forward?
No. That is the reason the workflow was done in a PR and not made a permanent part of the repo. Our intention is to not repeat the past and to do a better job of staying on top of the issues.
Why will things be different?
We are moving to a new process where each new issue on github will also be created in AzureDev Ops, where we will triage, prioritize, and do our daily work. When the state of the issue is changed or the milestone is changed, github will show those changes. It should be greater efficiency for us and greater visibility for everyone.
====
As we mentioned in the last community call, we are moving away from the model that tracked issues separately in github and AzureDevOps and towards a single list of issue that includes both. This will involve bringing all active github issues internally. To do this, we can’t (and shouldn’t) drown ourselves in the significant backlog that we have allowed to grow in github (mea culpa!).
What this means is that we will be bulk closing any issue that has not seen any activity in the last 180 days. We will be creating an exception for Feature Requests, and handling those separately. Action will be taken next Wednesday, July 19, 2023.
If you have issues that you still care deeply about that have been lying dormant, all you need to do is post a single comment. That will set the Last Activity Date as today, and the issue will remain as-is. After any item is closed, it (of course) may be reopened.
Our logic here is that 180 days takes us back to the release of WinAppSDK 1.2. Please attempt to repro any older bugs on a recent build and update the results.
Thanks!
The WinUI3 Team
Beta Was this translation helpful? Give feedback.
All reactions