10

There is a short paragraph on the Help which I have always felt some discomfort with:

We are not a GIS Software Support Site. We encourage you to seek official routes for support for specific issues you may have.

My discomfort is because I think we provide considerable informal GIS software support but we are certainly NOT an official GIS Software Support Site.

Are there any particular "specific issues" which we should look out for and redirect quickly to "official routes for support"?

Determining these might give us examples to cite when closing some unanswerable questions and/or to enable us to expand the section above to:

We are not a formal GIS Software Support Site. We are likely to close questions and recommend you seek official routes for support if you:

  • ask about licensing, pricing and release dates (you should ask the vendor/dev team)
  • seem to be trying to submit bug reports and enhancement requests (you should submit to the vendor/dev team)
  • are not actively trying to reproduce non-reproducible software problems (you should ask/re-open them when they can be reproduced)
  • <another specific issue type>
  • <another specific issue type>
| | | | | |
  • 1
    I would change 'non-reproducible software problems' by 'non-reproducible software errors'. It will make the feedback more specific and it won't overlap with other closing reasons we already have, which might cause some confusion among reviewers. Also, when we reach consensus on this I'd suggest not only update that message in the help center, but also making it a custom close reason. – Andre Silva Oct 3 '16 at 11:42
  • One more thing, if this idea gets approved and implemented, we could have a CW post similar we have on the stats SE site: Internet Support for Statistics Software. We use it to offer an alternative to users who have specific issues about software (does not involve stats) and the question does not fit in other SE sites, such as Stack Overflow, etc. Then, when we have this support post mature, we can even use it to link with the specific close reason message. – Andre Silva Oct 3 '16 at 11:55
  • @AndreSilva I'm not seeing the benefit of using the term "errors". Are you using it in the sense of error messages only, or something else? What is your discomfort with the term "problems" here? – PolyGeo♦ Oct 3 '16 at 11:58
  • Yes, I am thinking about [non-reproducible] error messages and errors that crushes the software (as you exemplified in your first answer). My discomfort with 'problem' is that it is a broad term and the close reason could be abused/misused. – Andre Silva Oct 3 '16 at 12:04
  • @AndreSilva I think I am seeing this as support for the "Other" close reason rather than as a justification for a fourth custom close reason. Either way I think we still need to do quite a bit more before it is in shape for either. Thanks for working on it. – PolyGeo♦ Oct 3 '16 at 12:17
  • @AndreSilva I think you should feel free to develop a Q&A here similar to that which you have on Cross Validated (i.e. Internet Support for Statistics Software) but I think doing that should be decoupled from this Q&A, even if it may later be linked into from what comes out of this. – PolyGeo♦ Oct 3 '16 at 22:30
  • @AndreSilva Any close reason could be abused/misused but we have Geographic Information Systems Meta available to work through their wordings to try and keep them clear and functional e.g. meta.gis.stackexchange.com/questions/4089/… – PolyGeo♦ Oct 3 '16 at 22:34
  • I just implemented this 10:0 proposal and the two answers that had achieved 6:0 up/down ratios. Endorsement on whether non-reproducible problems need to be included is not there at this time. – PolyGeo♦ Oct 27 '16 at 23:50
6

For commercial software, most licensing-related problems are a good candidate for this.

Even though the community can often help the asker get closer to a solution, these problems often require a call to the vendor to resolve because the vendor is responsible for licensing and they can know things about the asker's licensing status that we can't possibly know, or resolve even if we did know.

| | | | | |
  • Are you thinking that we may need a new custom close reason that incorporates this category? Or would it be already covered by using or extending an existing close reason? – PolyGeo♦ Sep 23 '16 at 19:54
  • I don't know that it comes up often enough to need either, I usually vote to close for the "This problem cannot or can no longer be reproduced" reason and also add a comment to the asker telling them their quickest solution is probably going to be to call the vendor. Maybe that paragraph in the help should be expanded. – Dan C Sep 23 '16 at 20:16
  • 1
    I think I would be more inclined to use the "Other" option and say something like "I'm voting to close because this is best answered by the vendor rather than outside opinion" (which might make it fall under the opinion-based close reason). – PolyGeo♦ Sep 23 '16 at 20:34
6

I think that GIS SE should NOT be used as a means to try to submit bug reports and enhancement requests. I think this position has been endorsed in a Meta Q&A on What should we do with bug reports? so it probably just needs to be formalized in the Help.

To try and prevent any misunderstanding in what I am saying in this answer, I need to say that I think GIS SE is invaluable for developing procedures to reproduce bugs and to validate use cases for enhancement requests. However, it is NOT the place to SUBMIT them.

