The MVP Program Communications Network

Clarke Scott has re-posted a piece that he put up in response to this post by David Lemphers. The talk about the Microsoft MVP program, the nomination process and the general ethos of MVPdom. Before you read any further I would recommend going and reading both of these posts to get some context.

What makes someone an MVP?

According to directors, program managers and directors of the MVP program, it is a way of recognising outstanding members of technical communities for their community participation and willingness to help others.

Looking at that definition we can extrapolate the definition of an MVP as being someone who has some degree of technical skill (in a Microsoft product) and is willling to share their experience with others.

At certain times each year Microsoft searches for people that have made that contribution to the community and awards them restrospectively (meaning that the award doesn’t lock you into continued participation and contribution).

Before an award is given a process takes place to determine suitability of a candidate. For new MVPs nomination is required which may come from many different quarters including the local Microsoft office or subsiduary or other MVPs who that person deals with in online communities and user groups. The nomination process is pretty open and I have been asked several times to nominate someone or act as a reference (informally).

For MVPs who are being re-awarded the process is a little bit simpler, you don’t need to be nominated but everyones contribution is evaluated. One ways for existing MVPs to make sure that Microsoft knows about their community activities is keep an online profile up to date which points to things that you have been involved in (reminder – update my profile).

Historically evaluation of MVP status was based mostly on contribution in newsgroups but the field of view has expanded somewhat to include the other kinds of ways that you can contribute to community.

• Running and presenting at user groups.
• Blogging and other online community sites.
• Authoring a relevant book or magazine articles on the subject.

Inside the MVP community there has been a lot of discussion about what constitutes a valid reason for being awarded MVP status. Rather than it being a binary switch I tend to think of it as a set of scales. One one side you have the total measure of an MVP, and on the other you have the sum total of your contributions.

For the most part, to become an MVP you are going to need to contribute in multiple ways to get an award, and to be honest if you forget about the award and just focus on the community its a lot easier (and a lot more of a pleasant surprise if you get awarded or re-awarded).

The Cost and Benefits of Community

The community that surrounds any Microsoft product forms a balanced eco-system where every participant exists for a purpose and is compensated in some way for their contribution.

The cost of providing the award to MVPs is significant – all MVPs receive a free annual subscription to MSDN or TechNet and have access to a technical/ community lead who works for Microsoft. In addition to this MVPs are given opportunities to attend global and regional conferences where some of the transport and accomodation costs are covered by Microsoft.

I would not be surprised if the base costs of running the MVP program runs into the tens of millions of dollars.

On the other side, even though the award is retrospective – MVPs tend to make themselves available to talk at user groups, and go on tour at the local level as well as producing great content and tools for the entire world to use.

As an MVP of some four years I feel that the benefits of being an MVP are well worth the effort that I put into community – although like most MVPs getting the MVP award is not actually a goal but rather a consequence of these actions.

The MVP Subspace Communication System

One of the emergent behaviours of the MVP program is that there is a high speed communication network that exists below the public communication channels provided by Microsoft (newsgroups and mailing lists). This enables the MVPs to react quickly to issues that arise with Microsoft technology and this network has often been used not only to help solve a technical issue but also disseminate information broadly.

However – the network is young from an evolutionary point of view and hasn’t really had the opportunity to develop immunities to certain destructive forms of communication.

As a result its possible for one post (like Dave’s – which whilst radical was actually pretty tame) to completely clog up inboxes with introspective discussion about the MVP program. One recent thread that started that also happened to get exposed to the public Internet was this post by XL-Dennis.

XL-Dennis who is obviously an Excel MVP enumerated his concerns about the MVP program and if you look at the comments on the blog post you can see that many MVPs chimed in with a similar AND contradictory views. The really interesting thing about this post is that Sean O’Driscoll (MVP Program Director) chimed in with his views.

When I was awarded my MVP it was with a batch of nominees who were among the first to be accepted for contributions off the public Microsoft newsgroups. At the time this invoked the ire of existing MVPs who considered us to be lesser MVPs for some reason. Over time I think this view has changed and people now recognise that there are lots of different ways.

My Thoughts?

I’ve written a lot here without really explaining my thoughts so I thought I might just bash them out here so as not to leave anyone in doubt.

• Scope of community involvement; I think that the MVP program is richer now than it ever was before and I think that this is largely due to the expansion of the areas that the MVP program looks for contributors.
• Renewals; I beileve that the MVP program should be an annual award that can be renewed, but where renewal is by no means guaranteed.

That just about wraps it up for me – thanks for taking the time to read!

Team Foundation Server Release Candidate has shipped!

The Team Foundation Server Release Candidate has shipped and is now downloadable via MSDN Subscriber Downloads. I will be downloading it tonight and installing it onto a VPC to put it through its paces.

TFVC: Version Control and Database Schemas

I received an e-mail yesterday from a friend who has been following my posts on version control in Team Foundation Server. He had a question on how to effectively manage changes to database schemas throughout the life of the project. I thought about it over night and I am not sure I have a good answer other than if you are thinking about it, you are probably on the right path.

Suggestions?

Versioning database scripts really isn’t any different to versioning source files in that they adopt the same branching strategy as the source, but there are some extra things you can do to make life better for yourself.

• Control the scripts; you need to choose the right thing to version control, in this case its the database scripts. I’m not a huge fan of monolithic scripts because they can sometimes be more difficult to merge so consider breaking them up in some way. I would recommend one script per database object and then creating a batch file which executes them in the right order (the batch file should also be version controlled).
• Control the difference scripts; this is an extension to the previous suggestion. Basically as you do major database releases its not sufficient to just go and hack a change on the creation script – you need to create alter scripts which can be applied in place on top of the old released schema, this should also take into account any data migrations that need to take place. Its a good idea to create seperate upgrade batch files for each version.
• Put the version in the data; although I don’t always do this one trick is to create a version table inside the database which is a history of the scripts that have been applied to the database. Application code can then query the latest version from that table and assert at start-up whether they are compatible with it.
• Create the feedback mechanism; if you can, consider writing unit tests which drive your data access layer. Add these tests to your BVTs in Team Build so that when you change the database schema and an automated build is kicked off (hopefully via continuous integration) you will get notified sooner rather than later what data access code needs to be fixed up.

I hope this helps!

TFVC: Integrating and Transitioning from Other Bug Tracking Systems

One of the challenges that organisations transitioning from their existing bug tracking tools will face is how to temporarily integrate their current bug tracking software with Team Foundation Server while they bleed data across (bulk imports aren’t always appropriate).

For example – lets for the sake of argument say that Mozilla decided to move from their legacy (sorry, couldn’t resist) bug tracking package Bugzilla, they would need some way to associate check-ins that occured with the bugs that they were addressing.

The above screenshot is taken from the Bugzilla database for the Mozilla project and as you can see there is a pretty obvious key on the screen there – that is the bug ID “300561”. One simple technique that organisations could employ is adding a required check-in note to the source control settings.

Check-in notes are simple strings of information that you can force developers to enter when they go to perform a check-in. By default no check-in notes are required which is why a lot of people miss out on this neat little feature on the check-in dialog.

This list of fields is completely configurable and you can even make them required (they can’t be overridden like check-in policies).

Once you have defined the required check-in note, the next time you attempt to check-in some code you will be prompted to put in the details – in this case the external bug ID.

The details that you enter on this form becomes part of the permanent changeset record for the code and can be accessed by looking at items in the source file history. Since changeset information also gets recorded in build reports you can also back track from a build to work this out, and while it isn’t as direct as working with the TFS work items it does do the job.

Another option is to modify the work item definition for bugs in the process template you are using which has the added benefit of showing up in the data warehouse so you can tie it into your reports – however thats a little bit more involved and beyond the scope of this post!

I’m Animal

You Are Animal

A complete lunatic, you’re operating on 100% animal instincts. You thrive on uncontrolled energy, and you’re downright scary. But you sure can beat a good drum. “Kill! Kill!”

The Muppet Personality Test