0

I've seen several questions that I dont think meet the standards met in the FAQ. This question seems particularly low quality to me.

From the FAQ:

what project you should do next

And:

practical, answerable questions based on actual problems that you face

And:

If you can imagine an entire book that answers your question, you’re asking too much.

This question seems like the OP hasn't actually built anything, and is asking what he should do next and he hasn't got far enough to actually encounter a real problem.

The question contains the presupposition that the only alternatives are raw sockets or HTTP. It is not "conceptual".

The requirements describe the main concern of "responsiveness" yet offer no evidence as to why these two particular protocols should have this concern. What does responsiveness even mean? Latency? Throughput? Or an ability to start downloading things before they're uploaded.

The OP states that the files are under 3MB and wants to know if the VPS will have enough memory for N connections. How can anyone answer that?

Do others feel that this question is low quality?

Could this be re-phrased to make it higher quality?

A question of this quality would have been closed on Stack Overflow

7

The "very low quality" flag is intended for questions that have severe formatting or content problems, that can't be solved by editing and/or commenting. If you can parse the question and understand what it says, it's not a "very low quality" one.

When you are flagging, you are essentially asking a moderator to take a closer look, and our job is not to judge the technical accuracy of posts. That's the community's job, and that's what up and down votes are for. If you feel the question is off topic, then the appropriate flag is "off topic", not "very low quality". If, on the other hand, you feel the question is on topic, but doesn't show effort or is not useful, then down vote it.

Lastly, regarding the question's topicality, there are some flawed assumptions in the question. That's ok, if the asker wasn't confused they wouldn't be asking in the first place. We can help correct those assumptions either via comments (which you did), or through good answers (which appeared). In any case, I agree with Thomas, I don't see any need for a moderator to intervene.

2

This question is perfectly reasonable for Programmers.

This is not a question about what project to work on next. The person asking clearly has an idea of what they want to create. That point in the FAQ is made to address questions like this one or this one, where people are actively seeking a project or want people to generate ideas. These types of questions are not appropriate.

As far as not having built anything, that's true of many questions. Questions about more up-front activities (requirements, architecture, design) along with the softer side of software development (process, project management) are very clearly on-topic here and mentioned in our FAQ as things to ask about. Choosing an appropriate communication protocol for your application that meets your requirements is clearly an architectural or design problem.

The fact that it only presents two alternatives is not an issue at all. One answer presents alternatives. In fact, two of them are good answers and the third is acceptable, but probably needs more detail to be a "good answer".

I think that most users are able to read beyond the words written and answer the actual problem of choosing a communication protocol that meets the requirements described.

  • As on all the other stack exchange sites, high quality answers do not justify low quality questions. The actually demonstrate what I'm saying is true as they say that the question is unanswerable. – Dave Hillier Feb 24 '13 at 22:56
  • @DaveHillier I fail to see how the question is unanswerable. The requirements presented are clear (at least clear enough to generate two good answers). – Thomas Owens Feb 24 '13 at 22:59
  • @DaveHillier If you feel that the question needs more detail, you should pose them as comments and encourage the asker to edit the details into the post. If you need more detail to provide a suitable answer, you should ask for that detail (and perhaps write an answer with the detail available and revise it as more information is made available to address your concerns). – Thomas Owens Feb 24 '13 at 23:00
  • I disagree thats a non-sequitur as they do not directly answer the question. – Dave Hillier Feb 24 '13 at 23:00
  • @DaveHillier Perhaps you should explain yourself in more detail. The question is about choosing a communication protocol for file/data transfer under given requirements. One answer suggests other application layer protocols, another answer suggests HTTP, and both provide reasoning as to why. Therefore, the question has been answers. Do you think you can contribute a better answer? If you do, then you should. If you need more information, comment and wait for the asker to respond. – Thomas Owens Feb 24 '13 at 23:08
  • I could contribute an answer, but it wouldn't be of the question asked, hence my question here. – Dave Hillier Feb 25 '13 at 19:10
2

None of the guidelines that you cited seem relevant to the linked question. The question doesn't ask for project ideas or suggestions, but rather for guidance in designing a specific project. The question is specific enough to be answerable, and not so basic as to require an excessively long answer.

You seem to object to the fact that the OP hasn't yet implemented anything, but the question isn't about implementation -- it's about design. The fact that the question considers only HTTP and a custom protocol is reflective of the OP's understanding of the options; there's no reason that you couldn't propose a different protocol in your answer.

A question of this quality would have been closed on Stack Overflow

If the linked question were closed on SO, it'd probably be because it's off topic there, and there's a good chance it'd be migrated to Programmers.

You must log in to answer this question.

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