8

I refer to this question:

https://drupal.stackexchange.com/questions/80033/please-help-understanding-subdomains-module

In one form or another I think this is the 3rd/4th/5th version of this question from the same user in the last week or so.

Now, we have a strict 'module bug reports are off-topic here' policy. We enforce this quite rigidly, and with 4 close votes on it that question will soon join the pile of off-topic bug reports. This is fine, all in line with expectations.

However

Since the OP has been so persistent in re-posting the question I went to check out the issue queue of the module in question. The module status is 'Currently seeking maintainer', and there are quite a few unanswered bug reports that date back some time.

Let's put aside for a moment the fact that the question itself is currently badly presented; let's assume in good faith that the OP will add the necessary amount of detail to the question, and improve the quality so it comes up to our usual standards.

Should we then accept the question?

Please note, I'm not advocating an answer either way, I'm just interested to hear people's opinion on this. I'm specifically speaking of modules that have become abandoned, or where authors don't respond to bug reports in a reasonable timeframe (maybe a few weeks or something, details are irrelevant compared to the big picture I think).

Is there a way to accept these questions, make them up-to-code and on-topic, or are they fundamentally at odds with what we want to see here?

1

5 Answers 5

8

TL;DR Questions that arise during module or theme development and maintenance should be considered on topic no matter if there is a bug report or not. Only questions about module bug in usage should be redirected to issue queue.


As I see it, if OP would try to fix a bug in a module and encountered a problem during the coding, it would be perfectly on topic. After all, we already help with module development here, so it shouldn't matter if OP was the original author or is simply patching work by others. Even "what's wrong with this code, I expected it to ..., why i get ... ?" if OP shows he really tries to understand code, at least to the point when he can identify probable points of failure, may be a good on topic question.

Asking how to possibly get X functionality in other means than buggy X.module can be pretty good too, there often are more modules / solutions to a problem.

Plainly asking people here to fix a bug would be nothing more but request for a free code writing service.

9
  • Interesting take on it, as above I wonder how we'd define where the imaginary 'line in the sand' is
    – Clive Mod
    Commented Jul 23, 2013 at 14:37
  • Are you saying that problems encountered during module DEVELOPMENT are OK, but bugs encountered when using a module are not? If so, then I totally agree!
    – Chapabu
    Commented Jul 23, 2013 at 14:37
  • 1
    @Chapabu During both development and maintenance, yes, they are OK, during usage not OK. That's how I see it.
    – Mołot
    Commented Jul 23, 2013 at 14:42
  • Seems reasonable! I'm in agreement with this totally. However - and this is probably another question for discussion later on - how do we deal with module maintenance/development when the issue is vanilla PHP based? I would suggest those are closed, but then we run into a similar issue.
    – Chapabu
    Commented Jul 23, 2013 at 14:45
  • @Chapabu first offtopic reason is "should be asked on stackoverflow", right?
    – Mołot
    Commented Jul 23, 2013 at 14:47
  • At face value, yes. However - say OP then comes back with a Drupal specific problem in their code. All of a sudden, they are having to ask for help in two separate forums (StackOverflow and DA).
    – Chapabu
    Commented Jul 23, 2013 at 14:50
  • @Clive after some edits to my post do you feel your concerns answered? And can you agree with my point of view or there is something I should reconsider?
    – Mołot
    Commented Jul 24, 2013 at 7:02
  • Yes I do agree - so in summary, your opinion would be that the question-in-question should be closed? Just to make sure I completely understand
    – Clive Mod
    Commented Jul 25, 2013 at 13:08
  • 1
    @Clive I would prefer to see it edited to an more acceptable form, like "why does this part of code fail to work?" or "I copied taxonomy functionality but can't adjust it to work on users instead, what to change in this part?" but in the current shape, yes. Not that I like what it might mean to OP (I hadn't realized it was not his first question on that topic). At first glance it was reasonable one, if broad.
    – Mołot
    Commented Jul 25, 2013 at 13:32
3

Not speaking about that question in particular, I think that there are a few cases where questions could be on topic here.

There are some issues in code and contrib that have been in the queue for a very long time and show little hope of ever getting fixed (eg, the issues holding up Secure Pages). In these cases, I think that questions about workarounds for the bugs are on-topic.

7
  • Very much agree with this, Secure Pages is a great example of what I'm asking about - those bugs ain't ever gonna be fixed by the module maintainer so we'd probably be doing the community a favour by accepting it here. The subdomain module (the module in question) isn't that abandoned but I'm wondering how we can define exactly where the line is. Maybe we can't, maybe it has to be done on a case-by-case basis
    – Clive Mod
    Commented Jul 23, 2013 at 14:33
  • I'm going to have to respectfully disagree. If the issues can be answered, then they belong in the queues. That's the first place I go if I ever have any bugs. If there is a workaround for a contrib module bug, then the workaround should be addressed/highlighted in the issue queue.
    – Chapabu
    Commented Jul 23, 2013 at 14:34
  • As an attempt at an analogy - if you are having a problem with a Nissan and get no help from Nissan after a few weeks, you don't take your problem to a Volkswagen dealership.
    – Chapabu
    Commented Jul 23, 2013 at 14:36
  • @Chapabu Hmm I also agree with that. Well this isn't going to get solved any time soon :)
    – Clive Mod
    Commented Jul 23, 2013 at 14:36
  • @Chapabu If your Nissan is broken, and the dealer has refused to fix it for two years because the mechanics can't decide on a solution and want to work on the later models first, you don't hang around in the waiting room asking for help. You take it to Jimmy's Auto Repair.
    – mpdonadio Mod
    Commented Jul 23, 2013 at 15:49
  • @MPD haha! Touché :)
    – Chapabu
    Commented Jul 23, 2013 at 15:52
  • @MPD Well taking it to Jimmy's Auto Repair is analogy of hiring a contractor, and asking in the waiting room ~= asking here, doesn't it?
    – Mołot
    Commented Jul 26, 2013 at 12:24
