Re: CSVW WG requests PR transition - Kudos and Plea

Hi David,

I will reiterate, we are not making all the changes that you are asking for
because we do not agree that they are necessary or helpful in the spec.

We are creating a Primer which is what we expect most people to read. That
is a more appropriate place for how-to guidance to users about different
approaches and pros and cons.

I would likewise encourage you to direct your passion for making users'
lives easier into creating guides and tools for people adopting the
standard.

Thanks,

Jeni

On Tue, 10 Nov 2015, 21:18 David Booth <david@dbooth.org> wrote:

> [Re-sending in two parts. This is part 2.]
>
> Maybe you are all too pissed off at me (for being so pushy) to be able
> to assess my suggestions without bias.  But I'm sorry, that's no excuse.
>   This spec is not for me, it is for the entire community, and any
> reasonable editor should be able to recognize that this spec would be
> significantly improved by making the *most* commonly used feature more
> *visible* to readers in a way that is accurate and reflects readers'
> likely use of the spec.
>
> The continued attempt by the editors to portray the "standard metadata
> filename" feature as an inseparable part of the "site-wide location
> configuration" feature is simply *misleading*.  It is *not*
> how users will see it, it is *not* historically how it developed, and it
> is *not* technically accurate.  (Technical test of separability: could
> feature X be provided without feature Y and vice versa?  Yes.)
>
> I was disappointed that nobody on the working group felt able to stand
> up to Mark Nottingham and push back on the TAG by pointing out that the
> TAG's perception of the standard metadata filename feature's impact on
> web architecture was simply *incorrect*.  It is unfortunate that this
> architectural mis-perception has not been corrected.  But I can
> understand that others in the WG may not have had the time or
> inclination to dig into the question as deeply as I did, and from that
> perspective it was certainly understandable that the WG chose to defer
> to the TAG's guidance rather than listening to little me.  And in the
> end, the inclusion of the .well-known feature causes very little
> substantive harm -- it mostly just adds cruft -- *given* that the
> standard metadata filename feature that users *really* need is still in
> the spec.  (Thank goodness!)
>
> I have very high personal and technical respect for all of you, and I
> very much appreciate your efforts.  You all have done an enormous amount
> of work on this spec and its implementations, whereas I am not a member
> of the WG and I have only made occasional comments here and there in my
> attempts to help.  And since this issue is purely editorial at this
> point, it really is up to you to decide how much work you are willing to
> do to benefit the spec's readership.  I won't make a stink about this if
> the WG decides to do nothing.  But I do still entreat you to think about
> this from the *reader's* and *user's* perspective.
>
> Almost *no* users will give a rat's ass about the "site-wide location
> configuration" feature.  But *all* of them will care about the "standard
> metadata filename" feature.
>
> I am not asking you to remove the "site-wide location configuration"
> feature.  It is there for anyone who feels the need to use it, and it
> satisfies the TAG's guidance.  But I am asking you to *please* -- for
> the sake of the community -- make more visible the feature that *all*
> users *will* care about: the "standard metadata filename" feature.
> Users will *not* think of it as a default of the "site-wide location
> configuration" feature.  They will think of it as the "standard metadata
> filename" feature.
>
> Thanks for reading, and thanks again for all your hard work,
> David Booth
>
> P.S. Apologies again for the poor choice of words in my previous draft
> of this message.  Based on the fact that multiple of my previous
> comments appeared to have been studiously ignored until someone else
> independently voiced the same concerns, I guess I unnecessarily
> attributed the editors' inaction to malice when I should not have done
> so.   (It certainly *appeared* that the editors were angry and hence
> treated my comments differently than other's.)  Again, I apologize.
>
>