Re: Basic processes

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

Received on Sunday, 18 November 2012 18:52:25 UTC