How to become a contributor?

We are currently planning two methods of becoming a contributor:
  1. Contribution proposals (see below) are sent to and we evaluate the proposal and the credentials of the contributor. Upon approval, contributors will be granted an account and permissions to the Toolkit project itself. See below for the approval process and criteria.
  2. We are planning on opening a fully public “ASP.Net AJAX” Component Gallery. Based on a set of loose heuristics (e.g. highest rated, most downloads, just plain cool), we’ll invite those authors to become contributors on the Toolkit project and move their components in.

Who can contribute
The Toolkit project has been designed to support discrete contributions from several sources. Most Toolkit components are isolated in their functionality, so individual component authors can make their contributions with little risk of impacting the Toolkit as a whole.

Contributors should have some basic skills:
  • A solid understanding of web technologies including the W3C DOM, ASP.NET page lifecycles, and JavaScript
  • Experience with the .NET Framework and C# (while the Toolkit supports writing components in Visual Basic.NET, the project itself is a C# Control Library, and Visual Studio does not currently allow mixed-language compilation for assemblies)
  • Experience writing ASP.NET controls
Contributors should be passionate about writing great, reusable components with flexible APIs, and be willing to commit to supporting the work that they do.

Why Contribute?

There are many benefits for contributors:
  • Recognition by the community. There have currently been about 50% as many Toolkit downloads as ASP.Net AJAX Runtime downloads, and that number is growing, so a large percentage of ASP.Net AJAX users are also Toolkit users. The Toolkit will continue to get mentions on the ASP.Net AJAX website, as well as in high profile blogs and publications.
  • Satisfaction. Developers are already using Toolkit components on production websites. There is nothing as satisfying as going to an application and realizing “hey – I wrote that!”.
  • Credibility. We’re going to be conservative about who we allow to be Toolkit contributors. Being a contributor means that you’re at the cutting edge of developers in the AJAX space.
  • Being a part of something new. This is a very different kind of project for Microsoft, and if it’s successful, there will be more like it. By contributing great ideas and working hand-in-hand with developers here at Microsoft, you’ll be one of the pioneers on the frontier of collaborative software development.
  • Fun! Writing “ASP.Net AJAX” components allows you to pull together several skill sets and produce components that can really simplify the development process. We’ve had a lot of fun writing them and we believe that you will too!

How do contributions work?
Contributions will be made through the “ASP.Net AJAX” Control Toolkit project at CodePlex, Microsoft’s new community collaborative-development website. CodePlex allows access to a Team Foundation Server setup via the Internet. On CodePlex, projects get source control, issue tracking, discussion forums, release updates via RSS, and a host of other functionality. What’s better is that you can manage all of this from directly within your Visual Studio 2005 installation, by installing a free add on called Visual Studio Team Explorer. If you’re using one of the “Express” versions of Visual Studio, you can also use this tool, or the command line TF.EXE tool, but in either case you will not get in-project integration as you will with a full Visual Studio 2005 installation.
Anyone can go to the Toolkit project site and view or download source, view current issues or look at the project “Wiki”. No permissions are required for that access.

