Those who have been following my blog since my days on the VSCore team probably have noticed that I haven’t blogged much about my new job here on the Developer Solutions / Power Toys team.  The golden rule of blogging has always been to blog smart, which implies blogging about the stuff that you know about (or get the expert of those areas to double-check your understanding).  I guess I could have blogged about how little I know about how and why people contribute to Open Source Software, but it wouldn’t have made for an interesting read – trust me.

So, after countless meetings with the Shared Source Initiative team, Bill Hilf’s team, my fearless mentor on OSS down the hall, WiX’s Rob (including staying late one Tuesday night to watch the team code – it’s crazy what I’ll do to succeed), and the CodePlex team, I have an idea how to kick start the collaborative-development for our power toys.

Josh wrote a post asking what does it take to be successful with collaborative development, and then posted some feedback. 

Let’s see how we’re doing with our power toys:

• Well-formed code / code comments – since day one, we’ve made sure we wrote all documents and source code with releasing it to the community as a top priority
• Unit tests – we’ve provided unit tests that for all our projects, along with test scripts that kick off running the unit tests.  This way project contributors can rest assured that their changes didn’t break mainline functionality. Also, we chose to go with tools like FXCop and NUnit to ensure that anyone who wanted to participate was able to.
• Scenario tests - we’ve also provided scenario tests to verify additional coverage than just at the unit level.  We really want to make sure check-ins are of high quality
• Design documents – we’ve provided documents written by the project developer to give a high-level overview of the project
• Test Plans – One of the things I’ve learned from my software testing category is that a lot of people out there would love to know more about how to do software testing.  And we’re providing another example of how to do it.  Also, our test plans allow contributors to think about the impact a check-in may have to other functionality. 
• Documentation – We’ve gone with calling our docs Readme’s, although I’ve always felt that a readme is more about “how to install, uninstall, and any gotchas you need to know about; whereas documentation is more about how to actually use the application once it is installed.  You’ll see us use the term interchangeably, but just note that both sets of information are included in one doc.  
• Vision document – We haven’t gotten to this quite yet, but what I would like each of the tools to have is a doc that describes the scope of the project, what works well, what doesn’t work so well, what features could be added (that are in-scope).  Also this doc would mention things that are not in-scope.  For example, MSBee should only contain tasks related to building against .NET 1.1, and not become a repository of .NET 2.0 tasks. 
• A good project leader – Currently, we have several people as leaders on our projects, including the PM for the tool, the developer who wrote the tool, and me (whatever it is that I do besides getting licenses approved for use).
  Experts -  We’re looking for a few good experts (or those who want to become experts) to join our projects.
• Popularity – So far, we’re doing pretty well here, especially with “power toys” in your project’s title.
• Completeness – I’m very curious to compare how the different tools we’ve provided meet users’ needs.  This will give us a better sense of where to invest our time with future tools.

My Power Toys WishList

Since I started back in January, I’ve been doing what I’ll describe as JIT (just in time) spec’ing.  I’ve tried to do some further out thinking by spec’ing consistency guidelines and such, but there’s a lot to do when you’re an early adopter for a new v1.0 site.  So, here’s a stab at some of the ideas I’ve had floating around in my head, where I would like to see the power toys get to.

• All documentation provided in a Wiki that everyone has access to modify.  Of course, the project coordinator should always retain the right to lock or moderate certain pages.
• A reputation system to honor top contributors, including Power Toy ship-it awards.  If you have any ideas, please let me know.  I’ve been thinking about this since I joined the team, but haven’t come up with anything I’m proud to share… yet.
• Screencasts for using each of the power toys.  I’d like to also do a screencast of how to use CodePlex to get your environment setup for building and to walk through the steps of checking in code, using both VSTS and Express Skus.  As I said earlier, we really want everyone to be able to contribute, and the more instructions I can provide (wikis, screencasts), the more successful we’ll both be.
• A really cool power toys logo that people can display on the blogs, indicating they are members of our power toys.
• A Power Toys for Visual Studio Collection getting started guide that describes how both for internals and customers can add their tools as Power Toys

Just like Accessibility, I never thought I would get an opportunity to do something this cool at Microsoft.  So please, send me your feedback, thoughts, etc.  Let me know what your experiences are, for good and for bad, so I can make them ever better.