Should we direct questions to Server Fault?

@Manuel I should have been more clear in that I meant that we should suggest all questions not appropriate for SO to be posted on the forum rather than suggesting some go to Server Fault.

Inappropriate questions definitely shouldn’t be directed to SO as that doesn’t help our community if they just get closed - even if they often don’t it still doesn’t help the SO community. Equally directing some questions to Server Fault where on the parse tag there is a low existing knowledge base and questions are unlikely to be answered by the Parse Community.

Thoughts?

1 Like

I’d redirect to Server Fault deployment related questions, like how to setup a reverse proxy, how to horizontally scale push notifications, etc…

I understand the concerns that directing questions to a forum where one is unlikely to get an answer wouldn’t make much sense, but I challenge the assumption, that a network related question would not get appropriate attention on SF.

According to SE guidelines:

  • The appropriate place for code-level questions is SO.
  • The appropriate place for server/network questions is SF.

The questions that should go on SF are not so much Parse Server related, they are server and network related. The challenge for the author here seems to be phrasing the question correctly to get an appropriate answer. That however requires some understanding of the problem, which is the actual issue in the first place. The parse tag is just a side info. From my experience, network related questions also get appropriate attention on SF, when properly formulated.

I once took the time to explain http server timeout settings in a Heroku context, but only because it is a fundamental setting that is not in the Parse Server docs (rightly so), and someone new to the topic will have to deal with it once their traffic scales. I wrote the answer in detail because it is a common issue when running Parse Server on Heroku and so we can point to it in the future.

Here is another Node.js http server question that asks about timeout of Parse Server. I can see this as a Parse Serve question as far as how to set the timeout, but the answer to set the http server timeout is only scratching the surface of request / keep-alive timeouts and how they have to be aligned up- and downstream to not produce other errors. Once the OP sets the timeout, they will likely come back with errors they suddenly encounter up/downstream. That I wouldn’t see as a Parse Server question anymore and I would refer to SF.

Here is another question that in my opinion is unrelated to Parse Server beyond a general Parse Server performance example, pointing to the DB as a potential bottleneck or suggesting NewRelic. It could be a variety of reasons why the author can’t get more req/s, from nginx configs, to CPU usage on the host, to host port limits, to file descriptor limits, etc. This would be a classic SF question.

I think that is somewhat the dichotomy of hosted Parse vs. open source Parse. We try to make Parse Server accessible and abstract away the complexity of mBaaS, but once it is self-hosted, there are new contextual issues that are not product related.

Some ideas:

  • Add a support document where we collect the most common contextual / network / technology questions, so we make our lives easier because we can refer to it and the author’s life easier, because they get a quick answer, hopefully before even asking. Like what are the main environment config issues running Parse Server locally / on Heroku / on AWS in Elastic Beanstalk; what to consider when setting the Parse Server timeout, etc. Beyond that I would categorically point to SF / SO and close the case.

  • Change the SF tag from parse to parse-platform and add parse-server as a synonym, to make it equal to SO.

I have removed ServerFault from my templates until we reach a decision on whether we want to refer to it. If we decide to not refer to it, I will remove the SF references from the recent comments. By being more vocal about the places to post Parse Server questions, we can let the parse tag “die” on SF, there is a periodic script that removes unused tags. There are also only 60 questions, so if we remove the tags manually, it will just disappear in a few days.

For reference, a tag discussions and my initiative from last year to merge tags on SO. ServerFault is part of the discussion.

As you guys are in agreement, I guess we go with SF. When we had the discussion and changed the SO tag that was my position too but, after having promoted SF for quite a while and having had no one post there I’m just not sure it’s worth it.

We’ll have to change a bunch of the places that talk about support, unless we just ask people to post on SF in specific cases?

I think this would are great, but I won’t volunteer to take it on!!

If SF is to be promoted I agree, but again I’m not sure it’s worth the effort.

I think @davimacedo already mentioned the most common cases which are network / OS related questions such as:

However I also see a gray zone that I would rather see answered on the community forum such as best practice advice that may be specific to Parse Server and may have proven to be efficient. In such cases my concern would be that the SF community may give general advice, but we are having a community here that can more specifically answer and bring Parse Server specific experience to the discussion. I don’t see a discrete line of separation, so I think we can leave this up to the team member for now.

1 Like

To conclude this topic, shall we forward the aforementioned type of questions to SF?

I took a look at SF today and there were 2 questions from Sept that fit there quite well I think.

If we agree to forward to SF, we can start to refer to SF also on Github issues, I currently use a template like:

For help with Parse Server, here are some resources you can try:

  • For code-level questions we recommend Stack Overflow using the parse-platform tag.
  • For network and server questions we recommend ServerFault using the parse-server tag
  • For questions that are not appropriate for the above mentioned sites we recommend our community forum.

Note that the parse tag has been removed from SF, as I retagged with parse-server as described in the Parse Platform related StackExchange tag list.