7

This DevOps site is amazing (I think). It continues to surprise me how many questions or answers contain specific terminology (DevOps related) that to me fit in either of these categories:

  • I don't understand what they mean.
  • I never heard about them before.
  • They seem to be like a new name (or synonym) for something else (which I'm familiar with already for a long time).

Consider these questions:

Are suchs questions on-topic here, or should I rather not ask them and do some (re-)search instead?

4
  • I think a Community Wiki (CW) question titled "Glossary of DevOps terminology" could be a valid solution to put terms and links toward their deifinition. But maybe a question by term and then a glossary CW could be a good fit.
    – Tensibai
    Commented Mar 6, 2017 at 13:18
  • 1
    @Tensibai Why would it have to be a CW? Why not just let the reputation encourage (or punish ...) users who ask good (or bad) questions about these zillions of terms, acronyms, etc), and eventually also reward the best answers to them accordingly? On top of that, this could result in the long run to this site becoming TheReference for learning the DesOps-language ... Attention: think 3 times before approving such kind of questions to be on topic (SRE, Hackatons, Containers, etc)
    – Pierre.Vriens Mod
    Commented Mar 6, 2017 at 15:42
  • Well, see the second part. Main idea behind a CW is that trusted people can edit them (100 rep needed in public beta). allowing to share the maintenance load while giving an answer/target to close others question as duplicate. I don't think we're here to build a dictionary and I personally worship at the church of research, so maybe none of my options above are a good idea and we should just close them as off-topic.
    – Tensibai
    Commented Mar 6, 2017 at 15:46
  • At least for the terms which have a corresponding tag IMHO a better vehicle for offering the definition would be through edits (or propose edits to) the tag's info. Much easier to access the info, canonical, etc. Or maybe port the clear winner answer to the tag info later one? Just a thought... Commented Mar 7, 2017 at 2:46

3 Answers 3

5

I'm glad you've brought this up. There are two aspects I see about these questions:

Are they on-topic?

Yes, I think so. It'd be hard for me to argue that questions about serverless computing, feature flags and black box testing aren't relevant to the topics of a DevOps-related Q&A site. But...

Are they questions we should encourage?

Probably not, especially in the expert-level private beta phase. The idea is that questions should be setting the tone and showing new users what this site is about.

You could almost say, "We gave DevOps experts a few weeks to come up with the best questions they could—questions which can be used to make the case for creating a new site—and they came up with these.".

Questions like "What is X?" or "Why should I use Y?" do not make the case. The blog post Are Some Questions Too Simple? makes this point well in my view, so I'll quote it here:

The key distinction to make here, in my mind, is that all questions are ultimately in service of the people answering them. That is the audience you need to satisfy if you want to have any hope of creating and sustaining a community of peers learning from each other. The minimum bar for a question is not “is this on-topic?”, but rather “is this somewhat interesting and on-topic?”. I’m not saying every question needs to be utterly fascinating, but please endeavor to make your questions more than a constant stream of no-duh underhanded softballs requiring nothing more than a quick cut and paste from Wikipedia, IMDB, or some other standard internet reference site.

There’s nothing useful any expert can learn from ultra-basic questions. Allow your Q&A; community to fill itself with enough “General Reference” type questions and you’ll soon find no experts there at all.

(emphasis mine)

However, the 'General Reference' close reason was abandoned because it ended up being used to get rid of anything that people didn't like. As stated in this Meta answer, it didn't pan out quite like you might hope, and I would imagine being on the receiving end felt a bit harsh—some users thought your question was too simple, so, no answer for you!


If you take nothing else from my post, I strongly encourage everyone to review the page you were shown before asking your first question:

You get the site you build

The first questions set the tone and topic of a site for a long time. Those early questions say a lot about what your community could become. And questions asked during the private beta will be on the front page when potential experts see your site for the first time. So please make those first questions exemplary ones that are interesting, challenging, and worthy of imitation.

Make this site worth opening up, and it'll do well. Allow this site to fill up with questions that are better answered by Googling, and people will just turn to Google instead.

2
  • The DevOps field does has a lot of interesting questions available via Google searching. But, unlike IMBD where you can find everything you'd want about a certain movie. In DevOps there is no definitive source where a person can go and find all the important DevOps topics. The information is usually available, but scattered across the internet. Some of the "basic" questions that ask about it are the filled with answers that contain (should contain) multiple reference links to multiple places that are not "easy" to come by in random browsing. Commented Mar 7, 2017 at 6:36
  • @Evgeny: A 'basic' question is fine when all the existing resources aren't great, and you can say "I've looked at X and Y, but I still don't understand Z." Showing the prior research also helps people to get an idea what the OP actually wants to know, specifically.
    – Aurora0001
    Commented Mar 7, 2017 at 15:40
4

IMHO yes, they should be on-topic. I'll try to present my reasoning.

They are DevOps-related to start with, which is what this site is about.

There may be gazillions of answers out there, maybe a google click away. But they are out there, not on this site, i.e.:

  • just as good as link-only answers
  • without any chance of contributing to this site being a reference resource, regardless of their absolute value
  • without the "validation" resulting from SE's voting and reputation systems
  • without the ability to have their absolute value increased via edits and comments, etc.

See also Ban LMGTFY (let me google that for you) links. While there you may want to note the wide range of opinions about that post as well, I'd expect an opinion spectrum for this question at least just as wide :)

2
  • Merci for this interesting viewpoint / answer / link. I think it somehow supports the comment I already posted below my question. And not to change the subject of my question, or to hijack your answer, but how about any type of "mainframe" DevOps term that you wonder about (I'd love to be challenged on more or less any of those) ... As a sample, if I'd post a question like "What are the pros and cons of using PDS versus PDSE file formats to be used for shipping executables to production environments?" If that would be an on-topic question, would you know what PDS and PDSE means?
    – Pierre.Vriens Mod
    Commented Mar 6, 2017 at 17:03
  • @Pierre.Vriens. Unsure - I had no exposure to mainframes. But I'm thinking that if I'd like to know what those mean I should be able to ask that, especially if that's relevant from DevOps prospective (which could be true if the original question is on-topic). Commented Mar 6, 2017 at 18:19
1

I tend to be in favor of two kinds of terminology-related questions.

The first are comparison questions. These are where there are two (or sometimes three) terms that, to someone reading their individual definitions, seem confusingly similar. Answers to these questions then focus on the subtle distinctions or implications of the queried terms in a way that you wouldn't get from a dictionary; you may find them online, but often that's at a Stack Exchange site. ;) A devops.SE example might be "What's the difference between continuous integration, continuous delivery, and continuous deployment?".

Secondly, it can be very helpful to have canonical answers to common questions, and sometimes these questions are asking what some term means. It's important for the answers here to not merely be a definition, but to fully explain the concept. In the "What is Serverless?" question linked in the question, a good answer (like the one we have from Aurora0001) does not merely define serverless, but explains the motivations behind it and why you would want to choose it (or choose to not use it).

You must log in to answer this question.

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