> There are like 8 macros...
I should have used quote / unquote instead of the word macro.
When I looked into the code I started with the engine and renderer. Between both modules they had dozens of quote / unquote usages which to me was hard to follow. Not because it's written poorly or anything like that, but it's not exactly easy to trace that code to learn how something works in more detail.
> I mentioned a solution after the issue was closed - and not before as you describe.
Yes, after it's been closed. But look at it from what end users of your library see from that chain of events:
1. User asks question on forums and presents a case where something very bad happens (2x network round trips)
2. User posts issue on GitHub
3. Creator of LV says it's a known trade off and quickly closes the issue
4. You and the creator of LV talk offline and figure out a potential work around
Re-opening the issue after #4 would have done a lot of good because it shows at a glance that it's a current issue, it's being addressed and open for discussion.
With the issue being and staying closed this gives off a message that you're not actively working on fixing the bug and aren't open to any form of discussion or assistance around fixing it. Maybe that wasn't your intention but that's the message you're sending to some people.
> Seriously?
That's the answer I've always received in the past when asking questions about the state of the docs on Slack and IRC over the years. The current docs usually give you a partial understanding of how something works. It's usually enough to get a basic idea of how something might work but not enough to get the ball rolling to implement a solution in your own application. I don't think I'm the only one who feels this way either because I've seen a lot of repeated questions on IRC and the forums, especially around LV components.