Remember that whenever you post here you are addressing the GIS SE users and visitors (in the same way that Wikipedia addresses its audience) and so, even though developers from various GIS software development teams may be reading your questions, the Q&As are not a formal conduit to them.

When I submit ArcGIS bugs to my local support I will often verify my understanding of an issue through a Q&A here first and then use a link to that as the bulk of my submission. The Q&A is directed at the community as something of a sanity check, then the Q&A is submitted in support of the bug report to the software developers (via support). By doing this our community and its site visitors get to understand the issue (and workarounds, where possible) but the software developers clearly get the responsibility to resolve it.

| | | | | |
  • How is this answer different from the other one? One is about 'errors', and this one is about 'bugs' (and enhancement requests)? Is that it? I am trying to understand why you posted as separate answers, probably because each is a different 'specific issue type'. The motivation of my confusion is because 'error' and 'bug' (both in subject and questions we have on GIS) are very related, in which sometimes the error comes from a bug, and sometimes a reported bug is not a bug, but an error due to some known cause. Could you clarify on your answer? Tks. – Andre Silva Oct 1 '16 at 23:31
  • To be verified as a bug a procedure is needed to be able to reproduce it. Bugs are the responsibility of the developers of a software to resolve using a software fix (preferably) or via documentation. This is quite distinct from an issue which is reported but non-reproducible. While something is non-reproducible it may be a suspected bug, but it may equally well be down to a user's procedure or data. A non-reproducible issue remains the responsibility of the user to come up with a reproducible procedure. – PolyGeo♦ Oct 2 '16 at 0:10
  • The above notwithstanding, a developer or support team may be concerned enough about something non-reproducible reported as a suspected bug to try and reproduce it themselves, perhaps to prove their software "innocent" rather than assumed "guilty", and there may be some obligation on official support teams to do this as the intermediaries between users and developers. However, we are not about formal Technical Support and consist of volunteers, so we do not have the obligation to keep such reports on our books as unanswered questions. – PolyGeo♦ Oct 2 '16 at 0:14
  • 1
    I'll see if I can work the above two comments into one or both of my answers but when we are talking about formal (developer, support team) vs informal (user, peer-to-peer) support I see a very clear distinction i.e. two specific issue types. – PolyGeo♦ Oct 2 '16 at 0:18
4

My perception of this is that We are not a GIS Software Support Site is not absolute.

As @Evil Genius pointed out, open source projects such as QGIS may not have an official support, and may use the Stack Exchange network as a support platform.

The main StackOverflow site has recently started Documentation, which almost exists to address the shortcomings of the official (or lack of official) support channels.

We could probably revise this to say We are not a GIS Software Support Site for unreproducible problems/license problems/too-broad problems/debugging problems. But that's a separate question:

What is it exactly about GIS support that we are not for?

| | | | | |
  • Your answer ends in a question which has me wondering why that question is present. Is it meant to reinforce the question that I asked or something else? I think it is always best for answers to consist of statements only, and for questions to be asked in questions. – PolyGeo♦ Sep 26 '16 at 11:59
0

I think non-reproducible problems should not be left open once they cease to be actively worked on and edited by their asker, because by then they are likely to simply contribute to our backlog of 18,000 unanswered questions.

A developer or support team may be concerned enough about something non-reproducible, that has been reported as a suspected bug, to try and reproduce it themselves, perhaps to prove their software "innocent" rather than it being assumed "guilty", and there may be some obligation on official support teams to do this as the intermediaries between users and developers. However, we are not a formal GIS Support Site and we are all volunteers, so we do not have any obligation to keep such reports on our books as unanswered questions.

I'll use an example from our second most frequently used tag of ArcGIS for Desktop () which is questions about Serious Application Errors (but questions could perhaps be included here too).

Serious Application Errors are likely to be very hard to reproduce using our focussed Q&A format, and to be analysed properly, and then fixed, will probably need the involvement of their developers or the support teams of those developers.

Rather than have them hang around like "broken windows" on our site I would like to propose that such questions be put on hold soon after they appear (and be closed a few days later) using our custom close reason of:

This problem cannot or can no longer be reproduced. Changes to the system or to the asker's circumstances may have rendered the question obsolete, or the question does not include a procedure to enable potential answerers to reproduce the same symptoms. Such questions are off-topic as they are unlikely to help future readers, but editing them to include more details can lead to re-opening.

If any such questions are closed in this way, which can actually or later be backed up by a reproducible procedure then, if their asker can include more details to show how, they can always be re-opened.

