Re: [pbd-se] Uber review of the reviews of wd04 R2

[<frederick.hirsch@nokia.com>]

It seems to me that with the number of comments to be folded into the next draft, including comments changing normative status, that at least a week (or two) should be provided after the merged draft is released, to allow review of the changes in situ, plus a chance to see if anything was missed. 

I would suggest allowing this review before a CSD vote. Doing so should avoid re-work and comments later in the process, so  It should save time in the long run. I don’t see how we can expect good review in a day.

regards, Frederick

Frederick Hirsch, Nokia

@fjhirsch

On Jun 16, 2014, at 7:36 AM, ext Sander Fieten <sander@fieten-it.com> wrote:

Hi Dawn,

we certainly can vote on approval of the working draft as a CSD. But I do not think this first version CSD will be ready for PR. Of course TC member can submit comments during PR, but I expect the TC members agree on the CSD when it is submitted for PR. And I do not think it is reasonable to vote for PR this meeting. There will need to be at least one round of review.

Regards,

Sander

----
Sander Fieten
IT Architect

FIETEN IT
e: sander@fieten-it.com
t:  +31 6 51507886

On 16 Jun 2014, at 12:18, Dawn Jutla <dawn.jutla@gmail.com> wrote:

Many thanks Colin and Jonathan! Also very helpful. 

Co-chairs will aim to send out an updated master document by Tuesday evening to the TC, and a spreadsheet showing accepted/modified/rejected edits across all contributions and reasons for alternative views, and how we addressed some comments/edits with clarifying new text in the working document. We will discuss alternative views on Wednesday's call. 

We are aiming for a first version CSD so it will be the final item on Wednesday's agenda. 

Also for newer TC members: in the process, the public review period will give the TC members (along  with the public) another period to provide further edits and comments. We can subsequently keep updating the CSD as many times as we like until we are satisfied with the output.

Kind regards,

Dawn.

On Mon, Jun 16, 2014 at 3:30 AM, Mr. Colin Wallis <Colin.Wallis@dia.govt.nz> wrote:

Folks,

I've looked at the comments circulated, at the time of this email (ss, sabo and sf). Broadly I support them (easier where proposed text has been provided!)and they more than cover my main areas of concern which were the normative text in Section 2, and Section 5 moving to an appendix.

The only area that does not seem to be covered is the Introduction, where on the call, we agreed that the text needs to be modified to recognize the role of the organization's governance processes in overseeing the efforts of the software engineer in respect of PbD.
To that end, I offer a start on the following..

From 1: Introduction: The PbD-SE specification helps engineers to visualize, model, and document PbD requirements and embed the principles within software engineering tasks. Add..**It also helps inform those organizational governance processes that oversee the engineers**.

From 1.1: The protection of privacy in the context of software engineering requires normative judgments to be made on the part of software engineers, add..**in the context of organization-wide governance of privacy protection**.

1.2 and 1.3 seem to be OK as is.

Cheers
Colin