Trailhead - Where Do We Draw the Line?

Question

So I was reading through this question and it made me wonder some more about what makes a Trailhead question off topic.

Trailhead Apex Superbadge || INVALID_FIELD_FOR_INSERT_UPDATE, cannot specify Id in an insert call: [Id]

I think it crosses the line in that it posts basically an end-to-end solution (that's not working) and then seeks feedback. From What topics can I ask about here?

Trailhead: Questions asking for assistance with finding resources to answer specific Trailhead Questions or for help resolving issues with Trailhead DE Orgs are welcome. Questions asking for a direct answer to a Trailhead Question are not acceptable and will be deleted.

Trailhead is intended to demonstrate your capabilities on an independent basis. As a Community SF.SE wants to demonstrate its support for the purity of that cause by not interfering with your personal learning experience.

I think this question falls in a bit of a grey area based on the phrasing used above. But I do not think it clearly violates the spirit of the message: we should not interfere with our users' personal learning experience. Anyone googling about how to solve this Trailhead module will now find this mostly complete solution.

Answer 1

It's an unfortunate situation and I agree with you that it was a valid question that merited an answer to a specific problem the user was having with his code.

Perhaps the code in that question can be edited to remove the unnecessary details that provide the complete solution (including deletion of his test class since the issue was with his base code). Edited to add, that's exactly what I have done. I hope others agree with this solution. The user's issue is solved and the offending static variable is still visible. Only the framework of his solution remains.

With that having been said, complete or nearly complete solutions are frequently provided as answers in the Developer Forums; primarily to "buggy" or poorly written modules. However, with a "Super Badge", I'd really hate to see solutions to those posted anywhere and most definitely not on SF.SE.

Edit:

I wanted to add that we had a very lengthy discussion in Responding to Trailhead Challenge Questions that led to the wording you've quoted in your OP after the first question or two was posted here asking for help with a trailhead challenge. It's a fine line to draw between excluding questions related to Trailhead and letting people know that we're not going provide complete solutions as answers.

What was unique about this particular question is that it was essentially already a nearly complete solution that just needed a minor tweak in order to "fix" it. With most questions that are asked, with a few exceptions, it's usually a case of where the user hasn't looked at the documentation that's referenced by the module. Perhaps this a "heads up" to us that we need to be watching for questions that are asked in general and editing them after resolution to remove irrelevant code that provides too much information.

I can think of a few modules that were very poorly written initially or were very buggy when released where that wasn't the case. That said, SF.SE really isn't the place to be asking about those when that's the situation. There's the Trailhead Group on the Success Community and of course the Developer Forum's Trailhead Section where the "right people" (like Jeff Douglass) are there watching to help address those issues.

Unless you've already gone through a particular module you wouldn't be aware these issues exist or know what the workaround for them is. What you've quoted was essentially a compromise that allowed Trailhead questions to be asked, but prevented complete solutions to challenges from being posted in answers. Perhaps what's currently written should be edited to include that "the best place to ask questions about Trailhead" is either of the two locations I've referred to above for precisely the reasons I've just cited?

Answer 2

If you ask me, the appropriate thing to do is to remove mentioning of Trailhead and Superbadges from the question.

If it is a legitimate question about why a specific bit of code does not work, why does it matter that it came from Trailhead? Think of the way you would ask a question about a coding problem where the project was related to something sensitive in your company that you were not permitted to share. Same thing here, if you ask me.

The spirit of Superbadges is inspired by the same spirit that people use when taking the Advanced Developer programming assignment. As an early contributor to Superbadges (I wrote the POC for that scenario) and as a person who has been a judge for Adv Dev Cert, I would hate to see the solution being given away. Maybe the compromise is to take the mentioning of Trailhead and Superbadges completely out of it.

There is a lot of effort put into Superbadges, and giving enough information in the scenario, getting the wording right, making it difficult enough, but still attainable...all of those things are not trivial (as many have experienced it is easy to get wrong). So giving away the answer on SFSE is potentially throwing a lot of effort of the Trailhead team down the drain.

Still, if it is a legitimate problem, I hate the idea of standing in the way of helping someone learn from a mistake.

Could we add some language/guidance to the "How to ask" topic to the effect of:

If you have a legitimate problem with your code in Trailhead that otherwise fits in SFSE, please remove any reference to Trailhead (including specific custom object, class, and method names in your code), and ask it in the same way you would ask a question about code that is sensitive to your business.

Just a thought.