> On Feb 16, 2017, at 7:18 AM, Kevin Nattinger via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Feb 15, 2017, at 3:45 PM, Tony Parker via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Feb 15, 2017, at 2:25 PM, Charles Srstka <cocoa...@charlessoft.com >>> <mailto:cocoa...@charlessoft.com>> wrote: >>> >>>> On Feb 15, 2017, at 3:11 PM, Itai Ferber <ifer...@apple.com >>>> <mailto: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 <rdar://30543037> and rdar://30543133 <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, > > At the risk of getting off-topic, I think it would defuse a lot of developer > frustration around that to just show the status (open/fixed/wontfix/correct) > of the root bug. Filed radar 30551245 suggesting as much ;-)
Wouldn't it be possible for Apple to add a checkbox next to the issue that the reporter can check consenting the issue becoming public? I fully understand that many of the issues reported are confidential (security issues, attached code, etc.); but there are many, many, many issues that I'd be comfortable with becoming public so that others can just +1 them and see their status; or even comment on them, suggest workarounds. Something like OpenRadar does... > >> 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 <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <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
