Page 1 of 1

About that bug report/feature request blog post…

Posted: Sun Apr 19, 2015 8:00 pm
by 10010110
OK, I feel like I’m at least part of the reason for the lengthy blog post at ... one-right/ since this came up shortly after having a discussion about exactly this on IRC, and I’m afraid I’m on calguy1000’s ignore list already because he dismissed several of my reports/requests lately. So, here I am now and would appreciate if you took the time to read this.

I see where calguy1000 (and Anne and all the other people) is coming from but would like to add that the tone makes the music – on both sides, of course. And I have the feeling the tone of the developers responding to requests/reports could be improved a lot. I understand that programmers/IT people usually aren’t known to be particularly eloquent or empathetic in general and I also understand that they probably get really annoying requests at times but in any case the response should be more than a closed ticket with an automatic “Won’t fix” or “Invalid” label. You wouldn’t know what people in other customer support fields have to deal with on a daily basis, and yet, they still have to be friendly in order to not frighten away the customers (because that’s hurting business).

Let me recapitulate: I wrote a feature request on the CGSmartImage module’s project page where I simply asked for support of HTML5 data-attributes on the generated images using the {CGSmartImage} tag. The request was dismissed as invalid without any explanation. Asking on IRC why this request is considered invalid I got the “What’s the difference between the green and the red one?” analogy and people – not understanding how I couldn’t possibly know why it was invalid – telling me I provided too little information.

Now, here’s the thing: I consider myself a person with some common sense, and while not a real programmer (“just” a front-end developer) I try in all conscience to be as friendly and elaborate in my requests as possible. I’m just a human, however, and I’m not perfect, although constantly trying to get better, so sometimes I do make mistakes (and sometimes unknowingly). But it doesn’t help me to get better with future requests if my question/request just gets rejected without explanation. It might be convenient for the annoyed developer but overall it’s counterproductive.

I still don’t understand how a request for a feature needs a big explanation, though. After all, that’s what FRs are there for: you ask for something that doesn’t exist yet. How this is supposed to be implemented is the developer’s problem, not the problem of the person requesting. And if it’s impossible to implement or the developer doesn’t feel like implementing it at all then where’s the problem of returning exactly this as explanation for closing the ticket? And don’t put me in the “cry-murder camp” because I’m requesting an explanation about this subject. I’m not taking anything personal, I would really just like to understand, to learn, to improve. What did I do wrong and how can I do better next time?

Believe me, I’m not trying to be a dick that demands solutions served on a silver plate. But people not responding at all or responding with automatic rejections does somewhat come across as being a dick.
At least you could employ automatic replies that are a tiny little bit more elaborate such as: “Need more information”, “Too complicated to implement without much effort”, “Duplicate of …”, or “Ain’t nobody got time for that:)

Thanks for your attention (if you’ve made it through here).

Re: About that bug report/feature request blog post…

Posted: Mon Apr 20, 2015 12:23 pm
by hasanen
What I think that some of the developers does not get on these days, is that if you want to make more money or get more people to use your software, you have to deal with the customer support. Including badly presented bug reports.

Personally I don't mind to ask more information about how I can reproduce the error, of course it's damn annoying if the person on the other side is so stupid that s/he can't answer my question or give me the perfect details, so I can just spend 5 min to fix the error. If someone is willing to spend time of hers to test/use my product, why I shouldn't return the flavor and ask the questions if details not provided? I know what details I need from the user in order to fix the bug. At least I should. I don't want to be drowned of details I don't need either.

Here's some thoughts regarding the blog post and original rant.
Polite requests for more information?

I am no longer willing to politely request for days the basic information that should be provided for each and every bug report or forum post. or to teach people how to do it. If you don’t know, find out. It is not my problem (I have enough problems). I am now just ignoring forum posts without a reasonable amount of basic information or an attempt to provide it… and I close bug reports. I don’t have the time or patience to deal with half baked crap, or to teach people stuff that they as professionals should either know, or know how to find out on their own.
I do see the point of this, but if there is so much of crappy bug reports, isn't it a sign that bug reporting could be done better? For example, now there is one textarea ("Detailed Description") for describing the problem. Could there be examples/hints what to write? For example, how developer of module can try to reproduce the problem? If it's related to file, can it be shared for the developer?

Make the reporting easy, ask what you want to know. There could be link to example bug report which the developer thinks is perfect. Educate the people instead of ranting about how they should google that stuff.

And in this world, you just don't get anything on the silver plate. You have to also the shitty works or get some to handle it.
It has to be worth it

Due to the countless permutations and combinations of options, configurations, and uses for the various modules it can take a couple of hours (or more) just to setup an environment to try to reproduce an issue. (i.e: to create a new install of CMSMS, extract and install the modules, create categories, create sample data, setup summary, detail templates, setup pretty URLS, upload images) is a considerable investment of time. Your bug report has to be worth it.
Well, if one want's to make a popular module/plugin, one has also give the support for that. You live by your choices.

