December 29, 2008 at 10:10 am
just to add-on to my thoughts....
I'd prefer the topic section to contain all topics; which should be grayed when an improper version is selected.
say a user has selected the version as 2000, then the DATABASE MIRRORING section should be grayed out... this will prevent lots of queries falling under incorrect section. An internal table can contain these information.
December 29, 2008 at 10:22 am
I think combining the version has merit. Yes, people need to specify what version they are using but is that really that big a deal? I have dealt with that on other platforms I have worked with. As long as people do not get snotty when they reply asking for a version things can work well.
The benefit of combining the version is cross-knowledge for those still on old versions. When they see how much easier things are in a new version or things that are now possible in a new version they have more ammunition to take to management to get an upgrade.
<><
Livin' down on the cube farm. Left, left, then a right.
December 29, 2008 at 10:33 am
Andy Warren (12/29/2008)
Sorry, one more point - if you tag every post with a version, with a little work you can let users select which view they want - do they want to see all admin, or only 2008 admin. That might let you satisfy most of the posts here.
Yesyesyesyesyesyesyesyesyes
And, might I say, Dear Chaps, I totally agree with the esteemed Mr. Warren's earlier proposition.
😀
December 29, 2008 at 10:39 am
Steve's original idea of general sections works well in consolidating and cleaning up the forums.
Someone posting into an existing forum or creating a new post can simply post under the relevant section with a choice of having to select the version upfront or typing it in within the issue description.
All the cosmetics around mandatory version drop downs, greying out incorrect versions, etc. simply complicates things and, in my opinion, would possibly cause more incongruous posts.
December 29, 2008 at 11:05 am
I like the idea of simplifying. I think the version differentiation could come within the categories if needed. Some things do stay the same between versions, and sometimes you can get a good idea from how it was done in a past version. Thanks for your great work.
December 29, 2008 at 11:20 am
I definitely support Topics at the top level. I can't count the number of times I needed to post a T-SQL question, and couldn't decide if it should go in 2000 or 2005 to get the most visibility. I hate cross-posting, but probably even resorted to that once or twice based on the structure.
The Version drop-down would be a beautiful solution!
December 29, 2008 at 11:25 am
joshcsmith13 (12/29/2008)
I can't count the number of times I needed to post a T-SQL question, and couldn't decide if it should go in 2000 or 2005 to get the most visibility.
Why visibility? The deciding factor should be what version of SQL you were writing the query for.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
December 29, 2008 at 11:30 am
joshcsmith13 (12/29/2008)
I definitely support Topics at the top level. I can't count the number of times I needed to post a T-SQL question, and couldn't decide if it should go in 2000 or 2005 to get the most visibility. I hate cross-posting, but probably even resorted to that once or twice based on the structure.The Version drop-down would be a beautiful solution!
Your 2000 questions will get the most "visibility," in this case, read that as "correct answers", in the 2000 forum as opposed to the 2005 forum. So many posts come in to the 2005 forum asking for help and then can't run the queries provided because, unknown to everyone trying to pitch in, it's a 2000 server.
It's exactly these types of issues that make me believe that we still have to have a way to filter between the versions. Lots of questions are generic in nature, but most are probably very specific to the version of SQL Server being run.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
December 29, 2008 at 11:34 am
GilaMonster (12/29/2008)
joshcsmith13 (12/29/2008)
I can't count the number of times I needed to post a T-SQL question, and couldn't decide if it should go in 2000 or 2005 to get the most visibility.Why visibility? The deciding factor should be what version of SQL you were writing the query for.
I have to agree with Gail. If you are writing for SQL Server 2000, that's where you should post. If writing for SQL Server 2005, then post there. The problem I have seen is people posting SQL Server 2000 questions in a SQL server 2005 forum, not telling people that they are using SQL Server 2000, then getting upset with the response they receive because it doesn't work in SQL Server 2000 because we used SQL Server 2005 specific constructs, such as CTE's.
Even though we still have several servers at work running SQL Server 2000, all our production systems are now SQL Server 2005, and that is where I personally do most of my work. I can answer SQL Server 2000 questions, and even write code that will work on SQL Server 2000, but I have to know that SQL Server 2000 is the target system or I will write code for SQL Server 2005.
December 29, 2008 at 11:38 am
When I think about how I would like it designed for optimal use, I would have an option of having the same post under more than one heading. Reason ? It's hard to categorize every question just under one umbrella. eg. if I need to ask/share something about data migration across diff versions or about backward/forward compatibility, I'd like to spread it across a wider spectrum to get more answers and for people to look at it.
I have been working on SQL Server since 6.5 days. These days I am totally on 2005 and look forward to 2008. So I will NEVER really bother looking at something older but I could help someone with issues elsewhere.
The option of casting the net wide seems attractive because after all, we are all here to learn and share. Of course, it increases redundancy but it's worth it.
To sum it up...broad headings with multiple sub-headings for a 'primary post' and same option for 'secondary post'. The secondary post can be limited to 2 options to start with.
December 29, 2008 at 11:39 am
First, creating a taxonomy is hard work. Don't forget this.
Second, all good taxonomies go from general to specific. The primary debate thus far seems to be on how to handle version. IMHO version is a specific attribute of the posting. The proposed areas (e.g. Administration, High Availability, etc) are more general.
Third, Steve, a few weeks ago you did a posting on tagging. It seems to me the best solution to balance between the number of forums and finding specific questions is to employ tagging. Tagging works best when the relationships are not hierarchical but rather graphical. I think this is the case with forum postings - that's why we see cross postings.
I'd start with the highest level of general classes (there's probably 6-10 of them). I wouldn't go any deeper. To provide further division I'd use tagging. Granted, tagging is totally optional so there will be posts that aren't tagged. This is where you can use moderators (or leave it open to anyone to update) to fill in missing or incorrect meta-data.
December 29, 2008 at 11:40 am
The most important thing about "Separation By Versions" is so that the responders know what versions they should craft an answer for. And as we all know, even having separate forums, we still get many of the threads posted wrong.
I really liked the suggestion that the new threads form have a required "Version" dropdown. Perhaps even better would be a checklist so that multiples could be selected. Ideally, this would initially be blank but would flag an error if something was not checked. I think that that would help to cut down the version confusion a lot.
Now, if we could get that to work, then I would agree that we have very little need for the Fourms to be separated by Version.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
December 29, 2008 at 11:46 am
sqlstuff (12/29/2008)
To sum it up...broad headings with multiple sub-headings for a 'primary post' and same option for 'secondary post'. The secondary post can be limited to 2 options to start with.
That's the thing though - multi-posting tends to backfire here. Because so many of the regulars use the "active threads" or "recent posts" options to look at new posts, having the same question come up multiple times over tends to annoy (and therefore, turn away). So - posting multiple times tends to pull in LESS answers.
I could see using your idea for searching later or if you're wanting to do a topical search, but you really don't want the same question coming up multiple times.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
December 29, 2008 at 11:51 am
Matt Miller (12/29/2008)
That's the thing though - multi-posting tends to backfire here. Because so many of the regulars use the "active threads" or "recent posts" options to look at new posts, having the same question come up multiple times over tends to annoy (and therefore, turn away). So - posting multiple times tends to pull in LESS answers.
In addition, there's little that's more frustrating than spending half an hour or so composing and testing a solution to someone's problem, only to realise that they posted it elsewhere as well, the question has already been answered, and that half an hour was a complete waste of time.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
December 29, 2008 at 11:57 am
Steve Jones - Editor (12/29/2008)
It looks like most people like separation by versions, and perhaps that still makes sense. My guess is that most people won't list their version, and probably most people today pick the right forum for their version.Likely I've just been sensitive since I see the issues and not all the things that work well.
I'd still be interested in what we can do to easily consolidate some of the existing forums together.
If you're willing to keep versions in (and consolidate to a point you feel comfortable with), have an extra step whenever a post is made (forum, article, or script). With the tags that are included with the post, you may want to force the version to be entered, but if someone forgets, the post would just float in limbo. Have as a mandatory option, a set of Radio Buttons with the SQL Version: SQL 7, SQL 2000, SQL 2005, and SQL 2008. Checking this box could cause an automatic entry into the tags section of the post. Any organization/filtering/consolidation that occurs by sql version could be comfortable with the fact that each post would have a version attached to it. Also, making the version a radio button, avoids typing in different names for the same server (e.g. SQL 2005 / SQL Server 2005 / SQL 2k5 etc.)
So basically, pick a standard naming convention for the versions, force the person creating the post to select the right version, and hopefully that should work.
Gaby
Gaby________________________________________________________________"In theory, theory and practice are the same. In practice, they are not." - Albert Einstein
Viewing 15 posts - 31 through 45 (of 99 total)
You must be logged in to reply to this topic. Login to reply