Could you change the way you answer issues on this module please?

First of all, I appreciate you telling me this :)

I understand your point of view. However, put yourself in my shoes for a second. I've been working on this module for years now. Time after time, I'm getting bug reports in my queue that truly are caused by other modules. Dozens of them.
Not to mention the multiple of those dozens of issues that were because of users not reading the documentation or simply blaming HS for something HS doesn't even touch.
For HS, there simply have been *so* many unnecessary issues :(

The first answer you list, I only give when I'm 95% certain it's something that's been fixed a long time ago and surely, somebody would have mentioned earlier because it would have affected everybody using HS. However, I've indeed been wrong several times in the past few weeks (months maybe).
The second answer you list, I've explained in my first paragraph.
The third answer you list, is similar to the first.

I guess I *should* be less dismissive. But trust me that it's extremely frustrating to keep seeing similar bug reports. To never be able to deliver something that's almost flawless. Because the basis it's built upon (Forms API) is so flawed (because it wasn't designed for AHAH form elements). I do have humility. I don't have endless patience and endless amounts of free time. To fix all the weird problems that keep popping up, I do need endless amounts of free time.

Now, I do understand that my hostility/dismissiveness is not a pleasant experience. But you'll see, when users post thoroughly written issues, possibly even with screenshots or screencasts, I'll answer with a very different attitude. I will try to improve my first posts to be more objective. I took the first step in that a week ago, when I started using an application for inserting macros. You'll often find this in the issue queue from now on:

Can you reproduce this on a vanilla Drupal site? If you cannot, keep on adding modules that you're using on your actual site until the problem is reproduced.

When you're able to reproduce this (on a vanilla Drupal site with the minimum number of modules to reproduce it), then please make a screencast of:

1. your site configuration
2. the problem being reproduced

That makes it easier for me to reproduce the problem. Thanks!

P.S.: don't have any screencast software yet? On Windows and Mac OS X, you can use the free Jing.

Do you have any feedback on the wording of that? :)

I have a lot of sympathy with Wim in this situation. Yeah, he's been known to get a little cranky but there is a LOT of garbage in these issue queues.

Wim already knows my opinion on HS as I've stated it clearly at least twice - and I also think it's the reason for a lot of the bugs on HS: the module has become a frankenstein's monster, way way over complicated and the original goal of the module has been left many miles behind by everyone and their uncle's infinite requests.

There needs to be a clear division between a very basic HS module and everything else in other side modules. There has been some attempt to do that, but the core module itself is too big and too complicated and that's why there are so many clashes with other modules. If someone who could code better than me would step up and put together HS Lite, I'd sponsor it in an instant.

Thanks esilou. That at least confirms I'm not distorting the reality :P

HS is indeed WAY too complicated. For two reasons:
1) Forms API sucks. It's AWESOME for simple and somewhat advanced cases. But it's just not designed for AHAH forms, let alone AHAH form elements. This is why there's HS' own form cache and why there is so much weird code: I had to find "sort of bugs" in Forms API to even get HS to work. Because nobody likes patching core (and that's a good thing of course!). merlinofchaos strongly agrees with me on this, and when I talked to eaton about it, he also agreed.
Yes, I know, the right behavior for me would have been to propose changes to Forms API. Create patches, convince others to get them in. But that takes time. A lot of time. Time I don't have. Remember, I'm doing all of this in my free time, after finishing work for my university studies. There have been many paid features over the past 1.5 year, but I've spent another multiple of that time of my free time.
Trust me, this kind of work sucks the happiness out of you, it wears you thin.
2) Organic growth without much refactoring. I've been adding features as they were requested, without having the time to rewrite the internals to properly suit that.

HS 4 should be a rewrite to improve the internals. It's insanely complex and not unit tested, so bug fixes are too likely to introduce other bugs/regressions. And to make it core worthy. Many core developers want this in core. But the code isn't good enough. And we don't have any amount of unit tests worth mentioning.
A year ago, I thought HS 3 would be a few weeks of work. Yes, I should have done more beta releases. But time constraints prevented me from doing this. (I intend to make new releases in the next week.)
Right now, I can't justify spending another TON (like, at least 40 hours, probably double that) of my free time on HS 4. But if there would be people willing to sponsor it, then I'm definitely interested. Because the potential of HS is huge. If we'd get it in core, it could be used in more locations in core. Without ugly form alters and messing with module weights.

having been on the same side of the issue queue as hythyth, I can sympathize with him a little. But I think Wim Leers' responses are perfectly reasonable. We're all adults, and with limited time. If there is a situation where it is a server issue or w/e, then it would be pretty much impossible for Wim Leers to discover and almost certainly would waste a whole lot of his time.

The onus is on the tester to rule out the possibilities and isolate the problem. Like other things in life HS is innocent until proven guilty. So I think, yes Wim Leers is a bit dismissive, but it's probably the most efficient way to deal with the issue queue, for everyone.

And lol, apparently you don't hang around the panels or views issue queue, talk about being treated curtly.

Exactly. Sure, "it doesn't take *that* much time to set up a demo site to reproduce the problem". Hardly ever is it less than 15 minutes of work. And then I still have to start looking for the cause. In the beginning, I spent hours (too many hours) believing that it was HS' fault, only to find bugs in other modules.

I appreciate your understanding, esilou and Flying Drupalist! I hope hythhyth can, too. :)

Interesting issue, as a maintainer I think about this sort of stuff as I've often been in denial about bugs in my modules before I realised it was indeed my fault. Now if I'm not convinced by the original issue, I try and explain that I need to be convinced it is my fault a bit more :P Can't fix it if I don't see it, and since I'm the one that caused the problem I'm predisposed to not seeing the problem, or not seeing that it is a problem.
And yeah it doesn't help that there are bogus issues in the mix, as well as compatibility problems from other modules, or people just not understanding the design of your module.

And lol, apparently you don't hang around the panels or views issue queue, talk about being treated curtly.

Indeed.

I also think that dismissing some issues initially, and letting them come back through popular demand, is a valid strategy for maintaining a large issue queue.