I ran across this policy / process statement from the ASP.NET Core team. I have to admit that it doesn’t superficially seem very different from the Xojo process that we so often decry: make the user do all sorts of free work to “prove” they have an actual “issue” and then require the “issue” to run a gauntlet of deflections if it isn’t sufficiently “impactful”. These include open-ended “investigations”, “it-can-wait” referral to the planning meetings for the next version (.NET 8 in this case, due out November of this year), etc. Always with the possibility they can circle back to you and say you just have to change your configuration or assumptions to make the bug go away anyhow.
The difference is that for MOST ASP.NET Core users, the general sense is that the platform is mature and stable. I would wager that most users don’t file bugs, they just find workarounds and keep going, and this is sufficient to get work done. Where Xojo fails is its lack of integration and regression testing, relatively poor decisions around the design of their abstractions, and then pretending that’s not creating actual problems. I think even M$FT can be believed to an extent when they say an issue, while admittedly painful for a particular dev or team reporting an issue, is not widespread enough to take up bandwidth.
I think all software vendors have some sort of triaging and priorisation system. But even MS would very quickly come up with a fix for everyone if one centrepiece of their software landscape, let’s say Visual Studio, stops launching because it has a serious bug.
Exactly. I have definitely had small issues with Visual Studio and SSMS, things I can’t imagine they haven’t noticed and fixed on their own, but have gone on for years. But they are not show-stoppers, and don’t produce incorrect results. Often they are just how I think things “should” work or reflect my assumptions, if I’m honest. Others probably don’t notice them at all.
That is not the kinds of aborts and abends that we see in Xojo. And even when it’s not a show-stopper, it’s extremely sloppy. Like the way on Windows that I have to remember to minimize an open Xojo app (including the Xojo API) before disconnecting from RDP, or else when I come back the app will quit drawing anything to the UI. That should never have gotten past integration / platform-specific testing.
