►
A
B
B
A
The
difference
would
be
that
there's
separate
controls
over
who
can
edit
this
stuff.
Yes,
yes,
so
sort
of
the
main
you
see
like.
Well,
that's
one
of
the
main
issues,
whereas
I
attention,
everyone
can
edit
issues
nodes,
requests,
ethics,
whatever
requires
management
is
like
our
boss.
Coming
in
saying
you
must
do
these
five
things
like
right.
A
Good,
like
you
cannot
change
these
five
things,
but
you
can
say
maybe
add
links
and
so
I
tell
your
boss
by
like
adding
the
link
and
saying
this
thing
is
gonna,
be
met
by
like
this
epic
over
here.
B
A
B
Who
and
I
think
it's
usually
who
right
but
I
mean
in
these
big
organization,
that's
sort
of
like
a
given,
but
it's
really
like
the
timing.
Right
and,
like
you
said,
a
project
plan
and
then
the
first
month
is
about
requirements.
Elicitation
are
gathering,
so
this
is
like
sort
of
project
management,
101
old-school
with.
B
A
So
as
part
of
requirements,
management
and
then
depending
on
who
you
talk
to,
it
might
even
include
like
dance
and
like
project
gaming
and
of
like
how
you
deliver
those
requirements.
Not
just
the
definition
and
documentation
of
the
requirements,
but
formally
like
one
of
those
requirements
might
include
like
delivery
by
X
day
and
therefore,
yes,
only
like
the
scope
of
requirements.
Management
includes,
like
delivery
and
reporting
of
how
you're
tracking
to
delivering
the
sub
requirements
to
meet
some
delivery
date
requirement
exactly.
B
And
so
because
the
word
management,
it's
so
broad
in
such
a
broad
category,
right
like
for
versus,
say,
like
a
requirements
document
or
like
what
is
that
call
a
request
for
proposal
based
on
these
requirements?
Then
you
know
that's
a
little
bit
more
pared
down
and
well
better
define
usually,
but
then
like
what
you
said
is
yeah.
You
could
probably
find
a
website
that
says,
reliance
management
and
encompasses
all
those
things
that
you
mentioned
well,
when
you,
okay,.
B
B
A
A
A
Yeah
so
with
the
difference
then
be
like
I'm
trying
to
think
like
the
difference
might
be
like
some
sort
of
structures
and
UI
templates
for
like
designing
these
requirements
that
then
either
represented
in
text
or
like
it
can
be
edited
directly
in
text.
But
there's
like
some
merge
request,
control
process
that,
like
potentially
you
could
have
separate
rules
for
movie,
requests
that
the
light
to
the
requirements
repo.
This.
B
Is
the
major
class
even
think
about
that,
but
that
that
could
be
like
a
great
design
like
Gila?
Just
knows,
you're,
mr
is
is
has
these
files
right
and
then
it
displays
it
a
little
bit
differently,
something
that,
but
that
could
be
a
good
way
to
do
it,
but
like
yeah,
even
that
the
wiki
point
to
me
is
like
it
almost
says.
It's
like
sort
of
like
let's
debate
that
as
we
come
up
with
better
designs,
if
it
could
be
built
on
top
of
wiki's,
doesn't
have
to
be
and
then
sue
to
me.
A
B
B
About
that
a
bit
in
like
it
doesn't
matter,
because
let
you
have
your
awesome
design
of
like
you,
just
have
a
crew
point
to
a
project.
That's
sort
of
like
you've
solved
that
with
the
template,
design
right,
I,
think
all
the
stuff
that
I'm
working
on
should
be
group
level
anyways
in
general,
because,
like
these
earlier,
we
want
to
go
after
the
enterprise
and
then,
like
you,
know,
things
shorten
time.
A
You
see
your
requirements
could
still
live
in
a
rape
by
somewhere
like
that.
Would
because,
at
the
moment,
on
the
create
side,
we
don't
have
repositories
that
live
out
another
project,
so
even
group
level
wiki's
we're
proposing
to
make
that
sort
of
like
shim,
that
in
by
like
exactly
a
project
that
has
everything
turned
off
except
the
wiki,
and
then
you
can
like
flag
that.
So
it's
it's
at
the
throat
or
project
list.
So
it's
like
start
or
featured
project
and
it's
the.
B
Wiki
exactly
exactly
to
me,
that's
the
that's
like
an
implementation
detail
that
that
you're
solving
and
then
sort
of
we
take
advantage
of
that
from
a
requirements.
Management
perspective
like
at
the
moment
we
say
requirements,
management
is,
is
using
repos.
Then
we
sort
of
like
ride
on
your
coattails
of.
However,
you
want
to
solve
that
to
do
your
group
level
use
cases
and
then
we
sort
of
built
on
top
on
that,
at
least
that's
how
I
think
about
it.
Yeah.
B
B
Reusing
issues
and
for
issues
we've
had
this
long
discussion
about
not
a
long
discussion
but
saying
should
the
descriptions
be
source
controlled
as
well.
So
if
the
descriptions
are
source
controlled,
then
why
don't?
We
just
use
an
issue,
and
so
I
think
I'm
attracted
to
that
particular
idea,
because
either
way
you
need
a
requirement
object.
Somehow.
B
So
if
we
don't
use
an
issue-
and
we
just
have
a
first
class
citizen
requirements,
object,
and
that
seems
to
be
what
we're
doing
at
your
lab
nowadays,
we
are
like
never
discusses
an
object
or
every
single
thing,
then,
for
recording
this
management
it
has
to
it
has
to.
We
still
need
some
object,
because
we
can't
just
say
a
file
is
a
requirement,
because
you
do
need
a
little
bit
more.
You
need
things
like
now.
You're
gonna
have
the
title.
B
You
can
have
alt
text
stuff
in
the
file,
but
at
the
moment
you
need
to
say
link
requirements.
So
that's
traceability
is.
That
is
the
big
thing.
This
requirement
satisfies
this
requirement
and
Bistro
requirement
satisfy
that
requirement.
This
test
case
satisfies
this
requirement.
We
need
to
make
those
links,
and
you
can't
can
you
do
that?
Give
me
maybe
you
can,
but
it's
it's
a
weird,
it's
a
different
type
of
linking
right,
so
that
has
to
be
done
and
get
labs
somehow
outside
of
the
repo.
B
So
if
do
that,
and
we
want
to
have
be
able
to
like
classify
requirements
and
possibly
labeled,
and
why
don't
we
just
make
them
issues
so
then
sort
of
I
sort
of
thought
of
can
we
do
the
best
of
both
worlds?
Where
issued
description
is
the
source
controlled
piece,
but
the
wrapper
of
of
how
we
do
issue
relationships
and
all
those
things
those
would
serve
as
the
requirements,
traceability
piece
of
RM,
so
so
that
seems
attractive
to
me
as
a
as
a
framework
to
do
this.
B
And
so
that
I
mean
our
templates
are
raised,
it's
almost
silly
that
there's
that
non-parallel
yeah,
if
a
template
is
a
repo
manage,
then
why
isn't
the
actual
content
people
manage
yeah
I
think
that
would
be
interesting.
There
was
like
some
performance
concerns
and
stuff
like
that,
because
you
reading
to
disk
and
stuff
like
that,
yeah.
A
B
To
serve
specifically
say
requirements
management,
because
if
you
look
read
that
long
discussion
in
the
issue
I
linked
the
current
design,
is
you
just
show
the
diffs
in
the
in
the
system
feed
write
that
like
what
we
do
for
titles
right
now,
so
you
could
do
that
for
a
description
to
and
then
you
do
not
need
have.
It
need
to
be
repo
backed,
but
there
could
be
a
great
like
Google,
Docs
style
feature
where
you
want
to
see
the
entire
old
version.
B
B
I
wouldn't
think,
that's
a
feature
to
justify
using
kid,
because
that's
not
like
a
compelling
enough
feature,
but
if
you
have
requirements,
management
needing
I
get
back
issue
description,
then
that
opens
up
the
possibilities
of
these.
You
know
what
things
lower
priority
features
monogamous
compelling
one.
A
One
interesting
thing
you
could
do
is:
if
you,
if
the
the
get
fact
representation
Avenue,
she
doesn't
have
to
be
human
readable.
You
could
have
a
text
file
for
each
issue
and
actually
just
stored
its
adjacent
object
and
some
representation.
It's
all
interesting
I've
been
thinking
about
this,
because
I'm
building
a
command-line
tool
with
an
offline
issue
case
that
well,
apparently,
the
catch
actually
stores
snapshots
of
the
issue
and
it
stores
historic
snapshots.
A
So
the
idea
being
I'd
run
this
on
an
hourly
basis
and
get
hourly
snapshots
of
every
issue,
and
then
I
could
see
the
history
which,
but
then
I
think
the
interesting
thing
about
that
is
that
if
you
store
it
in
some
machine,
readable
representation,
it
would
open
up
the
opportunity
of
storing
a
lot
more
data
in
you
could
store
the
issue
relations.
They
can
just
assign
an.
B
A
So
I
think
that
the
challenge
would
be
coming
up
with
a
format
that
doesn't
change
too
quickly,
because
every
time
you
change
the
representation
you
actually
have
to
like
commit
the
change
to
every
single
object
to
update
the
format
because
and
I
think
the
other,
the
other
advantage
of
making
machine
readable.
Besides
people
like
me,
who
want
to
build
utilities
on
top
of
the
customers
themselves,
who
want
the
traceability
and
they
will
want
machines
to
be
reading
this,
like
they
want
audit
logs
to
be
machine,
readable
formats,
11-hundred
include
their
like
security
analysis
tools.
A
A
A
A
And
you
probably
get
pretty
efficient
dipping
in
the
objects
right
right,
the
compression
in
the
pack
files,
it's
interesting,
I,
oh
yeah,
I,
wonder
if,
if
the
the
main
reason
forget
is
like
that
traceability
I
wonder
if
it's
not
better
to
sort
of
find
some
first
class
objects
like
issues
and
epics
and
see
if
we
can
like
stick
it
behind
it
and
right.
B
A
A
There's
an
git
has
this
notes
feature,
that's
not
version
control
and
the
same
way.
Other
objects
are
cousin,
just
get
like
the
latest
version.
The
problem
is,
it
doesn't
have
a
good
conflict
resolution.
So
if
you
push
and
then
I
push
like,
we
can
just
overwrite
stuff,
I
think.
A
A
But
if
there
was
say
gitlab,
c
dot,
issues
or
dot
like
I,
don't
know,
maybe
issues
is
the
right
term,
but
and
it
included
all
that,
like
issues,
merge,
request
descriptions,
other
kinds
of
requirements
or
whatever
inside
that
repo
right.
Then
then
that
would
be
really
really
interesting
and
sort
of
start
opening
up
these
use
cases.
A
lot
of
people
are
very
interested
in
and
it
would
solve
your
versioning
history
right.
That's
ability,
yep,.
B
A
The
challenge,
probably,
is
med,
requests
work.
Well,
when
you
sort
of
looking
at
the
source
code
and
you're,
exposing
underlying
data
structure
like
the
engineers
and
the
people
that
work
with
get
when
you
expose
the
fact
that
it
is
good,
they
understand
that
there
is
branching
and
matrix
right
right,
I
think
the
challenge
comes
when
like
do
you
hide
some
of
that
UI?
Do
you
yeah?
B
Could
totally
use
that
in
the
issue
description,
and
that
would
be
your
that
would
be
your
change
control
and
you
throw
a
little
bit
of
permissions
on
top
of
it
and
you're
done
so.
That's,
oh,
no
I
believe
me
think
about
that
and
that
that
that
could
be
you
don't
even
have
to
worry
about.
Merge
requests
like
you
said,
because
there's
branches
and
all
that
silliness
going
on
yeah
I.
A
B
No
yeah
yeah,
like
I,
mean
just
one.
You
can
only
commit
to
one
yeah
thing
and
then
yeah,
then
you
have
to
reject
it
or
before
you
propose
a
new
one
or
something
like
that.
So
that
can
be
done.
That's
interesting
I
like
that,
because
that
definitely
simplifies
it
and
you
definitely
don't
need
branching
for
requirements
as
a
use
case
that
that's
like
a
silly.
B
A
B
B
In
the
marketplace
where
they
do
that
for
like
editing
and
publishing
where
it's
sort
of
get
in
the
behind
the
scenes
and
you
sort
of
see
a
little
bit
of
it,
but
if
you
think
about
it,
nobody
else
in
the
world
really
uses
git
I,
guess
people
publish
like
papers
and
like
scientific
things.
Sometimes
you
can
get.
A
B
Are
pretty
technical
people
to
write,
but
if
you
think
about
it
and
not
a
lot
of
people,
use
git
in
a
really
non
like
programming
way
and
if
we're
the
first
ones
to
pull
it
off,
they'll
be
pretty
because
that's
like
supposedly
are
like
are
like
our
goal.
What
mission
or
whatever
right
to
make
all
things
we
write
and
then,
if
our
name
is
get
lab,
it
would
make
sense
that
we
use
git
as
that
technology
and
not
reinvent
Google
Docs
versioning,
because
that's
what
we're
doing
right
now
with
titles
yeah.
So
it.
A
One
of
the
great
features
of
Google
Docs
and
a
lot
of
other
editors
is
like
live
editing
like
you're
editing
alive,
and
you
can
see
other
people
editing
live.
So
imagine
like
we're
having
a
meeting
and
we're
working
on
issue
or
working
on
requirements,
we're
both
working
on
it
in
real
time,
and
we
can
definitely
and
collaborate
like,
particularly
as
a
remote
company.
We
find
that
tremendously
useful
yep,
but
I
think,
as
you
have
more
and
more
business
people
work
on
the
documents
like
the
value
of
that,
it's
just
so
phenomenal.
A
A
B
Lose
some
of
the
great
like
if
you
look
at
the
issue
about
issue
description
tracking.
What
people
have
proposed
there,
which
I
think
makes
some
sense,
is
that
you
just
lose
granularity
right.
You
just
say
like
you,
you
put
a
time
period
and
say
you
just
capture
a
version,
every
X,
number
of
minutes
or
whatever
and
so
I
think
the
proposal
there
was
that,
like
we
were
talking
about
earlier,
like
this
data
would
still
be
saved
in
a
database.
B
A
A
Kind
so
I
guess
like.
Let
me
let
me
play
out
a
scenario
like
imagine:
we're
like
working
on
something
together
and
like
I'm
at
the
top
of
the
document
and
you're
at
the
bottom
of
document,
and
we
like
working
in
that
area
for
like
five
or
ten
minutes.
So
the
question
is
like
at
what
time
do
we
generate
a
commit
and
who
is
the
author
of
those
commits?
Oh
I,.
B
A
Moment
we
sort
of
then
move
into
the
center
of
the
document.
What
should
happen
is
the
the
back
end
should
say
I'm
going
to
create
commit
by
James
to
the
top
bit
at
the
bottom
bit
and
then
like
I'll,
just
wait
and
see
what
happens
and
like
maybe
I'll
have
like
a
commit.
That's
co-hosted
by
the
two
of
them.
That's
pretty
cool
like.
A
B
A
Enlike,
and
maybe
what
the
web
ID
does
is
there's
like
there's
a
new
pair
programming
thing
and
it
says,
based
on
your
pair
programming
snap,
a
session
we're
proposing
these
like
five
commits
that
would
be
amazing,
Wow,
yeah
I
bet
it
would
be
the
same
logic.
It
would
be
like
looking
at
like
relevant.
B
B
Is
there's
so
many
applications
that
to
me
that's
what
just
pops
out
in
the
last
five
minutes
throughout
your
lab,
like
there's
like
three
or
four
places
that
you
could
plug
that
into.
If
we
had.
B
B
B
A
B
A
B
A
A
A
But
yeah
we
have
I
think
then.
The
second
point
is
like:
besides
sending
that
backwards
and
forwards
and
having
a
local
editor,
the
server
needs
to
be
like
storing
that
analyzing
it
guaranteeing
that
it's
not
losing
it.
You
know
and
then
deciding
when
to
commit
it
and
then
once
it
commits
it,
it
can
drop
those
operations.
B
B
Think
that's
like
the
greatest
takeaway
for
me
by
far
that's
like
but
I'm
gonna,
yeah,
I'm,
I'm,
glad
I
had
sort
of
this
epiphany
last
night
and
I'm
soaking
a
little
bit
more
validation
this
morning,
which
is
good,
always
a
good
thing
and
I'm
gonna
move
forward
like
which
is
more
tangible
issues.
I,
don't
know
when
we're
gonna
work
on
this,
but
we
are
hiring
more
planned
product
managers
so
yeah.
If
we're,
if
we're
ramping
up
per
like
whatever
board
approved
plan,
then
I'm
excited
that
this
will
become
reality
sooner
rather
than
later.