1

I still think it should be directed to the relevant issue queue. If anyone from this site knows the answer, chances are they have a d.o account and can answer the question there.

This way it keeps any module-specific issues in the issue queues.

7
  • 1
    Personally, this is my opinion too. But at the same time we have a wealth of knowledge here and it seems almost 'mean' to push people away on a technicality. I don't expect anything will change with regard to this but I'm interested to know what the general feelings are
    – Clive Mod
    Commented Jul 23, 2013 at 14:04
  • 1
    I see your point, but we're not pushing them away from here so much as pushing them TOWARDS the framework-defined location for module issues. It's also a slippery slope for having this become the norm on this site.
    – Chapabu
    Commented Jul 23, 2013 at 14:10
  • Yeah the slippery-slope argument is the main reason I don't see this having a happy ending for the OP. I'm trying to help avoid any ramifications on the OP's account for continuously re-posting deleted content, and see if there's a middle ground anywhere. But I'm not too optimistic, unless someone's got some brilliant insights
    – Clive Mod
    Commented Jul 23, 2013 at 14:12
  • 1
    @Clive all it takes is one person that will actually start to edit module's code, and will ask questions "from the inside". After all we help with bugs in OP's modules all the time.
    – Mołot
    Commented Jul 23, 2013 at 14:30
  • @Mołot Agreed, I guess if an OP was clever about it they could easily mask the fact they're working on a contrib module.
    – Clive Mod
    Commented Jul 23, 2013 at 14:38
  • 2
    @Clive New close reason for DA "OP was too sneaky" ;-)
    – Chapabu
    Commented Jul 23, 2013 at 14:38
  • 1
    @Clive I don't think any masking is needed - if someone actually tries to fix a bug, even if he fails right after reading module's source code, asking questions seems OK and on topic to me. Some may be redirected to stackoverflow, of course, but "how to rewrite that hook in X.module to get ..., I did ... but ..." is way more valid than "Module X has a bug, help me".
    – Mołot
    Commented Jul 23, 2013 at 14:46
1

I don't know, I should give my opinion here or not, but still I am writing.

If a question is well presented and can explain the situation which a user is facing while using the module then it should be accepted even if it reports bugs for some module which is seeking maintainer or maintenance is abandoned. Because at the end that particular user is looking for help & this is what we are doing here...

Other part of this question is, many of us don't use many good modules & most of the times I come across modules which are amazing. So these questions give us info about various module & if it's not being maintained, someone from us can popup and go for taking the responsibility or resolve the issue if no one is looking into the issue queue.

There are whole lot of modules which are seeking maintainer or not being actively maintained, have lots of bug, issue queue not resolved but I don't think it will be good idea to not accept question related to bug report of those or module configuration about them if the question has got quality & it's descriptive..

5
  • 1
    Because at the end that particular user is looking for help & this is what we are doing here... That's not actually the primary objective of Stack Exchange sites, strange as it might sound. The objective is to create a repository of high quality questions and answers - helping individuals out with their specific problem comes secondary to that, although it's obviously a nice side-effect when it happens. That's the main thing that distinguishes us from support forums; if we were a forum then I'd agree with what you're saying 100%. But SE have fought long and hard to make sure we're not :)
    – Clive Mod
    Commented Jul 25, 2013 at 13:18
  • 1
    BTW Adding your opinion is very much welcome, and most encouraged. The more people that come here and put down what they think, the easier it will be to talk about subtle shifts in policies, if they become appropriate
    – Clive Mod
    Commented Jul 25, 2013 at 13:20
  • Ok, then I am wrong but that what I think when I answer & expect when I ask question. Then may be not exact bug report but if requirements are explained then it should be accepted.
    – RajeevK
    Commented Jul 25, 2013 at 13:20
  • Ah, if it's not a bug report then we're possibly talking about different things. I agree there can be a grey area there
    – Clive Mod
    Commented Jul 25, 2013 at 14:04
  • If requirements are explained and OP is open to totally different solutions that would meet them, it should be OK. That's what I meant in 2nd paragraph of 2nd section in my answer. And nice you answered! Every point of view has it's value, if we agree with it or not.
    – Mołot
    Commented Jul 26, 2013 at 14:00
0

If the question were "I get the following error message from the X module. What should I do?" then it should be considered off-topic. If the question were "I need to write a new module I want to use instead of X module, which has a bug, but I don't know why the following code is not working. What code should I use?" then I think the question would be acceptable.
In the first case, the topic is the bug; in the second case, the topic is writing the code for a module that would be used instead of another module. The fact the user was prompted to write a new module because an existing module is buggy is marginal for the question, which is still about what code the user should be writing instead of the not working one.

I don't think we should look at the last time a commit was done for the involved module to decide if a question is off-topic or not. What would happen if the module maintainer would fix the bug 10 days after the question was asked on Drupal Answers?

Also, the answer to the first kind of question is generally "Use a different module, or write one yourself." If the user wanted some tips about writing a new module to replace the one that contains the bug, I am sure the user would be able to ask a proper question that is not the generic "I get the following error code from X module; what should I do?"

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .