Re: Basic processes

On Nov 18, 2012 1:51 PM, "Marcos Caceres" <w3c@marcosc.com> wrote:
>
> Hi Brian,
>
> On Sunday, 18 November 2012 at 16:03, Brian Kardell wrote:
> > I'd like to discuss how we go from 0 to something on these.
> > Most ideas originate with a couple of use cases and maybe a gist or poc
github repo or blog entry to be discussed on this list. Some ideas may
influence existing ones or be joined up - but I think we need to eventually
create drafts that we can evolve and potentially eventually submit.
Francois has info on where those templates are and everything - and I am
wondering if anyone has ideas on a basic/practical process so we can get
the ball rolling.
> > Given a few initial proposals, and working through a few discussions I
think should give us the opportunity to set things up in a sensible way -
I'd like to hear what everyone thinks is a good place to begin.
>
> My opinion to get up and running ASAP is that we should start with clear
use cases (but not perfect or fully refined) and a small set of goals of
what we want to achieve. Each of these should be no more than a sentence or
two - and all together should all fit on a printed page. From these we
should each propose 3-5 ways of addressing the use cases as "paper
prototypes" (pseudo code or diagrams or email or whatever - just rough
throwaway stuff to get us all thinking). Note that based on the use cases
and scope, this can range from small documents, a framework, or
establishing a complete end-to-end ecosystem (as suggested by Clint).
>
> The reason we do 3-5 is to avoid problems of anyone becoming too onerous
about any one idea (and allows us to better explore the problem space).
This should last no more than 1 or 2 weeks. We can then evaluate each of
the prototype solutions by throwing realistic straw-man at them (e.g., we
implement a simple DOM API, a CSS rule or layout, or a HTML element). In
parallel, we should be documenting existing best practices to inform our
own prototypes (which may then spin off into it's own project).
>
> Once we have agreement on which solution we are going to go with, we
should break up the tasks amongst the group - in the case we don't get
consensus, we might have to vote or something. Each project should have a
lead who is responsible for managing production (and areas: e.g., community
management/comms, framework, server-side, etc.). Also, as more people join,
we need to be prepared to get them into the project up and running as
quickly as possible - this mean matching, or sometimes even creating tasks
to match their skill sets. We need to ask anyone that joins to say what
area they are strong in, and what they are willing to work on (i.e., we
need to create a culture of producing rather than observing - opinions are
cheap - pull requests are not).
>
>
>
> So what we absolutely must avoid, IMO, is a lot of "bla bla" on the
mailing list about theoretical solutions, etc. We want rough consensus and
running code that we can iterate on as fast as possible. We want code that
we can discard, chew on, etc. but never code that we consider gold (i.e.,
code proves itself stable by people continuing to use it). As we go forth,
this will mean setting up some basic guidelines and common coding
conventions (e.g., closure linter + JSHint + JS Beautifier).
>
> I also really like Clint's idea of thinking about this as achieving wider
ecosystem integration (and having a centralised place to find
poly/prollyfills). However, lets start small because we don't know how much
time we can commit yet; and there will naturally be some jostling between
us as we work out each other's strengths and weaknesses - and also we work
out who works best with who and what skills each of us has… so, we should
probably list what we think think we are good at and what we are interested
in doing.
>
> My skill sets:
>
> * JS, HTML, DOM
> * (W3C-style) spec writing
> * Project/product management
> * Some community management
>
> It's also important to keep in mind that we are unlikely to be working on
this full-time (I doubt anyone is getting paid), so our commitments will be
somewhat restrained. My intention is to try to merge the stuff I'm doing
with RICG with stuff happening here. I can probably commit 1 day a week to
this.
>
> Kind regards,
> Marcos
>
> --
> Marcos Caceres
> http://datadriven.com.au
>
>
>

Ok, Mozilla's Daniel Buchner suggested that we consider this one, maybe the
right thing to do is struggle thought how to get started on one, I am
hoping he joins the list as well, he expressed some interest:

http://www.backalleycoder.com/2012/08/06/css-selector-listeners/

maybe the best thing to do is to just dig into discussions as I know that
similar ideas are important in my/Clint's Hitchjs and have been illustrated
by (I think) Raphael in http://code.google.com/p/mutation-summary/ and
further discussions have been had by myself and Francois (and a few other
W3C folks offlist) with regard to how this might be related to our own CSS
Custom Properties proposal/fork of variables
http://fremycompany.com/TR/2012/ED-css-custom/

I don't suggest that our group's goal is to conclude there is one true way,
rather to share and discuss and promote both competition and
cooperation/bettering of ideas through cross-pollenation.

So - given this, how would we start?