Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Received-SPF: pass (athena.apache.org: domain of aharui@adobe.com designates
 64.18.1.185 as permitted sender)
From: Alex Harui <aharui@adobe.com>
To: "dev@flex.apache.org" <dev@flex.apache.org>
Date: Fri, 1 Mar 2013 09:50:37 -0800
Subject: Re: A guideline for adding new components to the Apache Flex SDK?
Thread-Topic: A guideline for adding new components to the Apache Flex SDK?
Thread-Index: Ac4Wd1UX2LVWAtVRTbOIZCuH0dXlngALfKwF
Message-ID: <CD562A6D.4E39A%aharui@adobe.com>
In-Reply-To: 
 <CALorpXf_rO5RN+PFPOuCTc0VjOMkTvzJnGzTz7k9sgy-pSEDxg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-Entourage/13.15.0.121009
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

I think it is better to reset expectations.  Sure, if we take a team of
several people and develop a component in private, we can introduce to the
public something with relatively high quality several weeks or months after
we start, but I honestly don't think that is the most efficient policy.

If you are reading this, then you are now part of that team, and instead of
developing in private, we are doing it in the open.  This means that early
checkins may be as awful and bug-filled as any early checkins the Adobe
folks saw internally, but it also means we have opportunity to get more
feedback much sooner.

So yes, new components may make their first appearance in a release with th=
e
same sense of "quality" you might have expected from Adobe, but I think we
just have to manage expectations.  The release notes can mention which
components are new and may be in "alpha" or "beta" stages.  And we also get
to release more often so we can react to major issues found more quickly.


On 3/1/13 4:21 AM, "Nicholas Kwiatkowski" <nicholas@spoon.as> wrote:

> I think this is a self-policing thing that has been going on, and will
> probably continue to go on.  I know that many of us watch the commits as
> they come through (Alex I know dives into anything I touch, code-wise...
> that's probably a good thing).  I personally have gotten feedback on many
> of the things that have happened in my own whiteboard.
>=20
> -Nick
>=20
> On Fri, Mar 1, 2013 at 6:32 AM, Sebastian Mohr <flex.masuland@gmail.com>w=
rote:
>=20
>> Hi,
>>=20
>> It is great to see that people start to raise their
>> hands to work on new Apache Flex components.
>> I just wanted to share a general concern with you ...
>>=20
>> How can we guarantee that our new components,
>> coming up in the next versions of the Apache Flex
>> SDK, have the same quality of the existing Adobe Flex
>> components? People, like Chet Haase from the Adobe
>> Flex team, working on the Slider and Scroller components
>> [1], had the capacity to think about their Adobe Flex
>> components for months (if not years) before they have
>> added these components into the Adobe Flex SDK. They
>> also had a team that focused on the mobile components
>> only in Adobe Flex [2]. How can we keep up with the same
>> quality for our components?
>>=20
>> Wouldn't it make sense to write down a guideline into
>> our wiki so that we have a checklist we can go through
>> before we add new components into the Apache Flex SDK?
>>=20
>>=20
>> [1]
>>=20
>> http://tv.adobe.com/watch/codedependent/animated-scrollbar-and-slider-in=
-flex
>> -4/
>> [2]
>>=20
>> http://www.hufkens.net/2009/10/slider-a-mobile-version-of-the-flex-frame=
work/
>>=20
>>=20
>> --
>> Sebastian (PPMC)
>> Interaction Designer
>>=20
>> Looking for a Login Example with Apache Flex? Please check out this code=
:
>> http://code.google.com/p/masuland/wiki/LoginExample
>>=20

--=20
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui