OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pbd-se message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Hi Sander:
I agree. I am not suggesting we vote on PR this June. 

Sent from my iPhone

On Jun 16, 2014, at 8:36 AM, 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.


Sander Fieten
IT Architect

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,

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

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]