►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hey
folks
and
welcome
to
another
update
of
real-time
update
of
issue
descriptions
this
week
with
a
particular
focus
on
awareness,
ux,
the
user
experience
of
the
awareness
feature
and
a
database
for
crdts.
So
let's
get
started
after
last
week,
where
this
merch
request
has
shipped
user
awareness,
and
the
awareness
session
for
collaborative
editing
is
finally
in
gitlab
merged
in
gitlab.
This
allows
us
to
build
awareness
sessions
into
gitlab
and
build
all
the
top-notch
UI
features
that
we
want
to
have
yeah.
A
So
how
is
that
going
to
look
like
the
last
week?
I
have
spent
a
lot
of
work
with
a
lot
of
work
on
the
user
interface
of
the
awareness
feature,
so
in
particular,
I
was
thinking
like
what
kind
of
States
we
have
like
how
many
users
we
want
to
show.
Where
do
we
want
to
show
the
online
users
that
you're
collaborating
with
Etc?
A
So
this
kind
of
like
shows
the
potential
states
that
we
have
right
now,
as
you
can
see,
there's
like
four
users
currently
online,
but
only
one
of
them
has
this
purple
purple
border
color,
and
that
means
we
only
have
one
user
who
is
like
actively
working
on
the
document
and
the
three
others
are
either
expectating
or
they
have.
You
know
just
switched
to
another
tab
or
another
window
and
like
no
paying
close
attention
to
that
issue
anymore
and
there's
also
a
limitation
of
like
just
four
users.
A
So
you
know
the
first
user,
second
user
and
the
third
user.
The
joints
that
that
collaborative
editing
session
is
going
to
is
going
to
be
shown
with
a
little
Avatar
image,
but
the
fifth
user
is
kind
of
like
hidden
behind
the
show
more
button,
and
this
is
because
we
have
a
limitation
of
space
in
the
sidebar
and
or
like
it
just
in
general.
It
doesn't
make
sense
to
show
like
100,
100,
Avatar
images
next
next
to
each
other.
A
When
you
click
on
the
more
button,
you
kind
of
like
get
a
pop
over
with
a
list
that
you
can
scroll
and
you
can
see
all
the
other
people
that
you're
collaborating
with
the
the
presence
of
a
user
is
defined
by
its
activity
on
this
on
an
issue.
So
as
long
after
you
have
joined
an
issue,
you
can
immediately
see
your
your
state
being
online
and
you
know
if
you're
not
doing
anything
for
like
five
minutes.
A
You
will
eventually
be
marked
as
a
way
automatically
by
the
system,
and
that
is
also
true
for
any
other
user.
So
this
this
presence
State
get,
gets
regularly
broadcasted
by
the
server
to
all
connected
clients.
So
this
is
like
a
an
almost
like
real-time
update
of
the
current
user
state
cool.
So
let's
have
a
closer
look
at
the
the
actual
awareness
UI.
So
what
you
get
when
you
hover
over
an
aperture
image
is
the
name
of
the
user
you're
collaborating
with
and
when
they
were
last
active.
A
So
this
is
kind
of
like
represented
by
human
readable
date.
So
you
can
see
that
I
was
active
on
this
document
within
the
last
minute
and
if
a
user
is
away,
we
cannot.
We
already
give
a
little
bit
extra
information
about
that
and
you
can
click
on
the
user
name
to
get
to
the
user
profile.
So
this
is
very
much
in
line
with
all
the
other
usages
of
Avatar
images
at
gitlab.
A
A
If
I
hover
over
it,
we
can
see
my
state,
my
name
when
I'm
away
it's
like
a
less
saturated
version
of
that
Alberta
image,
a
second
user
choices
session,
a
third
one,
a
fourth
one
and
the
fifth
is
kind
of
like
hidden
already
behind
the
load
more
or
show
more
collaborators
picture.
You
can
also
like
hover
over
that
you
get
a
bit
of
different
information.
In
that
case,
you
just
get
the
number
of
additional
collaborators
yeah.
So
what
are
the
next
steps
here?
A
I've
we're
still
not
clear
on
like
if
this
should
be.
If
this
feature
should
be
added
to
the
sidebar.
The
reason
is
kind
of
obvious,
because
the
sidebar
usually
has
functionality
around
like
editing
an
issue.
You
can
add,
remove
labels.
You
can
set
a
milestone
stuff
like
that,
but
the
awareness
feature
is
not
really
like
editing
anything
on
the
issue.
A
We're
probably
going
to
play
around
with
it
like
right,
aligning
it
to
the
to
the
issue
title
and
maybe
even
try
to
keep
it
like
at
the
top
to
the
where
the
breadcrumb
menu
is
that
menu
is
at
the
moment
and
yeah.
There's
another
prototype
that
I
want
to
add
to
the
work
items
prototype
because
there's
like
dedicated
space
for
that
yeah,
we
will
see
what
works,
what
works
best
and
yeah.
Take
it
from
there.
A
Second
thing
for
the
week
is
a
database
for
clts
and
the
reason
why
we
need
a
database,
because
here
it
is,
in
theory,
don't
need
a
database.
They
don't
even
need
a
backend,
but
we
have
already
built
by
Ruby
for
a
particular
reason,
because
we
want
our
backend
to
act
like
a
client,
and
another
thing
we
need
is
a
database
that
helps
us
to
that.
Helps
the
back
end.
A
A
What
we
are
going
to
end
up
building
here
is
a
redis,
a
redis-backed
database
or
a
user
radius
database
to
to
persist
the
crdt.
The
reason
for
that
is,
the
CDT
is
essentially
just
a
linked
list
under
the
hood.
So
every
list
item
represents
a
change.
Those
changes
can
be
easily
mapped
to
a
specific
state
that
a
document
is
in.
So
if
client
a
is
in
a
different
state
as
client
B,
they
kind
of
like
set
the
current
state
Vector
to
the
back
end.
A
The
back
end
knows
okay,
you're
kind
of
like
missing
those
four
changes,
fetches
that
from
the
database
returns
it
to
the
user.
Redis
has
a
data
structure
that
works
nicely.
For
that
it's
a
list.
We
use
an
additional
hash
map
in
order
to
store
like
state
offsets,
but
that's
not
really
a
lot
of
data
that
we
need
to
store
and
yeah.
The
Prototype
is
already
working,
we're
probably
going
to
release
that
as
a
companion
to
the.