I'm asking because I saw this question Undefined offset: 1 in gcm_action_send_message()

This to me looks like a PHP error that's caused by a bug in the contrib module and should be filed as an issue. I could be wrong, but in general is this the place to be asking things like that?

The correct answer to me is that the module should be patched so that it doesn't throw errors regardless of whatever bung configuration the administrator has entered through the Drupal UI.

The "correct" answer as selected by the user asking the question will be workaround rather than a working patch more likely than not.

The bug may never be reported to the module maintainer and may go unnoticed for much longer than necessary because of the available workaround on Stack Overflow.

Should we be leaving comments on bug-report style questions (or even closing them) telling users to open an issue with the maintainer on the d.o. project page and request support from there before polling for workarounds on SO?

  • 1
    I don't have time for a proper answer to this, but you can't use the answer to determine whether a question is on-topic. If the question is indeed the result of a bug, an answer should also mention to file a bug report in the proper queue. But just because it is the result of a bug, doesn't make it off-topic. – mpdonadio Jan 17 '13 at 19:17
  • 1. I don't agree that just because a user doesn't know the exact answer to a question that they'd have no inkling of the type of answer they'd be receiving. If the expected answer is a patch, or adding missing documentation then it should be in the issue queue. – David Meister Jan 19 '13 at 13:18
  • 2. I didn't say that just because it's a bug it should be in the issue queue, I'm saying what do we do with bug reports that should clearly be in the issue queue – David Meister Jan 19 '13 at 13:18

If there is a bug in a module, then the discussion should be in the relevant issue queue for the module, not on DA. This is mentioned in the FAQ on the main site.

Most questions that relate to a module bug will be closed as off-topic because of this.

I suppose the only possible exception would be if there is no relevant issue posted in the issue queue, but in that case the question would probably still be closed and a re-post to the issue queue would be suggested.

If, however, the question is how to problems implementing working functionality of part of a module (for example, if the question you reference was more of a "I'm trying to call function X in module Y, but I'm getting an error - am I doing it right") then that's probably safe.

  • I'd argue that if there's no relevant issue in the queue yet it is even more important that the bug is reported. – David Meister Jan 17 '13 at 12:59
  • That's why I said "the question would probably still be closed and a re-post to the issue queue would be suggested" :) – Chapabu Jan 17 '13 at 13:00

Bugs should be reported on the module's issue queue, as a question on Drupal Answers about a bug in the code would not be much interesting for future users, essentially because there is nothing much that can be done about code bugs, if not reporting them to the maintainers of the module. Also, once a bug has been fixed, the question would stop to be of any relevance.

That said, the question you link is not about a bug in the code, but rather missing, or incomplete documentation about the function the module exposes to other modules. Knowing how to correctly use a function could have more interesting for future users, considering that normally a module is written with compatibility in mind. Eventually, the question could not be interesting for the users using a different version (e.g. 7.x-3 instead of 7.x-2), but the question could be interesting for who is using the same version.

To make a summary:

  • Questions about how to use a class/function/method exposed from Drupal or third-party modules are allowed, whenever the documentation is missing, incomplete, not clear, or complete

  • Questions similar to "I installed the [X] module, and when I enabled it I got an error about accessing a property for something that is not an object" are not allowed

If the documentation about a class/function/method is not complete, or not completely clear, a bug report can be opened in the issue queue of the project involved, but the question on Drupal Answers is acceptable, and not closed.

  • 1
    I consider undocumented functions a bug in the documentation. drupal.org/node/1354#functions - "All functions and methods, whether meant to be private or public, should be documented. A function documentation block should immediately precede the declaration of the function itself. " – David Meister Jan 17 '13 at 14:33
  • Questions about a function for which the documentation is not clear, or inexistent, are allowed. Questions where the OP says "I installed the [X] module and I am getting an error about accessing a property for something that is not an object" are not allowed. – kiamlaluno Jan 17 '13 at 17:20
  • Ok. Is there some kind of standard to say that once the user has figured out what the function does, they should be encouraged to file a patch with a doc block for that function? – David Meister Jan 19 '13 at 13:20
  • You can suggest that to the OP; there isn't a standard for that. Consider that such patch can be filed from everybody; the fact a user asked a question about how to use the function doesn't make creating the patch her/his responsibility. As the user didn't understand the purpose of the function, s/he is probably the last person who should provide a patch; that user could open a issue report for the module, but the patch should be provided from somebody else. I would also not like seeing that, for every question about a function, somebody suggest to file a patch for a module. – kiamlaluno Jan 19 '13 at 13:33
  • I'm talking about functions with no existing documentation. Not that we should just write comments about every question. If the question is "what does this function do and what is the structure of the parameters" then it would be great to see that turned in as a patch in the queue. I don't think it's fair to say that because somebody previously didn't understand a function they aren't qualified to write the documentation once somebody explains it to them. Just a few weeks ago I filed a patch for Aegir documenting a function that I had NFI how it worked 2 hours prior.. – David Meister Jan 19 '13 at 13:38
  • Still, asking a question about how to use a function without documentation doesn't make the OP responsable for providing a patch for the module implementing that function. The OP could arge that who answered her/his question should provide a patch. In short, you can suggest providing a patch, but the OP could also decide not to provide a patch. If s/he is involved enough with modules/Drupal development, s/he could decide to provide a patch; if s/he is not much involved in the developing of modules hosted on Drupal.org, s/he could think not to be the right person for doing that task. – kiamlaluno Jan 19 '13 at 13:48
  • So sad. Wouldn't it be great if people just submitted patches as soon as they realised: A - Something is wrong B - I have the ability to do something about it C - It will take less than 15 minutes to roll this patch – David Meister Jan 19 '13 at 13:51
  • 1
    @DavidMeister It would take less than 15 minutes to roll the patch for you too. I have committed some patches when I saw the documentation of a Drupal function that was not correct, or when I saw the code of a function that should be fixed; I have never said to the OP to make a patch for something I noticed while looking for the answer of her/his question. – kiamlaluno Jan 23 '13 at 14:55
  • I already spend a reasonable amount of my free time rolling documentation patches for other people's problems. I don't have time to trawl DA looking for all questions that could be patches. I do believe a decentralised approach would be more efficient in this case. – David Meister Jan 24 '13 at 2:13
  • @DavidMeister Who asked the question on Drupal Answers could not have the time to create a patch too; the same could be true for who answered the question. People who contributes to Drupal do it freely, not in virtue of questions asked on Drupal Answers. Trying to get more Drupal contributors is fine, but it is probably better to bring their entusiasm. – kiamlaluno Jan 24 '13 at 2:59
  • I think it's pretty clear that we're going around in circles here - you see documentation as something separate to code, whereas I see missing documentation for functions in a module as an obvious bug in the code itself. If you see missing documentation as a bug as I do, then it seems natural to tell people to open an issue in the queue for the benefit of the maintainers. Creating the patch is obviously optional, but I feel it should be encouraged. If you see documentation as independent of code as you do, then it doesn't matter whether the documentation lives on DA or DO. – David Meister Jan 24 '13 at 8:53
  • @DavidMeister As long as the topic is providing a patch, there isn't any difference between patching a PHP file, or patching a plain text file. (I will leave out the fact that most of the documentation on Drupal.org API is extracted from comments in the Drupal source code.) Drupal documentation lives on Drupal.org; asking questions on Drupal Answers, or answering them is not making documentation. – kiamlaluno Jan 24 '13 at 9:07

You must log in to answer this question.

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