Re:Rationales for Swift standard library designs
by aaronbrethorst on Monday March 14, 2016 @10:17PM
(#11287016)
Yay, Apple, for opening up quite a bit. Boo, Apple, for including such a thing as this in any webpage ever:
Radars: rdar://problem/19705854
I really, really, really hope that Apple opens up Radar a la Microsoft Connect, and soon. It is stupendously frustrating to have an issue with an Apple product and run headlong into the brick wall of Radar.
Re:Rationales for Swift standard library designs
by drakenot on Monday March 14, 2016 @10:58PM
(#11287157)
Gruber brought up how in Apple Maps, if you suggest a correction, you are eventually informed when the fix is made.
However, with Radar, it is just a blackhole. You file your report and an awful lot of bugs, no matter how well written or even if they have example code, they will never hear back again about it.
He said that this was a negative feedback loop because developers will end up submitting less bugs because of this lack of communication.
Craig said that they aren't where they want to be with the "external interface" of Radar. They use Radar heavily internally but they face challenges with Radar and the general public.
He expressed that the Radars are read, but then the process is usually that they are duped with some internal Radar issue. Then they struggle with how to externally communicate what release a particular bug will be fixed in, or to make particular promises about certain bugs, etc.
But he reiterated that they had really fallen short on providing a good tool with feedback for the general public.
Re:Rationales for Swift standard library designs
by Someone on Tuesday March 15, 2016 @03:27AM
(#11288045)
It's bad, but not quite a black hole. I have had the occasional feedback out of it, of the limited form "this should be fixed in the release that just came out. Please retest"
Re:Rationales for Swift standard library designs
by makecheck on Tuesday March 15, 2016 @09:12AM
(#11289322)
Well, perhaps they could start by looking at a feature of their own OS, introduced by Federighi himself (yet nothing new regardless): Tags.
If they simply started tagging things internally in some way that associates issues with external things like bug numbers and release numbers, they would have a start toward communication with the outside of the company.
https://daringfireball.net/thetalkshow/2016/02/12/ep-146
However, with Radar, it is just a blackhole. You file your report and an awful lot of bugs, no matter how well written or even if they have example code, they will never hear back again about it.
He said that this was a negative feedback loop because developers will end up submitting less bugs because of this lack of communication.
Craig said that they aren't where they want to be with the "external interface" of Radar. They use Radar heavily internally but they face challenges with Radar and the general public.
He expressed that the Radars are read, but then the process is usually that they are duped with some internal Radar issue. Then they struggle with how to externally communicate what release a particular bug will be fixed in, or to make particular promises about certain bugs, etc.
But he reiterated that they had really fallen short on providing a good tool with feedback for the general public.
If they simply started tagging things internally in some way that associates issues with external things like bug numbers and release numbers, they would have a start toward communication with the outside of the company.
Raymond Chen is particularly good at writing them [1] [2].
[1] https://blogs.msdn.microsoft.com/oldnewthing/20110907-00/?p=...
[2] https://blogs.msdn.microsoft.com/oldnewthing/20160216-00/?p=...