In overall, the blog has good points which would make developers life much easier. But I felt that the attitude was like that the person who is going to submit new FR/BR, should first read bunch of documentation about it, fair enough. But I have a question for you, how are you guiding users on that form to get what you want? I can answer for that: nothing. Yes, you ask version but it seems that it is not enough (at least for someones). And give some instructions where the info can be found. Or add some kind of automatic error reporting.
We never said it was simple for the site developer. It’s simple for the end user (your customer) to use.
So, CMSMS should be easy for end users to use and perhaps install? Modules can be installed via admin panel so it's easy. Still, you require that this non-technical user could produce high quality bug reports without any guiding? So are you saying that 60+ lady from same street should be able to install the system, but she is not allowed to tell you that your software has an error without somehow magically figuring out what info she needs to give you? At least in Finland there is mind readers.

That blog post was one step towards guiding the users. But I think you could do more. It's always two-sided thing.

This came a bit long post, but I felt I had to say something as the blog post seemed to blame just the end users where there is faults in both sides.

And by using "you" in above text, I mean developers of software/module as a general (including myself when I'm in that position), so don't think this as an attack to CMSMS or it's developers. We (developers) may have difficulties to understand what users wants/needs, but I bet they are as confused when we ask what version of php is installed on their servers.

In the end I want to say that I appreciate all work what is done to get this cms we all use. It makes my life easier in some cases. I don't use much of extra plugins and I've made few of my owns. I would like to see that CMSMS gets more users in the future as it means less bugs and more plugins.

Re: About that bug report/feature request blog post…

Posted: Mon Apr 20, 2015 1:35 pm
by Jos
hasanen wrote:Well, if one want's to make a popular module/plugin, one has also give the support for that. You live by your choices.
That may be true for commercial software, but not for OpenSource projects like this.
I never intended to make a popular module, I just needed a simple module myself that I couldn't find in the Forge. So I created it myself.

Then the feature requests and bug reports came in, which is fine. But only I decide which BR or FR I want to give attention. BR's get more attention then FR's.

A FR might be a good idea, but maybe I'm not interested in it now or short future to put my time in it for free. Maybe for later, so I just let them be. Same goes for BR's that aren't really bugs, where it works fine for me.

Re: About that bug report/feature request blog post…

Posted: Mon Apr 20, 2015 2:02 pm
by hasanen
Jos wrote:
hasanen wrote:Well, if one want's to make a popular module/plugin, one has also give the support for that. You live by your choices.
... but not for OpenSource projects like this.
Can you clarify what do you mean by saying this? I understood this like if someone wants to make popular open source software, it's not about serving the users? If you just want to release something you've made without giving any support it's fine, but I don't think you can except it to be popular.

It's ok to say that some FR's are not going to be made. It's even ok to say that some bugs can't be reproduced (because some are happening in that certain environment). It's about how you say it. Do you spend few minutes to write nice answer or just reject FR without giving reasonable reason?

And it's also a fact that some FR just are not in the scope of that software and the problem it's solving.

Re: About that bug report/feature request blog post…

Posted: Mon Apr 20, 2015 2:48 pm
by Jos
hasanen wrote:Can you clarify what do you mean by saying this? I understood this like if someone wants to make popular open source software, it's not about serving the users?
I just spoke for myself. I only serve users for free when it suits me. I have a life besides making CMSms modules ;)
If it's a paying customer, sure I would respond in the friendliest manner 8)

Re: About that bug report/feature request blog post…

Posted: Mon Apr 20, 2015 3:02 pm
by Jo Morg
There is one thing that IMO needs some clarification: what is Open Source?
Because OS doesn't necessarily mean freeware.

The whole discussion is around OS freeware which means that the developers are working on it on a limited basis:
- whenever they have the time;
- whenever they have the need;
- whenever they are being paid to work on a feature that is deemed necessary or worthwhile;
... and not in any particular order.

Just my 2cents...

Re: About that bug report/feature request blog post…

Posted: Tue Apr 21, 2015 8:20 pm
by 10010110
The thing is, I would totally have accepted that the feature I was requesting will not be implemented for whatever reasons. But it was closed as invalid and when I asked why I received stupid comments like “What’s the difference between the green and the red one?” that – to my understanding – have absolutely nothing to do with this.

So, this isn’t about whether you are obliged or willing to provide customer support but about responding to questions in a professional manner. If you don’t want to support your modules, fine. But if you do provide means of communication regarding the software then people can at least expect a hint on how to give better bug reports or feature requests rather than just “closed as invalid”. How is that helping me as questioner?

And again, according to my understanding a feature request is nothing that should require an elaborate explanation on the side of the requester. With a FR a person is stating that they would like to see some feature that currently doesn’t exist, nothing more, nothing less. In my opinion there was nothing in my FR that would render it “invalid”, and that’s why I would like an explanation what led to this decision.

Re: About that bug report/feature request blog post…

Posted: Wed Apr 22, 2015 3:45 am
by JohnnyB
For what its worth, all of the posts here have valid points and I can relate to all of them.

Each contributor to this CMS is different -- different personality, different opinions, different day job, different schedules, different coding practices, different interests... etc. So, I don't take a rejected bug report or feature request personally.
---I'm not saying that anyone here has taken a rejected BR or FR personally. But, there is some level of frustration being expressed here.

I feel it is my responsibility to get my BR / FR noticed. And, if it is rejected, than I dig deeper.

If a BR is rejected, I do my own work to find out why and to make sure I did my due diligence to understand the bug fully. And, I've been guilty of some crappy BRs.... But, on the other hand, some of my BRs have been addressed.

If a FR is rejected or disregarded, then I find someone that can do it for me or I take care of it myself. But, most often, I figure out a different way to handle the problem without needing the featured I thought I needed.