This forum is so incredibly effective, smart, polite, fast, helpful in every way for Swift language questions, it is natural to desire a similarly effective forum for SwiftUI and look here for it. If wishes were horses, etc... As pointed out above, inviting those topics here will dilute and destroy the quality here achieved due to its current focus. If that is happening, I'd encourage the moderators here to take a firmer hand wielding what Scalzi calls the Loving Mallet of Correction™ to discourage the off-topic. As much as I, too, would love to have this level of expertise on SwiftUI matters, that is not what this forum is for and attempting to accommodate it will only hurt what works so well here.
4 Likes
I think 90% of the problem would be solved if Apple gave up on their own horrible forum software and just replaced it with another Discourse instance. That way when we tell people here to go use the Apple developer forum instead, they might actually do so. With the current setup everyone takes one look at Apple's site, decides (rightly) that it's useless and unfriendly, and comes back here.
20 Likes
As a moderator, I'm happy to redirect people with these questions to the Apple forums. However, I don't have time to proactively read every thread here, so I rely on the community bringing things to my attention with flags. Flagging a post takes two clicks, so if you think something is off-topic, and you don't feel up to (gently) redirecting the contributor yourself, please just flag it, and I (or another moderator) will take care of it.
5 Likes
I really dislike Apple leveraging their influence here to push their so sad forums, but I can understand that this is not the right place to ask, for example, SwiftUI questions. The separation is clear. There is no "right" place to ask SwiftUI questions, but that's a different battle.
4 Likes
From a perspective of iOS/macOS developer (who I am) the win-win situation would be if Apple incorporates those other bestest things like WebURL or improved json parsers into their frameworks so that even those people who have "no third party code" policy can benefit.
JSONEncoder/Decoder is an example of blurriness in the rules here... I don't foresee (or want!) Karl or John chasing up people here with "stop discussing JSONDecoder, it's Apple close source implementation!". And if discussions about NSURL or json alternatives are ok, I don't see how discussions from my hypothetical example above are not (e.g. something like this but less dead). Hope this is not an indication of UI-intolerance expressed by server oriented people of this list. Unless of course UI topics are prohibited by rules here, even if they are not discussions about Apple frameworks.. Let me double check... which brings me to the question: where are these rules written? I thought they would be pinned here in some code of conduct or FAQ or something but I don't see them.
Example of what's currently pinned:
If you haven't been here for a while you'll have no clue that topics about Xcode or SwiftUI / UIKit / Foundation are not appropriate here as they can be perceived by "related tools" by significant number of not so experienced iOS users (let's face it - iOS users are the majority of swift users as of now).
3 Likes
My suggestion on this topic has been ignored.
6 Likes
This is more than about SwiftUI question. This is an example of what to do when Apple's interests conflicts with the community's interests. It will be fruitless to continue the discussion. Let's not waste the time and just keep the status (I think the Swift community is very friendly and the technical process is transparent).
2 Likes
Continuing discussion with @Karl from Cannot assign to property: ‘self’ is immutable?
Posts have been moved here, but are out-of-order. Chronologically, this post is ordered directly after this one
Asking users to post a more self-contained example is perfectly reasonable. What is not reasonable, IMO, is telling users that their post is off-topic without verifying that yourself simply because the question mentions an Apple framework.
I think this is unfair to the OP of that topic. They explicitly said that they posted here because (in addition to being disillusioned with the ADF) they suspected there was an underlying language issue that they didn't understand. And they were right! This is exactly the kind of question that should be asked on these forums.
This feels a bit hyperbolic to me. I advocated for flagging posts for moderator attention in situations where a community member is not confident in their evaluation of the on-topic-ness of a particular post. I don't consider that "ignoring the rules."
You said yourself that you "don't like to [tell users their post is off-topic]," and the moderators have expressed that they are happy to do so, so why take it upon yourself if you don't want to do the verification work yourself?
8 Likes
Yes, we have established that, thanks Xiaodi.
At the same time, due to the high number of SwiftUI-specific posts on these forums, it is helpful if members could reduce their use of library types before posting. Otherwise, they may be advised to seek support with the library developer before seeking support on forums for lower-level components. That is how it should be.
If there is unexpected behaviour in an application, users should likewise seek support from the application developer, before asking the OS developer or chip manufacturer. The issue may indeed lie with those lower-level components, but unless you can produce a reduced demonstration, it is in general difficult to isolate where the problem lies. If members don't do that themselves, they should expect to be directed to a more appropriate forum.
In this case, it only became clear that this was a language question once the library-specific components were eliminated. That is the proper way things should work.
EDIT: this discussion was thread was moved from another thread, posts are slightly out-of-order
IMO that sets too high a bar for posting if this is to be a beginner-friendly forum. Often times producing a minimal example is hard, and indeed it might not even be feasible to reproduce it without importing an Apple library. If the issue is caused, for example, by an undocumented annotation that happens to be used by SwiftUI, it's going to be next to impossible for an inexperienced user to produce a standalone example, but I would consider such a problem as decidedly on-topic.
I think it should be the responsibility of community members to verify that a question really is about Apple frameworks before directing users to post elsewhere. If there's any doubt about whether a particular problem is an Apple framework issue or a Swift issue, the community can flag the post for moderator attention.
3 Likes
Response
If they can't produce a minimal example, they should file a bug report and let the library author debug the problem. There may very well be a root cause that would be in-scope, but it is unreasonable and unrealistic to expect us to debug every problem before telling people to seek support at a more appropriate level.
It is not about being beginner-friendly or not - this is not the forum for SwiftUI. It never was. There is a forum for SwiftUI, and this is not it. If you have a SwiftUI problem, you should seek support at the place provided for exactly that. And if you can't reduce the problem, let them deal with it.
There are a number of users on these forums who are simply rejecting the rules because they don't like them, they think Apple's forums suck, etc (including the OP).
I think your idea is just an excuse, to be frank. Another attempt to justify ignoring the rules, as we've seen time and time and time again.
Not at all: I think users should justify that this is the appropriate forum for their question.
Anything else is untenable. In order to say for sure where the problem lies, we need to debug it. That means trying to debug how all of SwiftUI's various property wrappers, result builders, and other (potentially undocumented) features work - using pure guesswork, because we don't actually have knowledge about any of that stuff. That's why it is better to use the actual SwiftUI support forum for those sorts of questions.
The core concept that you are ignoring here is: triage. Issues need to get sorted and classified by those best equipped to do that. It may be that users later get referred back to these forums.
But if we start with the business of trying to guesswork-debug SwiftUI, this then very quickly becomes the SwiftUI support forum.
Just because this one question happened to be reducible does not justify the principle. If they were not able to reduce the problem themselves, they should have asked a higher-level support forum or filed a bug report.
The moderators are not actually doing it, which is why I've had to go around mopping up threads that were clearly only about SwiftUI.
I know that it isn't popular - everybody seems to be in agreement that Apple's forums suck. Members here are definitely looking for any excuse to ignore Apple's policy and turn this in to a SwiftUI support forum. I think that's very obvious.
@tkremenek - this is Apple's policy, I think it's clear that it needs to be clarified.
1 Like
A perfectly reasonable response to such a thread which involves no debugging effort is:
It's a bit hard to tell what the issue is here without a more minimal example. Could you try to edit this down a bit, and remove any imported frameworks if possible?
Of course, another perfectly reasonable response is to simply flag the thread for moderator attention if you think there's a chance it's off topic but the effort required to verify that yourself would be too high.
I'm not disagreeing with the principle that the community can help direct users to the proper venue. I was disagreeing with the callout of OP as someone who is "rejecting the rules." They absolutely did no such thing—their post was on-topic!
2 Likes
Our policy is that questions about Apple-specific frameworks should go to the Apple forums. That doesn't mean that users have to pretend that they're not using Apple frameworks and strip out all references to Apple framework concepts in order to ask questions here. It means that questions should be about the language, not solely about the APIs. Sometimes this is a little muddy, and that's okay, and the bias should be towards allowing the questions. In this case, the question was about the language situation set up by their use of the framework, which is clearly on-topic. If you don't know the framework well enough to understand the language situation it sets up, that's fine, you can leave the question for someone else.
It is not anyone else in the community's responsibility to mop up off-topic questions but the moderators. I appreciate it when people do some of this, but if you're having trouble not coming across as hostile, you are doing more harm than good, and I would like you to stop. You can just flag posts as off-topic, and we will deal with them. (To be clear, when I say "flag", I mean an actual flag, not just adding the off-topic tag.)
20 Likes
Or, you know, what I actually said:
And then once another member reduced the example and showed that it was a language problem, I even helped to reduce the example further 
OK, good. FWIW, I don't think I've come across as hostile - I think the community in general is hostile to the idea. You just get painted as the bad guy even if you're polite and help people.
3 Likes
Yes, I think that's a good piece of feedback to provide, and would have been fine as a direct response to the topic. However, IMO your first response was too dismissive given that the thread was indeed on-topic.
Most users' first exposure to Swift (right now, at least) will be through an Apple framework, and so chances are many beginners' questions are going to mention or import some Apple framework. If the knee-jerk response to such questions is, "Please don't post this here," the forums are going to be an unwelcoming place for beginners.
If you are telling users that their on-topic posts are actually off-topic, that is not helpful and people are going to be upset. I have not seen significant community pushback on users telling topic authors that their actually off-topic posts are off-topic.
10 Likes
i agree with this very much. people are people and will remember how they were treated for a long time. i think understanding this is crucial for the long term growth of the language outside of Apple platforms. we don’t want this place turning into stackoverflow.
the issue is there really isn’t a good policy for these kinds of “could be on-topic” cases. the question was originally off-topic and then it became on-topic once the root cause became clearer.
that said, as a rule, when high-reputation users try to enforce rules against new (and therefore low-reputation) users, it will always come across as hostile, no matter the intent. this is true on wikipedia, this is true on stackoverflow, and this is true here. that’s not a criticism, that’s just an observation.
5 Likes
The question was always on topic—that the code in the first post happened to be using SwiftUI was immaterial to the underlying issue, as another member of the community showed after only a couple posts. I think John has been clear that in cases where you think-but-don't-know that a particular thread is off-topic, the policy is "flag for moderator attention," and then let the mods decide for themselves whether the given thread is appropriate for this forum.
9 Likes
My opinion is that there has been a vast over-reaction to a single incorrectly-triaged post, and that characterisations which suggest this is some kind of "knee-jerk" pattern of behaviour are not helpful or justified, and are in fact more hostile than any behaviour they are attempting to prevent.
Sometimes things get triaged incorrectly. It happens, and once it was pointed out, there was absolutely no problem.
I certainly feel that I am being personally attacked and unfairly characterised here, and the hostility I've experienced from members has affected me. I never asked for any of that - this was only motivated by a genuine desire to keep the forums tidy because, as noted in the original post, there was an increase in members who certainly did know their posts were off-topic, but didn't care, and this was having a follow-on effect by misleading new and less experienced members.
That's my last word on the matter.
5 Likes
Where is this written down?