Re: Smoothing the edges by example (was pilot case?)

On Wed, May 8, 2013 at 1:07 PM, Clint Hill <clint.hill@gmail.com> wrote:
> I'd like to add a few things that I feel are important for getting more
> adoption. You could call these goals too I suppose.
>
> 1. We need a better story for the average developer/engineer who is having
> trouble due to browser limitations but has a great idea. We need to
> educate this person that they should prollyfill.

If they can... currently it is harder than it should be. In the short term,
we can work on that with engines and what not, but there are some very
important topics on how to better layer/prioritize things at the
platform/WG levels so this becomes more easily possible. We have folks
working on that.

>
> 2. For these average developers/engineers we need a very clear and very
> easy project template for their great idea. This template includes
> fixtures for tests, examples for documentation and all of the normally
> expected OSS artifacts. Yeoman generators are a good idea here. I believe
> that Chef has a great pattern for cookbooks and that we could provide a
> similar framework for developers to use in building their prollyfill.
>
That is kinda what I was saying... Not as a policy, or anything, but just
as some people on this list, let's try to run one or more of these things
through with an increasingly better git and see what works well/makes the
next one (or the transition to WG) easier and so on.  Ultimately, it would
be nice if some of us contributed some tools or generators to help that
imo. But to do that you really have to figure out what to automate in the
first place, thus my suggestion about working through a few thoroughly.

> 3. These developers/engineers should get this great idea published into
> the prollyfill registry for free. The said project template should
> automate the registration for them (I'm thinking of Ruby gems like
> Jeweler).
>
This has come up a lot, let's start another thread.

> 4. There needs to be an "engine" that runs the prollyfills that developers
> need not worry about. The responsibility of the engine is to execute the
> prollyfill for which ever target the developer has (JavaScript, CSS or
> HTML).
>
> Now I've assumed many things in those steps [engine, registry, project
> template, code generators] but I think those are the things we fill in.
> Having these things in place makes the work of getting it in front of the
> right WG much easier and with some organization. I would assume most WG
> would be displeased if all the great ideas came at them in varying forms
> but are all called prollyfills.
>
Maybe, but only by working through can we really determine, right?

> It's my opinion that we could collect tons of experience and we can do the
> research to smooth out the edges - but it would all be for not if the
> above things don't get better and easier.
>
>
>
> On 5/8/13 9:05 AM, "Marcos Caceres" <w3c@marcosc.com> wrote:
>
>>
>>
>>On Wednesday, May 8, 2013 at 4:36 PM, François REMY wrote:
>>
>>> > Documenting the experiences would be
>>> > of great value to the community, we
>>> > just need to do it (once we get enough
>>> > experience).
>>> >
>>> > I have experience from prollyfilling a
>>> > few APIs with the WebIDL projectÅ  and I
>>> > plan to do a few more in the near future
>>> > (for SysApps).
>>> >
>>> > I'm happy brand that work as having come
>>> > from this CG.
>>>
>>>
>>>
>>> Nice. I agree that experience is a prerequirement on that front. Brian
>>>has a good and growing experience on prollyfilling CSS from which we can
>>>build upon, too.
>>Absolutely. The problem is that we have no criteria to measure if what we
>>are doing is any good or not. Mechanical tools aside (linting or
>>whatever), knowing if the quality of what we are doing is any good
>>requires independent evaluation from our peers (who may or may not know
>>what they are talking about). Best we can do right now is share our
>>experience and pain points - and hopefully users of our tools can do the
>>same.
>>
>>Alternative is to look at prollyfills that are used in the wild by large
>>number of developers (e.g., parts of JQuery, picturefill, etc.) and see
>>if we can spot some patterns (and come up with reasons as to why we think
>>those are good patterns). And evaluate where the developer of the
>>prollyfill has struggled because of platform limitations. If we find
>>those limitations, we can then take them to various WGs and say: "see!
>>people are trying to do X and they can't - we need primitive X". For
>>example:
>>http://stackoverflow.com/questions/5136727/manually-artificially-throwing-
>>a-domexception-with-javascript
>>
>>We can also present these patterns to, for example,
>>public-script-coord/TC39 and ask them if they are idiomatic uses of
>>javascript.
>>
>>With WebIDL.js, we have basically 0 users right now (as it's not done and
>>not yet practical to use in a project). I'm trying to grow that to a
>>handful with specs I am prototyping, but so far it has only been me doing
>>the prototyping.
>>
>>Brian can probably reveal his usage stats for Hitch.
>>
>>Hope that makes some senseÅ 
>>
>>--
>>Marcos Caceres
>>
>>
>>
>>
>
>

--
Brian Kardell :: @briankardell :: hitchjs.com