SQLServerCentral Editorial Policy - Article Publication

  • I think it's time I just made a post for this and made it available for everyone to see. Actually it probably deserves an editorial as well that might explain it better.

    A number of complaints have been issued at various times from "experts" or knowledgeable SQL professionals that the information we publish is inaccurate or dangerous. I'll admit that we have published things that are inaccurate. Everyone has, including many experts. Some of them pull down information, some don't. Some don't realize that it's there, some do. It's a problem in any publication business.

    As far as things being dangerous, I am torn here. We can't control how people do things, and I would rather have the information out there along with the discussion than hide it. Do we never publish anything on cursors? or CLR manipulation of data that can be done better in T-SQL? The user has to beware, and that includes learning about something before you use it.

    Now that I've rambled, here's the basic policy.

    I look to publish articles that can be read, and have some technical information in them. We try to avoid white papers/marketing papers, but otherwise, I think if it's technical and written about SQL Server, we try to put it out there. We correct grammar and spelling as best we can, and make mistakes there at times, but our goal is to get information out there and debate it.

    I will let authors know when I disagree, or think they have made a mistake, but I don't censor articles. I certainly realize that I'm not always right, and perhaps I've missed something they haven't. But if they insist that something is a good way to solve a problem, I am willing to let them put it out there and have the community judge it.

    We are not trying to be the final authority on how SQL Server works, but rather a wide publication on how the product us used, and sometimes mis-used, in the real world. The goal is to build a community that helps each other.

  • I feel that's fine as a policy but there is no warning of this within the articles, they can look like they've been reviewed and properly published when as no such thing has taken place. If there were information somewhere within the article's page, that it has been published un-reviewed, then that would go a long way satisfying people's issues. As it is currently a bad article can look like a good properly published reviewed article.

  • Interesting. Too bad publications that do tech edit and peer review articles don't post warnings on their articles as well. I have read misinformation on other sites and in magazines such as SQL Server Magazine. How many people read these thinking that this must be true and accurate when it really isn't.

    I think it comes down to this, Trust but Verify, with emphasis on the latter.

  • It is good to have the editorial policy elucidated.

    Personally, I am a big fan of this site exactly as it is and have great respect for what it has accomplished.

    But, I do think it can be improved by requiring a formal peer review. This is certainly not perfect. Even academic publications which have multiple experts reviewing every article get things wrong, and I do not even think that this site should go anywhere near that far. But I do believe that even a rudimentary peer review will be of benefit to the site and the authors. It will not stop all 'wrong information' but it will improve the average.

    If a peer review cannot be implemented, then I agree that a message that the articles are not reviewed or fact checked should be more prominent. Again, I understand that with any publication a cuatious reader will and should take a "trust, but verify" approach, but the degree of initial trust given is influenced by things like that. For instance, I know that anything from Jeff Moden can generally be taken as a gold standard. But I approach material from author's I am not familiar with more cautiously. It may be precisely the information I need, but it needs to be verified.

    ---
    Timothy A Wiseman
    SQL Blog: http://timothyawiseman.wordpress.com/

  • In my opinion Tore Bostrup said it best.

    > Publishing the article as is (with advice that will lead beginners astray) is OK. Promoting it as

    > the headline article in the daily email is somewhat of an editorial blunder in my book.

  • jacroberts (8/11/2009)


    I feel that's fine as a policy but there is no warning of this within the articles, they can look like they've been reviewed and properly published when as no such thing has taken place. If there were information somewhere within the article's page, that it has been published un-reviewed, then that would go a long way satisfying people's issues. As it is currently a bad article can look like a good properly published reviewed article.

    That might work, but you get into the same type of mess as before. What determines if the article is reviewed? That Steve looks at it? What about the article that covers areas Steve doesn’t know about? Get volunteers? What if there isn’t a volunteer who knows enough about your subject to intelligently review it?

    A different solution might be to have an attest from the author during the submission process that the article has been reviewed. This puts the onus on the writer but what happens when writer lies about the review? Or misunderstands what is required of the review? If the article is reviewed for grammar and spelling is that good enough? What if the article does get a technical review by someone who shares the same "incorrect" views? It wouldn't be too far a reach to have someone ask their teacher/mentor for a review of an article and if the teacher is the source of the inaccurate data, well, the review is worthless.

    Take point 17. of the article that sparked this thread - CREATE TABLE vs. SELECT INTO - as an example. Jeff popped in (on page 3) that this information is a carryover from SQL 6.5 that got fixed in 2000 and gives the references. The mistaken idea is obviously still floating around (witness the article) and who’s to say a reviewer wouldn’t hold the same mistaken idea and therefore not catch it.

    Because the reviewer doesn’t know to catch it, we get into an even worse situation of the article being given more credibility because it’s been reviewed (after all, review should have caught any mistakes so it must be correct) and the myth/errors continue because no one has a reason to check the boards - “It’s been reviewed for content.” That’s the error you’re trying to avoid and it gets magnified simply because it HAS been reviewed before publication.

    The only way to know if the review (or the article) is good is to publish it and see what you get by way of comments. With the number of reads the articles get, if something is wrong or out of whack, someone will notice and comment.

    Given the above, the current system works, perhaps not all the time, but it works more often than it fails. Perhaps adding a note that it is advisable to read the discussions on the Editorials/Articles page might be a good addition.

    You can also get a situation where the writer is totally sure THIS is the way to do something because that is the solution he or she found worked and wants to share it. Turns out his solution does fix the problem but that his solution can be expanded upon and very much improved. Where is he going to find that type of review? Here on SSC if he publishes the article. And who knows, someone else might have a similar enough problem and be able to leapfrog over to the better solution.

    The discussion board is that review. Gail's post alerting the reader to some errors is on page 1. Jeff's comment regarding Point 17 is on page 3 (at the default setting of 10 posts a page). That's not too many pages to wander through to find out what's up with the article.

    I've read too many newspapers that have a fully-staffed editorial department publish articles which are just plain wrong, missing data or so full of spin it is ridiculous. And these newspapers tell us their articles are reviewed and therefore “credible.” (Check out DHMO.org[/url%5D for "truth" in writing. Every word written there is true.)

    The reviewers hated Star Wars when it came out, totally panned it. After it became apparent there was something to a movie where lines went around blocks multiple times, the reviewers changed their tunes. Now it is noted as an important event in the history of movie making. Which set of reviewers were correct?

    I do understand your concern and sympathize with it. Reading an article only to find out parts of it are wrong can be quite annoying. But, as trite as it sounds, let the buyer beware. As Lynn said, Trust but VERIFY. Read the discussion board for the review. And anyone not smart enough to read the discussion (it really is a no-brainer) deserves what he gets.

    edit: updated to add hyperlink

    -- Kit

  • Kit G, you have some excellent points.

    The counterpoint is that a review does not have to be perfect to be useful. As you quite correctly say, even sources of information with formal review often have mistakes, but they have fewer of them than they would have otherwise.

    By having fewer mistakes you will raise the over all quality, make the articles more worth reading, and improve the site overall. None of that requires that the review be perfect. And none of it makes the boards worth less. They will still find the mistakes the reviewers missed, still expand on the initial conent, and still generate interesting discussion. But they can do all of that more smoothly if the average starting quality is higher to start with.

    ---
    Timothy A Wiseman
    SQL Blog: http://timothyawiseman.wordpress.com/

  • timothyawiseman (8/11/2009)


    Personally, I am a big fan of this site exactly as it is and have great respect for what it has accomplished.

    I absolutely agree... I just got done tearing the shirt off of someone that wrote a RBAR trigger in an article and made the excuse that it was just a "basic theme". If it had been technically reviewed, it may have been corrected before I got there and I would have missed all the fun. 😛

    Seriously, though, I agree with Timothy 100% on this... leave things alone. Anyone who is naive enough to think they should trust anything they find on the internet without testing deserves everything they get. I also believe that seeing folks publish bad stuff and then getting their shirt torn off in the discussions that follow is a way to stress that point to others.

    I know that anything from Jeff Moden can generally be taken as a gold standard.

    :blush: Thanks Timothy... thats an awesome compliment and I really appreciate it. Just keep in mind that I'm human and I do make mistrakes :hehe: just like anyone else. 😛

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I think that ideally more review helps, but as you can see from the discussions yesterday, there is disagreement from reviewers about what is correct, or what should be recommended. I hear this all the time from "experts" and see them argue over things more often than I would have thought.

    What I would be happy to do is publish a list of "reviewers" on the writer's page and allow authors the ability to private message people that might be interested in reviewing something. Or maybe create a separate forum for authors to request some review.

    I'm slightly concerned that this will result in a few reviewers somewhat dictating what should be published and how it should be worded. I feel it's a valid concern, especially as new authors might feel overwhelmed by someone that disagrees with them, and might not be correct in their disagreement.

    What I have done is raise an enhancement request to call out the discussion more highly at the beginning and end of an article that has more than 4 responses to it. That would allow, or warn, someone to read further. To me that appears to be the best solution.

  • Steve Jones - Editor (8/11/2009)


    I think that ideally more review helps, but as you can see from the discussions yesterday, there is disagreement from reviewers about what is correct, or what should be recommended. I hear this all the time from "experts" and see them argue over things more often than I would have thought.

    What I would be happy to do is publish a list of "reviewers" on the writer's page and allow authors the ability to private message people that might be interested in reviewing something. Or maybe create a separate forum for authors to request some review.

    I'm slightly concerned that this will result in a few reviewers somewhat dictating what should be published and how it should be worded. I feel it's a valid concern, especially as new authors might feel overwhelmed by someone that disagrees with them, and might not be correct in their disagreement.

    What I have done is raise an enhancement request to call out the discussion more highly at the beginning and end of an article that has more than 4 responses to it. That would allow, or warn, someone to read further. To me that appears to be the best solution.

    Heh... no, No, NO, NO! Part of being a DBA or Developer is to make sure that you can communicate successfully and accurately. You have absolutely the correct idea of letting the authors simply have at it. Let them fail or succeed on their own merits just like they do at work. Shoot, I wouldn't even do a spell check for them... THEY'RE SUPPOSED TO KNOW HOW TO DO THAT. If someone insists on embarrassing themselves with poor research or bad typing habits, the let them!

    If I have a vote on this, my vote would be to keep things the same except maybe to stop doing spell checks for morons. 😛 "Give people the opportunity to fail... it's the only way they will learn to succeed." -- Jeff Moden circa 1980

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I have also heard this: "You learn more from failure than success."

    If you never fail, what do you learn? It's the mistakes one makes that you learn from, not the successes. Oh, another quote: "What doesn't kill you makes you stronger."

    So what does all this say? I agree with Jeff, to a point. Since we do have authors for whom English is a second or third language there should be some grammer/spell checking involved. I do recall a few articles that were difficult to read and understand because of language issues.

  • Steve Jones - Editor (8/11/2009)


    What I have done is raise an enhancement request to call out the discussion more highly at the beginning and end of an article that has more than 4 responses to it. That would allow, or warn, someone to read further. To me that appears to be the best solution.

    Sounds like a good enhancement. But should the threshold be set so low? I don't have the stats to see what the average number of responses is to an article, so I'll trust your judgment on it, you have the data, I don't. Just curious how that number was arrived at.

    -- Kit

  • Kit G (8/11/2009)


    jacroberts (8/11/2009)


    I feel that's fine as a policy but there is no warning of this within the articles, they can look like they've been reviewed and properly published when as no such thing has taken place. If there were information somewhere within the article's page, that it has been published un-reviewed, then that would go a long way satisfying people's issues. As it is currently a bad article can look like a good properly published reviewed article.

    That might work, but you get into the same type of mess as before. What determines if the article is reviewed? That Steve looks at it? What about the article that covers areas Steve doesn’t know about? Get volunteers? What if there isn’t a volunteer who knows enough about your subject to intelligently review it?

    I do understand your concern and sympathize with it. Reading an article only to find out parts of it are wrong can be quite annoying. But, as trite as it sounds, let the buyer beware. As Lynn said, Trust but VERIFY. Read the discussion board for the review. And anyone not smart enough to read the discussion (it really is a no-brainer) deserves what he gets.

    edit: updated to add hyperlink

    Articles on this site vary from excellent to poor. I realise that the authors are from different backgrounds, lots of material is published but there should be some form of reviewing even if it is light and limited, sometimes articles are published that haven't even been put through a spell checker; no prior knowledge is needed to do that it's just common courtesy to the readers. Spelling though is the least problem. Regarding Lynn's comment "Trust but VERIFY", I'm not exactly what she means, if an article is incorrect you shouldn't trust it. There are a lot of articles on the internet and most of us don't have time to verify everything we read, but a prior warning would be useful. Something like this could be put in the header of the article:

    This article has been generously submitted by xxxxx. SQLServerCentral have not reviewed this article for any inaccuracies.

  • jacroberts (8/11/2009)


    Kit G (8/11/2009)


    jacroberts (8/11/2009)


    I feel that's fine as a policy but there is no warning of this within the articles, they can look like they've been reviewed and properly published when as no such thing has taken place. If there were information somewhere within the article's page, that it has been published un-reviewed, then that would go a long way satisfying people's issues. As it is currently a bad article can look like a good properly published reviewed article.

    That might work, but you get into the same type of mess as before. What determines if the article is reviewed? That Steve looks at it? What about the article that covers areas Steve doesn’t know about? Get volunteers? What if there isn’t a volunteer who knows enough about your subject to intelligently review it?

    I do understand your concern and sympathize with it. Reading an article only to find out parts of it are wrong can be quite annoying. But, as trite as it sounds, let the buyer beware. As Lynn said, Trust but VERIFY. Read the discussion board for the review. And anyone not smart enough to read the discussion (it really is a no-brainer) deserves what he gets.

    edit: updated to add hyperlink

    Articles on this site vary from excellent to poor. I realise that the authors are from different backgrounds, lots of material is published but there should be some form of reviewing even if it is light and limited, sometimes articles are published that haven't even been put through a spell checker; no prior knowledge is needed to do that it's just common courtesy to the readers. Spelling though is the least problem. Regarding Lynn's comment "Trust but VERIFY", I'm not exactly what she means, if an article is incorrect you shouldn't trust it. There are a lot of articles on the internet and most of us don't have time to verify everything we read, but a prior warning would be useful. Something like this could be put in the header of the article:

    This article has been generously submitted by xxxxx. SQLServerCentral have not reviewed this article for any inaccuracies.

    My wife will take exception to my being called a she. 😉

    As for Trust but Verify. Simple, rely more on the latter than the first. It really depends on who is providing the information. I will tend more to the Trust if it is an article written by Jeff Moden (for example) and to the Verify if it is someone I know little about. Even then, I'll take the time to verify if it is something I am not familiar with before using in production.

  • I think grammar is not that important in a technical article technical accuracy is very important but something could be correct per the BOL or MSDN but is just plain wrong for implementation so accuracy becomes very relative. When SQL is separated to logical and physical there may be info lost in articles, so I think implementation will remove many errors and assumptions from writers.

    Print screen is good for all.

    😉

    :Whistling:

    Kind regards,
    Gift Peddie

Viewing 15 posts - 1 through 15 (of 102 total)

You must be logged in to reply to this topic. Login to reply