Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of omarg.developer@gmail.com
 designates 209.85.212.177 as permitted sender)
MIME-Version: 1.0
Sender: omarg.developer@gmail.com
In-Reply-To: <CB84CC3A.3D89E%aharui@adobe.com>
References: <72C14F5D-9F0B-46BA-A830-A7EA46FEB91B@classsoftware.com>
	<CB84CC3A.3D89E%aharui@adobe.com>
Date: Tue, 13 Mar 2012 10:12:28 -0700
Message-ID: 
 <CAEFz_vvdAxSe=2vscs7k7pb_ncnPuQHOOdRq_WR_KCjHHqv+7A@mail.gmail.com>
Subject: Re: SDK Inclusion Process (was re: [OT] What are we doing here?)
From: Omar Gonzalez <s9tpepper@apache.org>
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=f46d043c093eb2427004bb22f6f3

--f46d043c093eb2427004bb22f6f3
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Mar 13, 2012 at 10:04 AM, Alex Harui <aharui@adobe.com> wrote:

>
>
>
> On 3/13/12 12:24 AM, "Justin Mclean" <justin@classsoftware.com> wrote:
>
> > Hi,
> >
> >> I may change my mind about this in the morning, but this is just too
> much
> >> process.
> > I see it as more of a list of what you may need to think about/get other
> > people to help you out along the way with rather than a step by step
> process.
> > Perhaps I should of left off the numbers? I certainly don't think that a
> > contribution would need to address all of those concerns initially but it
> > would be not to nice to say to the list  "I've not considered any
> localisation
> > issues with this contribution can someone take a look at that for me" or
> "I've
> > no idea if this works well n Android/iOS".
> I don't agree.  If you don't have an IOS device, that shouldn't be a
> blocker. If you don't have a Mac, that shouldn't matter either.  That is
> the
> advantage of community.  Folks help each other by contributing their
> expertise.


> Yes, most of us have the experience to at least think a little about
> localization, but I can guarantee I don't know as much about it as some of
> you.  The next time I contribute a brand new component, I expect there to
> be
> issues with localization, accessibility, the names of the APIs, and there
> will be bugs in it.  But at least there will be code to look at and
> improve.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
I don't think Justin is saying it should be a blocker. I believe what is
being proposed is that it be used as a list to evaluate things that need to
be done to contributions. For example, let's say you write up some
component, and like you said you didn't really consider localization
because either you don't care or you don't know enough about localization
to add that in. The list would be used POST-contribution to get the
component through the last things needed, _with_ the help of the community
and other contributors, to get the component in a state where the community
will vote it in as part of an SDK release (or however we end up doing that
process).

I don't think the checklist being proposed is a list specifically for the
contributing developer, but more of a guide as to what we should address
before taking someone's contribution and making it an official part of the
SDK.

As an example, Tink has his layouts and containers in whiteboard. What now?
We have no process to take his contributions and get them in the SDK.
Defining a process does not necessarily mean that Tink HAS to perform all
those tasks... but _someone_ should, either other committers or the
community so that we can put that 'official stamp' on them.

Is this a bad thing? Or are we proposing that people just put in any code
in any state into the SDK so long as the community votes it in (or some
other procedure)?

-- 
Omar Gonzalez
s9tpepper@apache.org

--f46d043c093eb2427004bb22f6f3--