WayneS (4/5/2010)

---

Well, to start off, there are several distinct areas to cover:
1. Who qualifies to be sit on the board?
2. Where will the board convene?
3. How often will the board convene?
4. What topics will be covered by the board?
5. How large should the board be?

I suggest that we actually tackle these individually. However, it might be best to just throw things out that can cover all of these for a little bit, to get the conversation going.

It has been mentioned that it would be good to have boards at events / conventions (i.e. PASS, SQL Saturday, etc.). I agree with this, but we need to ensure that there are enough different people there to run multiple boards so that we don't end up with one group of people where all they do is do boards... they probably want to see what all is going on at the event also. (Unless they are being paid to be there for the purpose of conducting a board...)

It has also been mentioned that the board should be local. And in cases where it becomes a hardship to attend a board, that provisions to conduct the board via web-cam be available. I like both of these suggestions, but recognize that in order to have quality people sit on the board, we may need for some of them to actually be there virtually via web-cam also.

My initial thought as to who should sit on the board was to use MVPs. However, I immediately shot this down... because MVP does NOT mean that they are knowledgeable of the product to that depth, but instead this is a recognition of their evangalism of the product. This isn't to say that we should exclude MVPs; but that depth of knowledge is more important. I'm certain that MVPs will be on this board, but that should not be the criteria. I think that every attempt should be made to get at least two board members physically at the board, with the board consisting of 4-5 persons.

Does someone that has earned this certification automatically qualify to sit on a board? After all, they have demonstrated a deeper knowledge of sql.

What should be covered?
Index structures.
Indexing.
Clustering.
Mirroring.
Log shipping.
Replication.
Performance tuning (how to read execution plans / statistics).
Server configuration.

Time to let other people in with their thoughts...

Jeff Moden (4/5/2010)

---

I'd rather see the discussion continue on the thread which started it all rather than essentially double posting. Sorry Jason.

CirquedeSQLeil (4/5/2010)

---

I know. There are reasons to move it from there to here though. I agree with the reasons. Some of it is that there is a lot to wade through over there. Having this info here, may make it easier for other people to follow the thread and provide good feedback.

Jeff Moden (4/5/2010)

---

I guess that's reasonable. Thanks for the feedback, Jason.

Lynn Pettis (4/5/2010)

---

I know the discussion right now is the review board, but I thought I'd interject one other aspect so it doesn't get lost. Should there be one MCJ or should it be broken down similiar to the MCITP (DBA, Developer, BI) or as I had suggested earlier DBA/Developer, BI? Should all versions have a common core and then a specialization. This will be important as we discuss the review board as it could easily change the complexion of the who makes up the board.