An off-topic suggestion on radar bugs: Instead of closing as "dupe" why not call it "merged" into a known issue ?
Same technical result but very different IMHO user experience that allow communicating to the reporter that his bug hasn't simply been wrote-off as a "plus 1" but was combined into a very long story of use cases and examples to be considered while working on finding the optimal balance solution for the issue at hand. On Fri, 17 Feb 2017 at 1:16 Zach Waldowski via swift-evolution < swift-evolution@swift.org> wrote: > I can scarcely think of a less productive or more disrespectful thing to > do in a thread chock full of Apple engineers actively trying to help you > out. They're just humans, led by other humans. They can't divine the > presence of issues, just like they can't divine the priorities of > individual tasks without a holistic view of them. It would be far more > productive to figure out how we can get the changes we want done in a > public release of software as soon as possible. Everything else is > extraneous. > > Best, > Zachary > > On Thu, Feb 16, 2017, at 08:08 AM, Nick Keets via swift-evolution wrote: > > I’m going OT here, but even though I understand your reasons, you need to > acknowledge that for developers the rational thing to do is to not file > radars at all. > > Any bug fix will get released at best a few months later and you can only > actually take advantage of it a few years later (if you care about > supporting older versions). More realistically we are talking 3-4 years of > having to work around it (in the best cases). This is a lot of work (with > almost zero feedback) for some far future benefit that probably will not > even be relevant to you then. > > So to me, when an Apple developer asks me to file a radar, it feels like > they are asking me to do their job. > > I’m sorry for the off-topic rant. > > On Thu, Feb 16, 2017 at 1:45 AM, Tony Parker via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Feb 15, 2017, at 2:25 PM, Charles Srstka <cocoa...@charlessoft.com> > wrote: > > On Feb 15, 2017, at 3:11 PM, Itai Ferber <ifer...@apple.com> wrote: > > > FYI, Tony is the manager of the Foundation team. :) > We care very much about making sure that the experience of using our > framework is a positive one — the more Radars we get, the better we can > prioritize improving APIs that are not working as well as they could be for > our users. Even if the Radar gets duped to an existing one, thats one more > +1 for that Radar saying "this is a problem". > > Yeah I know, but it’s a frustrating experience, spending a half hour > writing a detailed bug report (sometimes with videos attached to > demonstrate the issue), just to effectively do the same thing as spending 5 > seconds to hit the +1 button on most issue trackers you come across. > > Especially since you never find out what happened to the original bug > report. You can see if it’s open or closed, but did they fix it in some > internal build? Did they decide it “behaves correctly?” Did somebody just > skim your report, and mistakenly attach it to some other, unrelated issue? > There’s no way to know. > > I will search for your old Radar, but in any case, please do file a new > one about this, and about any other issues you have, because we are indeed > listening. > > I was pretty sure I'd submitted something way, way back in the misty days > of yore, but I can’t find it. I’ve filed a couple of new ones: > rdar://30543037 and rdar://30543133. > > Charles > > > Thanks for filing these. > > Sometimes, for process reasons, we do indeed mark bugs as dupes of other > ones. Usually the polite thing to do is to dupe to the earliest filed one. > Sometimes this comes across with an appearance of not caring to the filer > of the new bug, but our intent is simply to consolidate the reports we have > so that we know that the issue is serious. > > We do not make API changes without going through a vigorous review > process, to avoid churn for the many clients above us. The flip side is > that this can take some time. I’m sure you understand that all software > engineering is about tradeoffs. > > All of that said, we’ll take a look at these and see what improvements we > can make here. As I said, I’m not a fan of exception-based API. > > - Tony > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > *_______________________________________________* > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution