[Adium-devl] Some Context, please read

[Colin Barrett]

Now, please bear with me and read this. I'm going to try and give some  
context for what I've been doing and thinking the past year or so:

I think (hope?) we can all agree that one of our goals as a community  
should be growth. People will come and go from our community, and the  
patch contributor of today is quite possibly tomorrow's lead developer  
(it's happened once before). Making sure we've got folks rising up  
through the ranks (and ways for folks to gracefully fade away), is  
very important.

I also would like to admit that I float sometimes crazy, left field  
ideas on this list that would definitely not work or add way too much  
overhead and aren't practical at all. I expect folks will push back  
and we'll hopefully end up meeting somewhere in the middle, and we've  
done a good job at that despite me poorly communicating my intent.  Go  
team.

Chris, you asserted that Adium is a mature product, and that's largely  
true when thinking about the app we ship at the end of the day.  
However, from a developer community and process point of view, we're  
still fairly wet behind the ears. I know adding process where it's  
unnecessary can be really frustrating, but a little can go a long way  
towards giving us some breathing room to grow our community.

Here's a good thought experiment: We have some great community testers  
and some awesome folks triaging tickets, but imagine what would happen  
if say, we had 2x the number checkins on the trunk that we have now?  
3x? 1.5x? 10x?

Does our current process allow us to deliver a product of a quality  
level we're happy with, in a timeframe we're comfortable with? That's  
the question I keep coming back to. Our current model is very fluid  
and has some nice benefits, but it does not scale very well,  
especially considering all our testing is completely ad hoc by users  
(as opposed to having written test cases people can run through, which  
seems to be the norm for QA at most companies).

Finally, I would like to point out that many of the changes I've been  
suggesting are common both throughout the software industry and other  
open source products. Everyone has to deal with issues like code  
review, continuous integration, end user documentation, automated  
testing, manual testing, revision control, quality assurance, security  
issues and release management. I'm trying to look at the ways other  
people (not just Mozilla) deal with these issues and see if we can use  
those to help us grow our developer community.

Does that help explain where I'm coming from a little better?

(please let me know if anything is confusing)

-Colin