So for practical reasons, I think we're going to start with commit-then-review.
If you try to commit a new component, that commit will be reviewed and vetoed out if there is a problem. So let's get specific. Let's say you want to contribute your version of a Spark TabNavigator component. Adobe has almost finished its version and promised to commit it. I would recommend starting a discussion on this list about whether to take yours vs Adobe's. That way you'll at least have an idea whether folks are willing to review your version or want to wait for Adobe. Then if you do decide to commit, we'll take a harder look at the code and maybe you'll get rejected if we find some major problem, but otherwise it gets in. And if folks want to wait for Adobe and you disagree, you can offer it up under a different package name. I suppose someone might still try to veto that based on confusing folks about which TabNavigator to use, so that might be worth discussing up front as well, but I personally don't have a problems with different flavors of components. -Alex On 1/4/12 12:19 PM, "Michael Schmalle" <m...@teotigraphix.com> wrote: > Quoting Jonathan Campos <jonbcam...@gmail.com>: > >> That is an exact question that I asked at the Flex Summit specifically for >> the group. >> >> Roy Fielding had a great analogy/answer. >> The main idea is that this is that we are throwing a party, not running a >> business with free labor. So people need to be energized about what they >> are doing, they aren't there to be given tasks. >> >> As such there is no roadmap. You may come up with a great idea and start >> working on it, then when other people see what you are doing they may join. >> Over time your idea snowballs and gets added in, but this doesn't mean that >> there is a formal roadmap for people to sit at and program away against. >> >> However this is where Spoon comes in. We do have plans and roadmaps of >> features we want to add. Some take time and require people. If you are >> interested in our roadmap (our party) you and anyone else is free to join. >> >> Make sense? >> >> J > > This actually does make sense for features. > > So can I ask this, am I to then just look at the bug base, say hey > that looks like something I can fix, fix it then commit it? > > Don't jump on this to quick, I am saying there needs to be a unit > test? I remember Alex saying that Apache is usually commit & review > but that they were trying for a review and commit in the beginning. > Has anybody else heard this? > > Does there have to be votes on say a new component that would be added > to the SDK? I'm really just trying to understand the algorithm of > develop/test/fix/commit for an initial committer. > > Thanks, > Mike > > > > > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
