This is a good question. I think it makes sense to create a spot on the wiki for specifications. Some of the stuff on there might not even be component specifications per sey, but some topics like the Architecture Review Board discussed. You can see how it was done on the old page: http://opensource.adobe.com/wiki/display/flexsdk/Flex+4
I think that having some discussion occur on wiki pages via comments and edits is totally fine as long as the mailing list gets looped in at the beginning and the end. At most places I've worked, specs get announced on some mailing list with a particular "sign off" date. From that point, people can post comments. Once it's signed off, another mail is sent to the mailing list. If people agree to this, we should probably also transfer the opensource.adobe.com pages to the apache wiki. There are probably also some internal wiki's that are still hiding inside the Adobe firewall that would be good to push out to the apache site. Cheers, Ryan On Tue, Feb 28, 2012 at 12:52 AM, Jeffry Houser <jef...@dot-com-it.com>wrote: > On 2/27/2012 5:24 PM, Daniel Reicher wrote: > >> 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... >> > As I understand it; the Apache way is that "if it didn't happen on the > list, it didn't happen." > > I expect most "new" component development will be done by people who have > an "Itch to scratch." and do something, then donate it. It doesn't have > to be a huge thing with tons of discussion before or after. I don't think > we need a huge central repository of pre-development docs; although I do > believe it is important to have documentation. > > > Is there a list tag for discussing implementation/architecture for a >> specific component or piece of functionality? >> > not explicitly, and I'm not sure if I would recommend creating / using > one. > > > Is the current "group think" to continue the component, MXML Spark Skin, >> code-based/optimized Mobile Skin architecture? >> > Lots of people are all over the place on this. There has been some talk > about building a whole new component architecture designed from the ground > up for deployment to multiple platforms (Such as HTML/JS). > > > How closely should a Spark component that has an mx equivalent adhere to >> the functionality of the mx component? >> > It doesn't matter. But if you feel something is missing in one or the > other you are welcome to make updates and submit them. > > > Should spark components have clean separation from the mx namespace? >> > I thought they did? > > > 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? >> > We already have mobile only components; and "non-mobile" only components. > I think the answer of "Should this be allowed" is already addressed; > because that is the way it is. When you build a new component, build it > for what you need. IT can later be ported over to mobile or non-mobile at > your discretion. > > > -- > Jeffry Houser > Technical Entrepreneur > 203-379-0773 > -- > http://www.flextras.com?c=104 > UI Flex Components: Tested! Supported! Ready! > -- > http://www.theflexshow.com > http://www.jeffryhouser.com > http://www.asktheflexpert.com > -- > Part of the DotComIt Brain Trust > >
