Re: Next steps on layering?

On Thursday, May 16, 2013 at 7:11 PM, Alex Russell wrote:

> As per today's call, it seems time for us to consider next steps regarding what concrete things we should be doing related to layering. As I see it, there are some open questions about what the tag can do, as well as what it should do.
>  
> Here's a (smallish) list of ideas, all or none of which we could pursue. Looking for your ideas too, as I'm sure this list is missing quite a lot:
> Create a more formal review process for specs. The public-script-coord@ threads are great, and it would be good if there were a way for us to track our progress in review and follow-up on specs that ask for it. A nag-file for follow-ups alone might be worth it's weight in gold.

That would be nice. They could just be tracked as bugs on GH and people could request reviews from us there or on the mailing list. But we should certainly keep a list of specs being reviewed and it would be good to know who is reviewing them (for coordination). It would also be good to start showing some show of solidarity from the TAG - i.e., it might have more weight than us just running around making comments independently.  

(PS: Web Audio is turning into an absolute disaster spec - for the sake of developers and the Web, we should intervene there ASAP!)
> A page that helps WG's that want to "do it right" learn a set of concrete steps for how to engage best with us in helping to review their APIs early and most constructively.

Agreed.   
> A page that lists the specific strengths of the TAG's membership so that the right people can be pinged independently about issues. This seems obvious to us, but the world is a big place.

Sounds good.   
> A guide for how to design an idiomatic API in anger, including but not limited to:
> A discussion of imperative and declarative layering
> A library of common patterns to employ along with copy/paste-able IDL and JS examples to show how they can be used
> A discussion on how and when to think about the JS library ecosystem.
> Some common TAG-approved design principles to keep in mind when considering how to formulate a feature's API surface area
> A concrete walkthrough of an API that starts declarative in v1 and grows good, layered API later
> A walkthrough of an API that starts imperative and grows a declarative expression in v2

Could we maybe do some of this as a series of videos? It would be great to walk through and API or two and show how it could be changed by discussing the changes (would even be nice as a series, "The TAG Show: the Foo API gets it!"). If we keep the videos short, it would be much more fun/informative for people than reading a document.  

It would also be nice to have some kind of checklist - though not sure it can be simplified so much… might be a good starting point for the how to design an API document.   

Also, I think (well, hope) Navigation Controller, Fetch, JSIDL, Futures, and Event Streams should become TAG deliverables (or be heavily associated with the TAG). It will show that TAG members are actually shifting focus to provide not only guidance, but real technical solutions.   

--  
Marcos Caceres

Received on Wednesday, 22 May 2013 10:54:29 UTC