On Fri, Jan 13, 2012 at 12:43 PM, David Arno <da...@davidarno.org> wrote: > ...I'm going to repeat myself from yesterday here. If you think this > documentation is useful, get writing it...
Or write some code, maybe an example application, that exposes your ideas. > > ...If what you commit it or submit it as a patch gets approval, then it'll > form > part of future Apache Flex releases. If folk veto it, it won't. Either way, > it has to be more productive than this endless "Yes we should. No we > shouldn't" bickering over this topic.... It doesn't have to be black and white between releasing and a veto - and a release might not include the complete Apache Flex codebase. Many projects have a "contrib" folder in their code repository, where code that's not part of the core project but might be interesting to part of the community lives. Same for "samples". We have both of these in the Sling project [1] [2] and that works quite well: sometimes a module will move from contrib to the core parts, and the reverse has also happened IIRC to deprecate a core module. The contrib and samples modules might have different release cycles as the core, and some of them might be out of sync with the core project, that's fine as having them in there makes it clear what their status is. Many contrib/samples modules are one-man shows which is fine as well. You might see that as the next step up from the whiteboard area. Creating a contrib and samples folders in the Flex trunk, if/once people have stuff to commit in there, might be a good idea for this project as well. Instead of kicking out people who want to work on sample code that's only interesting to a subset of the Flex audience, give them a space under samples or contrib. -Bertrand [1] http://svn.apache.org/repos/asf/sling/trunk/contrib/ [2] http://svn.apache.org/repos/asf/sling/trunk/samples/
