I've seen pockets of discussion regarding component creation but nothing formalized (it seems) and I think it might be useful to have some process in place - even a loose one. For the purpose of opening a discussion, I'll use a mythical ProgressBar component...
Is there a place in the wiki currently or could one be created to handle the architecture of component proposals? Adobe maintained one (example: http://opensource.adobe.com/wiki/display/flexsdk/Spark+NumericStepper) and that seems like a decent jumping off point. It seems that there would be immense value in codifying discussions to a page like this so that a generally agreed upon approach can be worked. This, at least, gives some idea to the scoped functionality of the component and some idea to what belongs where. As an example, with our fictional ProgressBar, should the indeterminate overlay be a SkinPart or should it be exposed as css styles: indeterminateOverlayColor, indeterminateOverlayAlpha, indeterminateOverlayWidth, indeterminateOverlayGap, etc.? What should the base class be: SkinnableComponent, Range, etc.? What events should be dispatched? What do the default SkinnableComponent css properties (chromeColor, contentBackgroundColor, etc.) affect? Is there a list tag for discussing implementation/architecture for a specific component or piece of functionality? Is the current "group think" to continue the component, MXML Spark Skin, code-based/optimized Mobile Skin architecture? How closely should a Spark component that has an mx equivalent adhere to the functionality of the mx component? Should spark components have clean separation from the mx namespace? Again, using our ProgressBar example, should mx.controls.ProgressBarMode be avoided even if that avoidance only entails creating a Spark equivalent: spark.controls.ProgresBarMode? Should components be "allowed" to be mobile-only or desktop-only or should everything be available in both scenarios unless there is an extremely overwhelming rationale not to?
