Re: Recommendation template (Was: Editing process for Recommendations)

Agreed.  I think that would be easiest to manage.

Close, Tyler J. wrote:
> Yes, a standalone wiki page is fine.
>  
> Tyler
> 
>     ------------------------------------------------------------------------
>     *From:* Mary Ellen Zurko [mailto:Mary_Ellen_Zurko@notesdev.ibm.com]
>     *Sent:* Wednesday, May 09, 2007 3:53 PM
>     *To:* michael.mccormick@wellsfargo.com
>     *Cc:* public-wsc-wg@w3.org; Close, Tyler J.; sduffy@aol.net
>     *Subject:* RE: Recommendation template (Was: Editing process for
>     Recommendations)
> 
> 
>     Tyler and Shawn, is that how you want them? I would assume so, in
>     the face of silence.
> 
>               Mez
> 
>     Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
>     Lotus/WPLC Security Strategy and Patent Innovation Architect
> 
> 
> 
>     *<michael.mccormick@wellsfargo.com>*
> 
>     05/04/2007 11:04 AM
> 
>     	
>     To
>     	<Mary_Ellen_Zurko@notesdev.ibm.com>, <tyler.close@hp.com>
>     cc
>     	<public-wsc-wg@w3.org>
>     Subject
>     	RE: Recommendation template (Was: Editing process for Recommendations)
> 
> 
>     	
> 
> 
> 
> 
> 
>     It looks reasonable.  I'll try using it and then may have more feedback.
>      
>     Should each Recommendation be a standalone wiki page, linked to from
>     the current Display Recommendations page?
> 
>     ------------------------------------------------------------------------
>     *From:* public-wsc-wg-request@w3.org
>     [mailto:public-wsc-wg-request@w3.org] *On Behalf Of *Mary Ellen Zurko*
>     Sent:* Thursday, May 03, 2007 8:21 AM*
>     To:* tyler.close@hp.com*
>     Cc:* public-wsc-wg@w3.org*
>     Subject:* Re: Recommendation template (Was: Editing process for
>     Recommendations)
> 
> 
>     Great structure for discussions; doing this will help us proceed
>     quite well.
> 
>     As I said during the meeting, I  specifically want to hear from
>     anyone doing a lightening discussion proposal about this template;
>     if they agree it's a good one (since they'll be filling it out), or
>     what changes should be made.  
> 
>              Mez
> 
>     Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
>     Lotus/WPLC Security Strategy and Patent Innovation Architect
> 
> 
>     *"Close, Tyler J." <tyler.close@hp.com>*
>     Sent by: public-wsc-wg-request@w3.org
> 
>     05/02/2007 01:25 PM
> 
>     	
>     To
>     	<public-wsc-wg@w3.org>
>     cc
>     	
>     Subject
>     	Recommendation template (Was: Editing process for Recommendations)
> 
> 
> 
>     	
> 
> 
> 
> 
> 
> 
> 
>     Here's a stake in the ground for our recommendation proposal template.
> 
>     --- Begin template ---
> 
>     Title
>       Each proposal must have a short name by which we can refer to it.
> 
>     Goals
>       Each proposal must reference the WG Goals
>     <http://www.w3.org/2006/WSC/drafts/note/Overview.html#goals> the
>     proposal helps achieve.
> 
>     Overview
>       Each proposal must provide a brief overview of the problem it
>     addresses and general approach being proposed to fix the problem. This
>     section should reference the usability principles
>     <http://www.w3.org/2006/WSC/drafts/note/Overview.html#usability-principl
>     es> violated by the current approach, as well as any usability
>     principles that will be upheld by the proposal.
> 
>     Dependencies
>       Each proposal must reference the Available security information
>     <http://www.w3.org/2006/WSC/drafts/note/Overview.html#available> it
>     relies upon. (I'll add anchors to the Note that can be the target of
>     hyperlinks).
> 
>     Use-cases
>       Each proposal must reference the use-cases
>     <http://www.w3.org/2006/WSC/drafts/note/Overview.html#scenarios> it
>     addresses. This section must provide more detailed description of
>     exactly how the user will interact with the proposed user interface. The
>     details provided in this section must be sufficient to enable
>     lo-fidelity testing of the proposal.
> 
>     Expected user behavior
>       Each proposal must discuss the user behavior it relies upon and that
>     therefore must be tested. Each item should refer back to a step in the
>     "Use-cases" section of the proposal. For example, a proposal might rely
>     on the user reacting in a given way to a specified indicator. The
>     proposal must call out what the needed user reaction is, as well as what
>     user reactions might be detrimental to the user's interests. For each
>     item, the proposal should list the motivations for the user to react in
>     the desired way as well as any factors that reduce the user's motivation
>     to react in this way.
> 
>     Disruption
>       Each proposal should list any significant disruptions it makes to
>     current user habits for web browsing. This section should help the
>     reader understand what issues might cause the proposal to not be
>     deployed, despite advantages it may have.
> 
>     --- End template ---
> 
>     I think the above template gives us the information we need to evaluate
>     a proposal and proceed with testing and implementation. I realize that
>     the template asks for a lot of content from the author and so we might
>     not get complete documents for many of the proposals by the F2F, but I
>     think that's OK. At least we'll know what we don't know.
> 
>     This email addresses ACTION-212.
> 
>     Tyler
> 
> 
> 
> 

-- 
shawn duffy - shawn.duffy@corp.aol.com
senior technical security engineer | aol it security
703.265.8273 | AIM: ShawnDuffy1
https://open-itsec.office.aol.com/
https://www.itsec.aol.com/

Received on Wednesday, 16 May 2007 12:12:28 UTC