W3C home > Mailing lists > Public > public-sysapps@w3.org > November 2012

Re: Process proposal

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 6 Nov 2012 07:48:21 -0800
Message-ID: <CAJE5ia-3skjsRgCYO2aFC2ox7GYB7MOmC5xqqtDYd-pKWHoCYg@mail.gmail.com>
To: John Lyle <john.lyle@cs.ox.ac.uk>
Cc: "public-sysapps@w3.org" <public-sysapps@w3.org>
I'd recommend starting with the System Applications wiki:


If we need something fancier later, we can switch to something more complex.


On Tue, Nov 6, 2012 at 1:11 AM, John Lyle <john.lyle@cs.ox.ac.uk> wrote:
> On the subject of process and proposals, I was wondering if there were any
> tools or formats that W3C working groups were recommended to use for
> describing requirements, use cases, threats, risks and other
> pre-specification data?
> For the security model deliverable it seems unlikely that there will be much
> agreement (or productive discussion) until there is a consensus on the
> requirements, assets and threat model.  Or at least what the scope of this
> working group is.  As such, these seem like essential documents to put
> together and collaborate on.  I know that there are many different processes
> (Trike / Octave / Microsoft's / CORAS / etc) but most of the actual output
> is likely to be the same, particularly if there is a consistent vocabulary
> and format.
> Wikis and documents are a bit limited when it comes to describing and
> linking requirements and their related artefacts.  When working on other
> projects we've used our own tool, CAIRIS [1] and published the data [2], but
> we've also found it easier to collaborate using spreadsheets (indeed, I'm
> using Google Docs to try and do *some* of parts 1-4 of Josh Soref's
> excellent suggestions now [3,4]).If there are any commonly-used tools for
> this purpose I would be very grateful to be pointed in their direction.
> Thanks,
> John
> [1] https://github.com/failys/CAIRIS
> [2] https://github.com/webinos/webinos-design-data
> [3] Some consolidated threats and assets -
> https://docs.google.com/spreadsheet/ccc?key=0As1cqcmobbEvdEhyOFN3ZU82QlMyR1FDUjlMSWRuM3c
> [4] Background analysis -
> https://docs.google.com/document/d/175vNhHLPdjYb7iwRBlLmSa3SsSIATpYZ7kpFyy-eYI0/edit
> On 26/10/12 19:27, Josh Soref wrote:
>> I've spent a bit of time in a number of groups and think that a lesson
>> learned could be useful.
>> CoreMob (really Facebook) did research into an area and then moved
>> straight to trying to publish roughly a "specification".
>> Then people asked "what UC/Requirements are you addressing?" (roughly:
>> "why are you doing this?"), and CoreMob didn't have an answer - because it
>> hadn't published its research.
>> For defining an API, these are the things which I think should be
>> answered:
>> 1. [UC] What are the general Use Cases which you're trying to address?
>> 2. [Req] What are the specific technical Requirements to address the UCs?
>> 3. [API] How have others tried to address these UCs and Reqs?
>> 4. [Use] Given others' APIs for these UCs/Reqs, what have people produced
>> which uses this solution?
>> 5. [QQs] What questions have people asked about others' APIs?
>> * [UC]+[Req] can be published as a single combined Use Case and
>> Requirements document, or as separate documents, but they should be
>> published.
>> * [API] can be initially a wiki and will probably end up in an informative
>> appendix to a published specification.
>> * [Use] should be a survey - roughly producing a spreadsheet, preferably
>> with some charts showing popularity/use - preferably highlighting which
>> UCs/Reqs are addressed/how well/how used.
>> * [QQs] can initially be some sort of wiki/spreadsheet - it should show
>> which are the most common causes of confusion / problems that aren't easily
>> solved for the existing APIs. It doesn't need to be published per se, but
>> being able to reference it informatively from the spec is useful "we tried
>> to avoid (most) these problems when we wrote our specification". Sources for
>> this include sites like "Stack Overflow" (as well as any group's actual FAQ
>> pages).
>> I think that SysApps (and really every other group) should keep this in
>> mind when it tries to produce any API.
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential
>> information, privileged material (including material protected by the
>> solicitor-client or other applicable privileges), or constitute non-public
>> information. Any use of this information by anyone other than the intended
>> recipient is prohibited. If you have received this transmission in error,
>> please immediately reply to the sender and delete this information from your
>> system. Use, dissemination, distribution, or reproduction of this
>> transmission by unintended recipients is not authorized and may be unlawful.
Received on Tuesday, 6 November 2012 15:49:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:10 UTC