Your summing up of code contributions is correct, that's basically the process that nearly all contributors have followed - though some (like me) came in as a core contributor as we don't do project related tasks e.g. i head up our security team. One thing that's perhaps not obvious is that it's a two-way street, the core also reach out to talented individuals that we notice e.g if i notice someone in the forums who regularly helps others with helpful and knowledgable posts in the forums I'll mention their name in our weekly chats and see if any project teams could use another team member. I know a number of team leads have used this to add to their teams e.g. I noticed Don Worthley making a number of useful blog related posts and saw that he had created some useful blog additions and let the project lead, Antonio know. Antonio contacted him and he is now a valued member of the blog team.

It's done like this for a reason, in the past we've had too many project team members join and not end up contributing anything - they simply wanted the kudos of being a team member (I guess for CV purposes in many cases), so we wait until someone has demonstrated the desire and ability to contribute without credit. This makes it much more likely that they will end up actually doing some work.

To be noticed like this, the best routes are to post in the forums, and also post issues in the issuelog @ support.dotnetnuke.com - users who supply code as well as detailing issues (make sure and use the "code for review" status) are particulary welcome :) . That way if a team feels they can use additional bodies, we'll be aware of you, or else if a project lead asks for new team members via a blog they'll recognise you.

BTW, another thing to be aware is that we take great care to ensure that all code in dotnetnuke is valid and that the IP of dotnetnuke is maintained. Basically this means that whilst we can accept simple fixes such as bugs or minor enhancements , but that larger chunks of code require legal protections i.e. say someone approaches us with a large chunk of code and we add it to dotnetnuke - if that code later turns out to have come from another project or some code that a user wrote whilst employed by someone, we would be infringing on copyright. Obviously this would be a huge problem with lots of chance of litigation (see sco vs linux for a recent example http://en.wikipedia.org/wiki/SCO-Linux_controversies#IBM_code_in_Linux ). This is why major contributors to dotnetnuke and all core and project team members sign agreements that licence code to dotnetnuke and make them personally liable for any contributions. By doing this the contributor and not the project become legally responsible i.e. I go to jail, not Shaun :)

Cathal

I agree that it is not always easy figuring out how to contribute.  There are many avenues - some of them obvious - some of them not so much.  Here's one that doesn't require any approval from Shaun, myself or any project lead - create an open source module and post it on codeplex through the forge.  Build a team and really work on making it the best module for its intended purpose.  Stay commited and keep improving the module.

Does this approach work?  Sure it does - just ask Michael Washington.  He worked very hard on the Firebird Dataprovider project and was very active in promoting alternative approaches to simplifying data access in DotNetNuke.  In the end the Firebird project died off due to some technical issues and his original DAL2 project did not get very far either.  The important thing is that Michael stayed commited to trying to educate people on some of the challenges and helped to do what he could to fix them - without being a member of the team or even having any expectation of being invited to the team.  When he was invited onto the core team, he put those skills to work on the DAL+ methods before taking over the job leading the survey project.

What doesn't work however is working on a bunch of code and just throwing it over the wall, thinking that we'll accept it and be responsible for maintaining it.  Your code is unlikely to fit in with our long-term plans or how we like things architected and coded.