Re: a couple of concerns

Hi Annette

Thank you; I appreciate your thoughtful comments here.  I'm sorry that this
happened, and I think you're right to raise this.

I've just discussed this with Phil, and he is looking into the implications
for the draft we've just agreed to publish.  He'll let us know how that
unfolds.

To fix this:  We can try to get another draft out to address these concerns
quickly, if you can be entirely clear what you think should be changed (and
establish with the editors what they were intending when they put them in)
— then we could sort this on Friday, with new text (frozen) for Monday or
Tuesday so that next week we can vote on another version.

Going forward: we do need to be more meticulous about:
a) giving the entire working group at least 4 days (with final, frozen
text) to review anything before we vote to publish it
b) agreeing that, ideally, no changes should be made after we publish.

(This does take some negotiation, and — unfortunately — can be part of why
the standards process takes a while!  But it's important to make sure what
we're publishing reflects the consensus of the entire group.)

If you're okay with that, we'll put it on the agenda to clear up your
concerns about the REST API best practices for Friday.  Do confirm.  And
thanks again for bringing this up.

Cheers,

   Hadley



On Tue, Jan 5, 2016 at 11:12 AM, Phil Archer <phila@w3.org> wrote:

> Thanks for this Annette, please see inline below.
>
> On 05/01/2016 06:35, Annette Greiner wrote:
>
>> Hi all,
>> I’d like to raise a couple of issues that have been bothering me of late
>> in our process for developing the DWBP best practices doc. The most recent
>> version contained some last-minute changes that I disagree with, which
>> points at two different issues.
>>
>> First, we should not be making editorial changes that change the sense of
>> the text after a vote to publish.
>>
>
> Definitely true.
>
>  While I’m sure that the editors have never intended to do that, the doc
> has been undergoing a flurry of post-vote changes each time, and these have
> sometimes affected the meaning. I am concerned about the pattern of delays
> in getting the document into a stable state and the lack of stability at
> the time of voting and immediately thereafter. I think we need to be voting
> on a document that is as we expect to publish it, including all changes.
> This would require a publication schedule with dates on which feedback is
> due and by which changes must be made, and those dates should be before the
> date on which we vote to publish.
>
> Correct, of course. I'm explicitly copying the (active) chairs who will, I
> am sure, respond to this.
>
>
>
>> Second, the most recent changes that prompted this concern are the
>> changes to the text regarding the best practice to use REST APIs. I took
>> some pains to include the two main approaches to using REST in my
>> submission for that BP, and while I must admit that my writing was not
>> successful in making the distinction clear, since it wasn’t clear enough to
>> the editor to preserve it, I was surprised to see how far from my intent
>> the published text appeared. I would be happy to give another try at
>> teasing apart the two approaches. I do not feel that the current BP
>> reflects what most web developers would consider best practices for
>> developing with REST and REST-inspired architectures.
>>
>
> Ack.
>
> My suggestion is that a new version of the doc is prepared as soon as
> possible and, following suitable WG review, published.
>
> Thanks for bringing this up, Annette, I'm sorry it was necessary.
>
> Phil.
>
>
> --
>
>
> Phil Archer
> W3C Data Activity Lead
> http://www.w3.org/2013/data/
>
> http://philarcher.org
> +44 (0)7887 767755
> @philarcher1
>