Return-Path: X-Original-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E27B89D43 for ; Mon, 6 Feb 2012 15:47:57 +0000 (UTC) Received: (qmail 97327 invoked by uid 500); 6 Feb 2012 15:47:57 -0000 Delivered-To: apmail-incubator-flex-dev-archive@incubator.apache.org Received: (qmail 97269 invoked by uid 500); 6 Feb 2012 15:47:56 -0000 Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: flex-dev@incubator.apache.org Delivered-To: mailing list flex-dev@incubator.apache.org Received: (qmail 97261 invoked by uid 99); 6 Feb 2012 15:47:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Feb 2012 15:47:56 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of joao.saleiro@webfuel.pt designates 216.154.217.150 as permitted sender) Received: from [216.154.217.150] (HELO webfuel.pt) (216.154.217.150) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Feb 2012 15:47:47 +0000 Received-SPF: softfail (webfuel.pt: domain of transitioning joao.saleiro@webfuel.pt does not designate 77.54.127.141 as permitted sender) receiver=webfuel.pt; client-ip=77.54.127.141; helo=[192.168.1.71]; envelope-from=joao.saleiro@webfuel.pt; x-software=spfmilter 0.97 http://www.acme.com/software/spfmilter/ with libspf2-1.0.0; Received: from [192.168.1.71] (141.127.54.77.rev.vodafone.pt [77.54.127.141]) by webfuel.pt (8.14.3/8.14.3) with ESMTP id q16FlNjD022473 for ; Mon, 6 Feb 2012 15:47:24 GMT Message-ID: <4F2FF609.70403@webfuel.pt> Date: Mon, 06 Feb 2012 15:47:21 +0000 From: =?ISO-8859-1?Q?Jo=E3o_Saleiro?= Organization: Webfuel.pt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: flex-dev@incubator.apache.org Subject: Re: Creating Working Groups [Was: Apache Flex suggestion - dumping SWF support in favor of HTML5 - listen to Steve] References: <6035f101$740f9175$752d89cb$@com> <02d401cce4b5$5d8284b0$18878e10$@davidarno.org> <4F2FA8B5.5090403@webfuel.pt> <4F2FAF6B.6090703@leichtgewicht.at> <4F2FDDAE.30505@leichtgewicht.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org On 06-02-2012 14:28, Jonathan Campos wrote: > Why do you need consensus just to get started? I think this thinking on the > ml is continually crippling are our output. I started this discussion to see if it was possible to provide "sandboxes" to each separate initiative, so groups of people can organize around each initiative. Since there is not a common roadmap and anyone can have their own idea, many people will be pushing Flex in their different directions (which is a good thing). The current model is nice if there is no disruption from what we have and everyone is creating small features here and there. But I currently see people wanting to invest time in completely parallel ideas: (1) Making Flex reach 4.7 (2) Refactoring the framework to make it more lightweight and modular - Flex 5? (3) Researching and implementing solutions for exporting the existing SDK to JS/HTML5 (4) Building a new SDK from scratch specifically designed to target HTML/JS (5) add your idea here. Until now, we've seen many people proposing either one of the above topics, with enough energy to start working on it. Instead of answers like "well, I might not agree completely, but here you have: share your vision in this wiki, put the code here, and start working on it (and remember that there's a risk we might not accept it)", we're just seeing answers like "No, I don't agree", "Yes, I agree". Let's give these people resources to start working on their ideas, and to help others who believe on them work together around the same objective. Imagine I just subscribed to the ML. I'll start by reading a couple of emails in the history, but I won't read 2 or 3 thousand emails for sure. I have an idea for something I would like to work on, so I send an email suggesting it. I don't have a clue if someone else is already working on it. In the model I'm suggesting, either: (1) someone already had a similar idea, so people would simply answer by indicating the wiki page URL, that would have some info (vision, roadmap, specifications) on that idea, the respective branch, and a listing of the persons currently involved (2) it's a new idea and there's a positive feeling around it so I get the resources to start my own sub-project. Other people might join later. If we don't provide tools to help people with disruptive ideas organizing in groups, they'll simply get those tools outside of Apache and probably discuss and work outside of Apache, and then bring them in when they feel it's ready. Not that this is a bad thing, but I would prefer it if was easier to keep self-organizing groups of persons with a similar idea as close as possible to Apache. For example, I have a disruptive idea for Flex that I would like to work on in a mid-term future. It's a completely different one from what has been discussed before, and while many people will relate to my vision and be willing to join, many other might be completely against it. If I decide to start working on it and others want to join, should I get a wiki+branch+Jira project+ML outside of Apache (which means, I'm working outside of Apache...), or should I use the existing resources (that are all dedicated to one single huge project, so I'll be generating unwanted noise for all those who don't share my vision) ? What if we consider a solution that involves providing easily resources to each sub-project (a codename, access to a part of the wiki, a folder in the SVN, a JIRA project, and a ML [Tag] (for filtering)) ? This way, everytime someone joins the ML and says "I want to see Flex exporting to HTML5", we'll simply say "ok, here's the link to wiki page for that sub-project, here's where you commit code, here's where you track the issues, and if you send emails related to that subject add the [HTML5EXPORT] tag to the subject"... Jo�o Saleiro