<hhalpin>
ACTION:[CONTINUES] tinkster
to add user story along lines of... if you enable import of
contacts from other sites, then it lowers the barrier to entry
for new people signing up at your site, hence get more users,
hence get more advertising revenue. [recorded in http://www.w3.org/2009/07/29-swxg-minutes.html#action12]

rreck: spoke to friend to alter
photo settings, and didn't agree with how the pics were
used
... supporting SNS, problem faced is more paid propaganda.
Matrix to determine the messages, whether the messages are
propaganda or not

<trackbot> Created ACTION-64
- Write up use case based on shill case [on Ronald Reck - due
2009-08-05].

<PhilA2> close ACTION-63

<trackbot> ACTION-63 Write up
use case based on situation closed

hhalpin: clean up use case
docs

<hhalpin> yes?

<hhalpin> I can hear you.

hhalpin: categorise use cases and
user stories to make them more legible

fabgondon speaking?

<AlexPassant> mattroweshow:
yes

<rreck> i think maybe just
adding attributes to the use cases

fabgandon: very distributing use
cases covering different topics
... categorised by business and other topics, some of the
scenarios are not covered by certain fields

hhalpin: group use cases
abstractly?

fabgandon: good initial step,
some are very technical compared to others

<hhalpin> Maybe separate the
more technical ones from the less technical ones?

<rreck> im wondering about
usecases about situations that ARE being dealt with in current
implementations

fabgandon: some scenarios are
just functionalities

<rreck> i think its important
to have authors per usecase so there is someone to talk to
about one

hhalpin: separate use cases which
are functionalities from others. use cases have different
levels of abstraction. address business developers and
users
... separate use cases into 3/4 buckets

<hhalpin> someone to talk
to?

fabgandon: need someone to talk
to about a use case

<rreck> i think the use cases
should have unique identifiers so that we can refer to them
from other contexts

fabgandon: point of call needed
for each use case, in order to get the details

<AlexPassant> what about
'champions' for each use-case (as done in the SPARQL WG for new
SPARQL features)

what is champions?

are*

hhalpin: need author information
next to the use case

<rreck> maybe we can ask
author to add themselves to the use case

<rreck> or champions

<rreck> +1 champions

<melvster> +1

hhalpin: get use case doc by
fall

<FabGandon> +1 for champion /
contact per use case

+1

<rreck> agreed we need a
milestone for usecase "completion"

<rreck> i think
recommendations in the report should/could be tied to
usecases

<hhalpin> PROPOSAL: Each
use-case gets a champion whose job is to determine the audience
and the functionality, as well as fill out the existing
template, and then is needs be rephrase the use-case on the
right level of abstraction. Use-cases without champions will be
dropped.

+1

<rreck> +1

<melvster> +1

<AlexPassant> +1

<MacTed> +1

philA: functionality or
requirements?

<rreck> functionality is
possibly to technical?

hhalpin: not designing a
tech'

<hhalpin> funtionality is too
technical?

PhilA1: in use case doc normally
have use cases and requirements

<rreck> at a high level
people know what they want, not how it can be accomplished

fabgandon: divide scenario into 2
types: before and after

<rreck> i think as a group we
should focus more on what is to be accomplished

fabgandon: how was the scenario
before? what was the requirements?

<rreck> +1

hhalpin: what are the initial
requirements? what functionalities could achieve this?

<trackbot> Created ACTION-65
- Send some thoughts on new template to be sent out to listserv
[on Ronald Reck - due 2009-08-05].

<rreck> modified rather

<melvster> question: what if
more than one person wants to champion a use case?

<rreck> i think that is
imperative

champions is a good idea

<PhilA2> the champion per UC
sounds like the way forward to me

<PhilA2> There's a lot of
work that needs splitting up

hhalpin: use cases to have
champions, any objections?

<hhalpin> RESOLVED: Each
use-case gets a champion whose job is to fit the use-case to
the template, as well as fill out the existing template, and
then is needs be rephrase the use-case on the right level of
abstraction. Use-cases without champions will be dropped.

<PhilA2> +1

+1

<melvster> +1

<FabGandon> +1

<MacTed> +1

<hhalpin> 4. Invited Guest
Invitations

<rreck> i think XG
participants should attend or give regrets

<hhalpin> Any
suggestions?

<rreck> invited speakers are
good

hhalpin: have the invited
speakers been useful?

<hhalpin> Should we keep
doing this?

<rreck> +1 continue
speakers

PhilA2: good for the group, opens
up discussions

hhalpin: tradeoff between
speakers and how to move forward

<MacTed> +1 continue

<rreck> i think focus on
deliverables is important

hhalpin: last 3/4 meetings were
invited speakers, should we have less speakers and more
deliverables?
... may not get work done due to speakers