On 06-02-2012 09:54, David Arno wrote:
I struggle with this philosophy. The idea of spending time writing code to
then find out whether people like the idea is very alien to me.
I would suggest the creation "working groups" attached to different
initiatives related to Apache Flex. I'm sure yet how much how like this
idea, but considering how big the SDK is, the amount of teamwork and
cooperation needed, and the big number of different initiatives that
will appear (some complementing each other, others completely
disruptive), I would suggest we could arrange a solution that would help
us organize better - creating a working group per initiative could help.
What do I mean by an initiaive? (Fictional) Examples: (1) building the
next minor version of the SDK (2) building the next major version of the
SDK/adding framework-level DI (3) building from scratch a new simpler
SDK meant for exporting to javascript (4) implementing missing Spark
components (5) creating a Spark Scheduling framework (6) [....]
Existing initiatives would be listed in a page on the wiki ("Currently
we're working on:") and each one would have:
(1) a wiki section used by that working group to document progress,
specifications, etc
(2) a list of the people that are/were involved in that initiative
(3) an area in the whiteboard for sharing code that would be imported to
the trunk after accepted
(4) a specific subject [TAG] so it could help everyone organizing the
Mailing List in topics. Another option would be a different Mailing List
for each initiative - it would reduce the S/N level but then it wouldn't
enable coordination between initiatives
Also, while we wait to have everything in our side, I think we could be
doing some progress in:
(1) completing the missing Spark components (Carol, could you share them
in the whiteboard?)
(2) doing some research on what would be needed to create a version of
the SDK meant for cross-compiling to JS. In other words, creating a
checklist what would and wouldn't work, what are the risks, what
features of HTML could we take advantage of, how could we change Spark
architecture so it was optimized for HTML, what to do with embedded
assets, etc
Just my two cents.
João Saleiro
