This project is read-only.

Quality Bands for control development - comments?

Jun 15, 2009 at 5:54 AM

I've spent some time last week talking to people about how best to produce good quality controls and also how best to make it easy for people to contribute.

I propose we have 4 bands for all all controls as per the Silverlight controls project here on codeplex.

Quality Bands


Experimental components are intended for evaluation purposes. The main goal of these components is to provide an opportunity for feedback during the earliest stages of development. This feedback will help decide the future of these components. Development of an experimental component may end at any point so it may not be included in future releases.


Preview components are intended to meet most basic usage scenarios. While in the Preview Quality Band, these components may have a moderate number of breaking API or behavior changes in response to customer feedback and as we learn more about how they will be used. Customers are likely to encounter bugs and functionality issues for non-mainline scenarios. Preview is similar to "Alpha" quality in many traditional projects.


Stable components are suitable for the vast majority of usage scenarios and will have incorporated most major design and functionality feedback. They are designed to address over 90% of customer scenarios and will continue evolving via limited bug fixes and fit-and-finish work. Stable is similar to "Beta" in other projects. Stable components will have a very small number of breaking API or behavior changes when feedback demands it.


Mature components are ready for full release, meeting the highest levels of quality and stability. Future releases of mature components will maintain a high quality bar with no breaking changes except when such changes are necessary to make them more secure or guarantee future compatibility. Customers should be confident using mature components, knowing that when they upgrade from one version of the Silverlight Toolkit to a newer version it will be a quick and easy process. Due to the heavy focus on backward compatibility between versions, the bar for fixing bugs found in mature components is also considerably higher than any other Quality Band.

Jun 15, 2009 at 6:03 AM

The idea is that anyone can contribute an experimental control, doesn't matter if the code is a little awkward but it must compile. The process may proceed as follows:

  1. New ethusiastic developer makes interesting control, adds it to the project under experimental. A wiki page is setup for every control.
  2. Everyone can comment and provide feedback on the controls wiki page.
  3. Someone may like it so much they add it as a feature request in the issue tracker.
  4. People can vote.
  5. Developers can vollenteer to take it to the next level - preview. The code at this stage must fit the DeepEarth architecture, namespacing and work with other controls.
  6. Tests are created, feedback gathered and with help it is evolved into the Stable band.
  7. Feedback from users running the control in production will continue to stabilise the control, if it reaches a critical point where it is feature complete and well used it will become Mature

What do you think? I believe it is important to lower the barrier of entry for poeple to contribute their initial ideas while still producing a quality set of controls. Importantly we should make it very clear what band a control is currently in.