The original question was sarcastically asking whether reading the documentation was too much to ask, implying that laziness was the issue. I responded that for the target market, yes, it actually is too much to ask, and not because of laziness.
I didn't come in and say the whole thing was a bad idea and that it should be abandoned. Just that if the design requires more than a paragraph of explanation, then that's a serious problem for the target audience. As well as pointing out that the idea of not requiring opt-in actually causes the friction that it seeks to avoid.
If insight into the target audience's perspective is demoralizing, you honestly should stop and reconsider your priorities. I say that without any kind of sarcasm or criticism in my voice. If the people you want to help believe that the thing you're making will cause problems for them, that's a red flag. It's not always true, and it might not be true for all users, but it's something to seriously consider.
If people are worried that your product will appear to be a scam, you absolutely need to reconsider.
> If insight into the target audience's perspective is demoralizing, you honestly should stop and reconsider your priorities. I say that without any kind of sarcasm or criticism in my voice. If the people you want to help believe that the thing you're making will cause problems for them, that's a red flag.
I actually agree with this completely, but it's totally orthogonal to key points of the counter-arguments here. Some people thinking your project will cause them issues cannot be inherently bad, pretty much out of necessity, because you simply can never please everyone all the time. If it starts to become a sizable portion of your intended audience, maybe, but even then there will always be a sizable signal/noise ratio as well, which is the real issue here. It's not that people's concerns are unfounded, or that they should be ignored, it's that nothing is ever argued in favor of why this specific issue should be prioritized over all the other equally urgent issues in a project, nor more importantly, how this particular issue could be addressed.
The problem here isn't one of digging up issues, as anybody that's managed any kind of non-trivial project knows they are plentiful, it's a problem with finding solutions. Therefore, the main counter-argument that's been made here is that simply shouting and pointing at these things is not going to help your case as an end user. It's a pretty straightforward point, but people seem to forget that all projects need to make trade-offs, and that often their contributions aren't totally novel "insights" that the project maintainers aren't aware of.
For example, you state:
> if the design requires more than a paragraph of explanation, then that's a serious problem for the target audience.
Which is true, but arguably anyone doing any kind of business would likely know that already. The trouble is actually coming up with such a short explanation, especially when as was claimed before, people don't like to read documentation. It's not exactly easy to explain Bitcoin in one paragraph, much less smart contracts, and even harder still to explain some etherium-based token, on top of explaining the business model and the reason behind it in such brevity. Which is why, even though I'm also not particularly in favor of this BAT project, I know I have nothing to contribute to it in terms of useful criticism because I acknowledge that it's a hard problem and that they're fighting an uphill battle anyway. The part that I am arguing against, is that many seem to implicitly believe that just pointing out that some project is fighting an uphill battle is enough of a worthy contribution to get their concerns addressed/acknowledged somehow.
The more concerning corollary to this, is not so much that these sorts of responses "discourage" active project developers anyway, but that they de-incentivize future projects from even attempting to bother with hard problems, just because they observe enough of a backlash against previous solutions that they deem the risk-to-reward ratio not worth it, instead of actively exploring the space, when that's exactly what's needed to gain any sort of traction on long-term hard problems.
We already see this happening, with so much manpower going towards developing relatively safe "problems" like scaling social networks and/or optimizing ad delivery mechanisms, instead of encouraging people to try out different/riskier things. And that's the real crux of the issue.
> It's not that people's concerns are unfounded, or that they should be ignored, it's that nothing is ever argued in favor of why this specific issue should be prioritized over all the other equally urgent issues in a project, nor more importantly, how this particular issue could be addressed.
1.) This issue should be prioritized because it makes the whole endeavor literally appear to be a scam to the exact people it wants to help by sending them money.
2.) It should be addressed by being opt in.
Both of which I did cover in my previous posts.
I get where you're coming from. But this is actionable advice with a very strong reason why it should be prioritized.
I didn't come in and say the whole thing was a bad idea and that it should be abandoned. Just that if the design requires more than a paragraph of explanation, then that's a serious problem for the target audience. As well as pointing out that the idea of not requiring opt-in actually causes the friction that it seeks to avoid.
If insight into the target audience's perspective is demoralizing, you honestly should stop and reconsider your priorities. I say that without any kind of sarcasm or criticism in my voice. If the people you want to help believe that the thing you're making will cause problems for them, that's a red flag. It's not always true, and it might not be true for all users, but it's something to seriously consider.
If people are worried that your product will appear to be a scam, you absolutely need to reconsider.