Let's meet 11am-1pm, then do a working lunch (order in pizza?), then finish with a long afternoon stretch.
Thomas offered to be the notes-taker for for most of the day.
George: Write up "problem B" as a user experience description that can be turned into a user story.
Eve: Put the public-private continuum language and diagram into the Lexicon.
@@More TBS - figure out how to get all new user stories into place
Quorum not reached.
Deferred due to lack of quorum.
Two indications of submission interest have been sent in so far. The deadline for submission interest is 11:59pm Pacific time tonight.
We reviewed the new User Stories page. The page isn't very complete yet; Eve put in a sampling of user stories to test the columnal design, column sorting, and general "feel". Epics are tightly associated collections of stories; she has made epics all be in the "UX" category so that they focus on a human being's desire for some benefit. Some stories are "negative", in that they express some (typically malicious) entity's desired outcome that we want to avoid if at all possible.
It was observed that the stories zoom from high-level to low-level, and the "so that..." (motivation) portion of the descriptions could useful become more motivational and less technical/mechanistic even for the lower-level stories. Apparently the Ruby community likes to move the "so that..." portion earlier, in which case it would make sense to rephrase it as "in order to...". But since this is a fairly invasive change without obvious huge benefit we're likely to keep it in the current order.
Many new stories were suggested over the course of the rest of the meeting.
The "share" pattern and other patterns: At first through discussing the "Register resources and available scopes" story and the pending "Request registration of resources and available scopes" story, and then through general discussion and examination of the latest proposal, we drilled down into the likely tasks an authorizing user might want to perform to try and figure out the flows that need to be supported. The proposal supports the first of these stories but not the second.
The goal in the SMART project was to enable a user to click on a "share" button while visiting the host, and then be redirected to the AM to map a policy to that resource. The project also has the goal for the host to accurately display to the user the status of a resource (whether it has been registered at the AM or not). These generally fall under what we started calling "problem A", acknowledged to be likely in-scope for UMA 1.0 based on the SMART UX study experiences.
We also considered the possibility that the user might want to remain at the host while associating a policy with a resource for lowest possible UX friction, which we called "problem B", and to cancel protection for a particular resource while visiting the AM, which we called "problem C".