There are four levels of access to CodePlex:
  1. Visitor (Anonymous User) – you can look at the project, discussions or issues, and can download source.
  2. Evaluator (Registered user) – this allows you to post to the discussion forums (note the “ASP.Net AJAX” Control Toolkit project doesn’t have one since we’re using the forums at and enter issues.
  3. Developer (Contributor) – this gives you the ability to enlist in source control and modify the code base.
  4. Coordinator (Toolkit Team) – this level allows you to manage the project site, add and remove Developers, etc.

However, in order to modify or contribute code directly, you’ll need to be marked as a “Developer” role in CodePlex by one of the projects “Coordinators” (Toolkit Team). At that point, you’ll be able to check in and modify Toolkit code.

Contributors agreement and licensing model:
The last step towards becoming a contributor completion of Community Assignment Form by you. We will send you the form after we have evaluated your application and had email communication with you.

All code included in the Toolkit is licensed under the Microsoft Public License (Ms-PL), which is also included with the Toolkit distribution and can also be viewed here:

Toolkit idea submission and approval process
In order for the Toolkit to be broadly used, it must be not only applicable to the scenarios developers face, but it must also be of consistently high quality. Therefore, it’s critical that we maintain a high bar for what gets put into the toolkit itself.

Toolkit proposals will be judged based on:
  1. Usefulness – How many developers will find this component useful for “normal” web applications?
  2. Fit – How does the proposal “fit” within the context of the Toolkit? Is it significantly different than the spirit of the other components? Does it significantly improve the “completeness” of the Toolkit?
  3. Likelihood-of-success – How likely is the proposal to actually work? We want to stay away from highly-complex ventures that are prone to an ongoing stream of difficult to manage issues.
  4. Coolness – Are the components unique and/or great ideas that highlight the power of the platform?.
Granted, these are subjective, and will be open for discussion. As the project grows, we hope to have a set of people who can review proposals an offer potentially differing perspectives. In any case, our goal is to grow the Toolkit so any good ideas have a good chance of getting approved.

When submitting your idea, please write it up in the following format:

Contributor Name(s): Your name
Contributor type: New Component Author/Existing component author (mostly bug fixing, new feature requests)
Component Name: The name of your component (existing component/wishlisted component/new component not tracked by us)
Component Type: (Control/Extender) Is your component an extender or a server-side control?
Description: A few sentences describing your component idea
Standard Scenario(s): A few standard usage scenarios that this component would address
Estimated Completion Dates:
Prototype: ETA of completion of prototype
Final: ETA of checkin of completed component
Already prototyped: (y/n) Is there already a prototype or demo of this component available? Link to demo.

Email this information to and we’ll process them in order and get back to you.

Supporting your contributions
One of the keys to the success of the ASP.Net AJAX Control Toolkit project is rich interaction with the people who are willing to use and give feedback on these components. We believe in the power of the community to identify and report the key issues that are affecting a given component. But, as with any new technology, users often need some help understanding how to use the components. Helping them achieve this understanding will lead to them reporting better quality issues – you know, the kind you never thought of before you shipped but wished you would have!

So it’s critical that component authors also commit to providing support for their components, preferably via the forum at By keeping this feedback loop as tight as possible, the Toolkit components will rapidly reach a good quality level and help drive the wider adoption of the Toolkit and make it attractive to other contributors as well.
If a component is receiving a large number of issues that are not being properly addressed, we reserve the right to remove it from the Toolkit until the issues have been worked out. We will work with the author to figure out the right course of action here, be it some focused bug fixing, moving the component back to the Prototype project, or outright removal.

If you become a contributor...
  • New Controls: All new controls start out in prototype. If you own a control you need to actively fix bugs, check in feature request changes, maintain test and demo pages and handle pertinent forum posts. All bugs reported on the control will be assigned to you for primary investigation with some priorities set by the toolkit team. It is your responsibility to get bugs fixed in a timely fashion. You own full responsibility of the control till it reaches a stable state i.e. the control work items are mostly in the form of new feature requests but not bugs/issue types. New controls in prototype should have (1) no known issues, (2) a self-sufficient toolkit test, (3) documentation(code comments, usage help and api descriptions) and (4) a code review by one of the members of the toolkit team before they can be moved into the Development tree.
  • Bug fixing: If you do not own any controls then you share the bug fixing responsibility and get assigned work items in triage. Please provide your bug schedule to the toolkit team and ensure that you are on top of things. If you need code reviews, which we recommend you do anyways, you should send mail to the contributor’s alias requesting people to look at your code.

We would like the contributor list to reflect active toolkit contributors.

ASP.Net AJAX Control Toolkit Releases
Under the “Releases” tab on the CodePlex “ASP.Net AJAX” Control Toolkit project, you will see the list of packaged, signed releases of the “ASP.Net AJAX” Control Toolkit. These are the releases that have been well tested and approved for general distribution. We’re making decisions about how to manage this as the Toolkit project continues to move ahead.

We will, however, be providing regular “Last Known Good’ releases that are at a lower quality bar but pass all of the internal tests. These will be provided as a full package and a binaries-only package.

Last edited Oct 18, 2007 at 12:35 AM by kirtid, version 10