| | | | | |
  • 3
    Another thing to consider is why users are ending up here in the first place. For QGIS, it'd probably be worthwhile to work with the dev team to update the QGIS website, which lists GIS.SE under support and says "QGIS does not have a forum. Please either search in StackExchange ..., or via nabble.com in the history of our Mailinglists ...", to add some guidance as to what questions should go where. – Evil Genius Sep 21 '16 at 11:38
  • 1
    Licensing issues – Midavalo♦ Sep 21 '16 at 12:15
  • Two concerns: i) we'd need to narrow and be very clear about what types of questions fits in (so to avoid disputes and inconsistencies); ii) somehow have a clearer custom close reason/message, because the one you cited is unclear for such purpose. We could ask one more slot for the dev team. Or append a new message at the end of that message. – Andre Silva Sep 21 '16 at 13:15
  • @AndreSilva I think that close reason is crystal clear when applied to my two examples: "the question does not include a procedure to enable potential answerers to reproduce the same symptoms" – PolyGeo♦ Sep 21 '16 at 13:44
  • @AndreSilva The current wording on that custom close reason only has 8 characters to spare and I think it is already saying what it needs to so I cannot see a case to expand it. I think it is possible to ask for another custom close reason (to maximum of 5 I think) but I don't think the issue here warrants that. – PolyGeo♦ Sep 21 '16 at 21:31
  • @EvilGenius Hopefully users who are part of the QGIS dev team will see this post. I would prefer some, not much, change to the way support via GIS SE is described on the QGIS support page. Perhaps someone can raise that as a separate Meta Q&A. – PolyGeo♦ Sep 21 '16 at 21:38
  • 1
    @Midavalo Some licensing issues and all pricing issues seem like good candidates for another answer here. – PolyGeo♦ Sep 21 '16 at 21:39
  • @AndreSilva I think the current Non-reproducible wording already gives us the tool we need for this answer. The question asked is about providing some clarity around what "We are not a GIS Software Support Site" actually means and this answer is about providing two examples of how and when Non-reproducible can be used to support its invocation. Its all part of trying to tame the nearly 19,000 unanswered questions quickly, cleanly and consistently with community support. – PolyGeo♦ Sep 21 '16 at 21:44
  • 1
    While I like your question, the answer is still broad to me. I'm fine with the arcgis example, but not sure about the qgis side. Moreover, I'd like to see a specific closing reason for this issue, and that we would only close questions with very user-specific (local) errors. My main concern so far is using a pragmatic approach for closing more questions than we should. I will try contributing more with an aswer, asap. – Andre Silva Sep 21 '16 at 22:51
  • 2
    @AndreSilva If anyone high on the top QGIS answerers list wants to chip in on whether the QGIS example is not appropriate, then I'll be happy to exclude it from my answer. I know ArcGIS for Desktop far better than QGIS and only included the second for balance and because I think it is analogous. – PolyGeo♦ Sep 21 '16 at 23:00
  • @AndreSilva I've edited the QGIS example out of this answer because no one has indicated whether it is a good/bad example of something likely to be non-reproducible, and I (like you) am not certain. – PolyGeo♦ Oct 3 '16 at 0:07
  • Besides the 'problem/error' thing I commented under the question; I still would like to see that part of 'this problem cannot or can no longer be reproduced' removed from this answer, because it is not quite accurate for the whole issue about 'support' we are discussing here (plus, to me that message is still very broad for the specific issue of this answer). Therefore, I believe having a close reason like the one we are making at the bottom of the question would be much more accurate, and users would understand better why a question was put on hold/closed. – Andre Silva Oct 3 '16 at 11:50
  • I agree that for QGIS this could be the minidumps (crashes) for example. Or anything else which indisputable can be flagged as a bug and is not subject to individual judgement. The later case is sometimes hard to tell from a question author perspective (I expect a to happen when I do b. But I don't know that c is also a prerequisite. And only c makes it a question suitable for gis.se which I am unable to judge because of my lack of knowledge). That's the blacklist for questions. A whitelist OTOH might be that a question is related to concepts rather than individual local problems? – Matthias Kuhn Oct 3 '16 at 14:32
  • @AndreSilva I'm not convinced that we are trying to make a new custom close reason. I know that I asked this question to try and clarify what we understand by the statement "We are not a GIS Software Support Site". At the moment I think the reasons questions are closed on this site are already covered using the existing close reasons, but why they are applied is not always understood, particularly by new users, and so I want to be able to point back at a clearer help center page without developing long lists of close reasons. – PolyGeo♦ Oct 3 '16 at 22:18
  • The on topic help page would be a longer text than a specific, individual close reason attached to the closed Q (I am not against changing there either). It is clear we don't have a custom close reason for licensing issues and bug reports, for example. The way I see, that close reason in your answer is only tangential to support; because although it partially fits explaining about non-reproducible errors, its recommendation about what to do is vague. It is often used for Qs with typos, software that became obsolete, OPs who quickly find answers and post them as comments. – Andre Silva Oct 3 '16 at 23:08

You must log in to answer this question.

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