42 lines
1.6 KiB
Plaintext
42 lines
1.6 KiB
Plaintext
|
'''UseCases'''
|
||
|
(x is good to have in EDN because we need it for y)
|
||
|
|
||
|
Those use cases will double as draft for the "why EDN" documentation of the
|
||
|
final product.
|
||
|
They should focus on the situation of a human using the
|
||
|
product.Avoid technical terms if possible.
|
||
|
Don't focus on mass, concise, prepare for a couple of iterations.
|
||
|
|
||
|
x = "A Glossary"
|
||
|
|
||
|
y = "to be clear about important concepts for developers and users."
|
||
|
|
||
|
This should only contain terms required for EDN. Furthermore it should
|
||
|
avoid references to implementations. Even for concepts which eventually
|
||
|
map 1:1 to EDN space.
|
||
|
We'll need this later when defining which APIs to map to plugins
|
||
|
for flexibility.
|
||
|
|
||
|
x = "To avoid any language suggesting that any particular data item
|
||
|
represents (or identifies) a human being"
|
||
|
|
||
|
y = "two reasons:"
|
||
|
|
||
|
a) This data item would accumulate reputation over time. While this is
|
||
|
something needed in certain context, "reputation" is meta data collected
|
||
|
elsewhere. Certainly it would be used as a key in "big data".
|
||
|
|
||
|
Since we need some reputation to connect humans, make always clear that
|
||
|
this data item (e.g. address) designates something the human possesses
|
||
|
at the moment.
|
||
|
|
||
|
If EDN grows big enough, the language which has manifested itself at
|
||
|
that time, will be used in court. This could really fire back.
|
||
|
|
||
|
b) It is an offense to the end user: When explaining the product, we
|
||
|
should be sure that rarely any end user having just understood how the
|
||
|
product works will advertise it to a technology-avers friend, point to
|
||
|
the screen showing anything other than the friends face and say "this is
|
||
|
you". Teach them from the beginning to say: "this is quasi the your
|
||
|
phone's number here".
|