►
From YouTube: Source Editor: multi-file support discussion
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
On
this
computer,
so
hello,
everyone
we
are
at
the
source,
header
multi-file,
support
discussion,
and
today
we
have
a
really
really
good
crowd
here.
So
I
will
I
will
start
with
the
very
first
thing.
So
I
I
saw
some
confusion
in
in
the
comments
that
Source
header
somehow
is
considered
to
be
the
single
file
editor
and
vice
versa.
So
these
two
things
are
used
interchangeably.
A
These
are
not
the
same.
These
are
definitely
not
the
same.
So
single
file
error
is
just
one
of
the
usages
for
for
the
source.
Editor
in
the
agenda
document.
I
have
added
other
usages,
and
it's
one
two
three
four
five
six
at
the
moment
and
no
seven
at
the
moment-
and
there
might
be
there
might
be
more
so
Source
editor
is
much
more
than
single
file.
Editor
and
single
file
later
is
much
more
than
just
Source
editor,
so
these
two
things
are
not
interchangeable.
B
Think
sure
I
think
it's
a
great
clarification
and
I
saw
also
that
you've
afterwards
listed
out
which
implementations
of
the
thoughts
at
a
time
in
different
areas.
We
already
have
just
posted
a
new
question,
because
what
I'm
very
curious
about
is
what
do
the
different
implementations
need
and
which
teams
determine
what
these
different
implementations
need.
A
Editor
functionality
like
we
do
not
extend
the
core
functionality
of
source
editor
because
Source
header
is
very
modular
and
that's
what
allows
it
to
be
used
in
groups
other
than
just
editor
right
so
see.
The
pipeline
editor
is
used
by
pipeline
authoring
group.
They
wrote
their
own
extension.
So
it's
all
about
extensions
when
it
comes
to
the
multiple
support.
That's
again
only
about
writing
an
extension
that
introduces
this
functionality,
so
it
either
installs
this
or
removes
or
doesn't
install
at
all.
A
If
it's
some
use
case
where
we
do
not
need
multi-file
support,
like
Snippets,
for
example,
Snippets
have
no
idea
about
the
repository,
so
there
is
no
no
need
to
include
the
multi-file
support
there,
and
also
for
the
in
particular
for
the
pipeline
editor.
It's
only
about
the
yaml
file
right,
so
probably
well.
Actually,
if
you're
building
really
complex
configurations,
we
have
for
gitlab,
where
our
CI
configurations
spread
over
like
hundreds
of
yaml
files.
A
That
might
be
interesting
as
well
to
to
actually
support
that
there,
because
you
do
want
to
check
what,
like
you,
read
the
configuration
and
you
want
to
check
what
is
going
on
in
the
other
file
that
this
configuration
references
so
with
that
I
I.
Just
don't
want
us
to
think
that
we
are
going
to
implement
something
that
is
going
to
be
spread
across
all
the
implementations.
No,
that's
not
about
Source
editor.
We
just
talk
about
an
extension
that
would
introduce
this
functionality
when
only
when
it's
needed
right.
A
B
It
can
have
different
attributes
and
team,
sees
it
differently
and
I
think
with
the
start
editor,
we
might
have
reached
a
similar
point
where
actually
other
teams
have
more
interest
in
the
foundation
of
the
source
editor.
Then
we
have
ourselves,
because
we
have
only
the
single
file
editor
currently
left
compared
to
previously,
but
also
Snippets
and
Legacy.
Web
IDE
were
based
on
it,
but
right
now
it
seems
like
we
are
holding
responsibility
over
something
that
could
be
just
a
pajamas
component,
kinda
and
I'm
curious.
Why?
A
I
I'm
sure
Eric
will
respond
to
this
I'll
just
bootstrap
this
conversation,
which
is
provocative
so
first
of
all,
we
do
not
delegate
this
because
there
are
still
things
that
we
did
not
Implement
in
the
source
editor
which
were
initially
planned
right.
We
still
didn't
finish.
The
toolbar
like
it's
still
behind
the
feature
flag,
and
the
problem
is
that
there
was
no
particular
interest
from
from
the
group
to
push
this
because
of
the
web
ID
effort.
A
So
now
I
hope
it's
I
will
will
get
focus
on
this
back.
But
why
not
to
push
this
to
foundations,
because
this
is
definitely
not
foundations
area.
This
is
the
editor.
This
is
the
core
editing
experience
and
we,
as
editor
team,
are
responsible
for
exactly
editing
experience
it
it
can
become.
It
can
be
a
component
in
pajamas.
It
can
be
anything,
but
we,
as
editor
team,
are
responsible
for
editing
experience
not
only
in
the
web
ID
but
across
the
whole
product.
A
C
I
mean
I
only
have
the
like
pragmatic
perspective,
which
is
when
Source
editor
was
created.
There
was
no
foundations
team
per
se
like
there
were
no
Engineers
on
foundations
and
that's
why
we
have
it
and
then
the
reason
it's
not
there
now
is
because
we
still
have
the
expertise
and
there
we
don't
want
to
overload
that
team
with
more
responsibility.
C
I
could
see
a
future
not
to
scare
you
Dennis,
but
where
it's
fully
mature,
where
we
have
it's
stable
we've
all
the
features
that
it's
ever
neat
gonna
need
and
like
it's
more
adopted
by
the
community,
like
people
could
use
it
outside
where
we've
talked
about
making
an
open
source
component
in
itself
and
have
community
members
build
extensions.
That
would
be
fantastic.
That's
our
like
fully
mature
Source
editor.
At
that
point.
It
is
it's
just
another
component
and
somebody
in
leadership
can
decide
who
gets
staffed
and
which
group
it
belongs
to.
C
B
For
discussions
like
the
single
file
versus
multiple
file,
editor
low
and
we
are
not
the
ones
in
control
over
the
experience.
That's
the
pipeline
editor
theme
and
that's
the
one
who
are
apparently
or
some
other
team
in
the
editor
team.
None
of
the
features
we
have
are
driving
the
need
for
the
multiple
file
implementation
as
far
as
I've
seen.
Yet
we
have
the
discussion
about.
Should
the
single
file
editor
become
a
multiple
file.
B
Editor
I
have
strong
opinions
about
their
decision,
but
currently
we
are
now
being
tested
to
make
ux
decisions
based
on
completely
different
contexts
that
we
are
not
experts
in
that
we
have
no
work
and
that
we
have
no
Partners
in
and
that's
usually
where
foundations
designers
like
they
have
the
right
tools.
They
have
the
right
processes
right
now,
we
are
being
tasked
to
look
after
the
ux
for
something
that
is
not
actually
in
our
area
and
I
fully
agree
with
you
that
it
would
be
amazing
if
the
entire
editor
experience
would
be
an
editor.
B
But
that's
just
not
the
case
when
you
look
at
the
features
that
you
use
the
editing
experience.
The
vast
majority
is
outside
of
editor
and
that's
the
major
problem.
When
we
look
at
the
ux,
because
now
suddenly
we
are
pushing
Julia
or
whoever
would
be
in
editor
into
completely
different
directions.
She's
supposed
to
be
a
foundations,
designer
who's,
looking
over
different
experience
from
different
teams,
but
also
even
more
development,
and
we
have
intentionally
pushed
it
away
from
pages
and
Wiki,
because
we
want
to
keep
the
focus
on
this.
B
So
if
we
now
open
up
us
ourselves
to
be
the
ux
gatekeeper
and
the
ux
driver
for
Source
editor,
that's
going
to
have
an
impact
on
how
much
work
and
how
much
Focus
can
keep.
We
can
keep
on
web
ID
and
remote
development,
and
that's
not
the
usual
processes
that
we
have
in
these
teams,
because
our
team
is
not
tasked
with
multiple
file
editing.
C
I
think
I
think
we
might
be
getting
ahead
of
ourselves
a
little
bit
and
I
want
to
clarify
that.
I.
Don't
think
that
we,
this
is
nothing
new
I
mean
all
of
these
experiences
have
already
adopted,
Source
editor
for
better
or
worse.
We
don't
actually
have
any
insight
into
how
a
pipeline
editor
or
the
pages
wizard
extend
or
don't
extend
the
source
editor,
and
we
don't
gate,
keep
their
experience,
although
they
do
sometimes
point
out
bugs
with
the
editor
that
or
or
functionality
that
they
need
that
we
can
put
on
our
backlog.
C
What
that
experience
looks
like
in
that
scope
without
inflating
it
with
like
the
pipeline
editor,
because
at
that
point,
if
we
build
the
extension
for
single
file
editor
to
become
a
multi-file
editor
and
they
say
oh
well,
that
would
be
helpful.
Then
we
can
say:
okay,
well,
here's
how
you
would
extend
it
or
here's
how
you
would
use
that
extension
in
your
context,
but
we're
not
pushing
that
to
anybody
else.
We're
not
solving
their
problems
prematurely
or
in
any
way.
B
C
C
Like
that,
we
need
to
decide
whether
the
single
file
editor
would
benefit
from
the
ability
to
open
and
edit
multiple
files
or
I
should
say.
Would
our
developers
benefit
and
non-developers
but
benefit
from
having
the
ability
to
open
up
multiple
files
without
opening
the
web,
IDE
and
I?
Think
that's
a
good
question
to
ask.
C
It
is
a
presumption
that
I
have
that
there
are
people
who
find
the
web
ID
intimidating.
We
we've
heard
that,
for
whatever
reason,
either
can't
or
don't
want
to
use
it
and
still
want
to
edit
multiple
files.
I
think
there's
data
that
we
can
start
looking
at
about
how
many
people
I
think
Michael
back
in
the
day
started.
Looking
at
that-
and
it
was
like
you
know-
85
of
the
Mrs
from
editors
per
view
or
one
file,
but
it
kind
of
ramped
up
pretty
quick
after
that.
So
we
can.
C
We
can
dig
more
into
the
data
there
about
who
we're
actually
targeting
what
they're
trying
to
do
I
think
as
the
web
IDE
settles
in
and
matures
we
can
figure
out
how
big
of
a
blocker.
It
really
is
by
looking
at
the
data
there
or
are
there
fewer
commits
being
made.
Is
the
balance
between
the
single
file
editor
and
the
web
ID
actually
going
in
the
opposite
direction
than
we
expected?
C
What
I
wouldn't
want
to
do
is
jump
right
into
implementation,
because
my
major
concern
about
the
user
experience
is
around
context,
which
is
the
single
file
editor
you're.
In
the
context
of
the
repository
you
have
the
edit
View
and
then
you
open
up
another
file.
I
mean
none
of
this
is,
is
unsolvable
I'm,
just
saying
we
need
to
think
through
what
that
experience
is
like
if
you
then
open
up
another
file
in
that
context,
are
they
presented
as
tabs?
C
C
Both
the
problem
and
exploring
the
details
of
the
solution
will
will
take
a
little
time
but
I
think
it's
worth
it's
worth
understanding
and
if,
if
nothing
else,
it's
worth
going
down
this
path
of
both
problem
and
solution,
validation
to
determine
yes
or
no
we're
going
to
do
this
so
that
we
can
have
a
stance
and
say
you
know
what
actually
we
found
out
that
this
complicates
the
user
flow
and
no
the
people
we
interviewed,
aren't
actually
more
successful
in
making
changes.
So
we're
not
going
to
do
it
and
here's
why?
C
But
until
we
have
that
data,
it's
just
kind
of
like
why
not
right
so
I'm
willing
to
I'm
open
to
being
proven
wrong.
I
do
think
that
there
is
a
purpose
for
a
lightweight
multi-file
editor
in
the
gitlab
UI,
but
I,
don't
know
what
shape
it
takes.
So
I
think
that's
what
that's
what
we
need
to
figure
out.
B
Yeah
I
would
also
love
to
understand
the
problems
that
people
who
can't
use
the
web
ID
better,
because
maybe
then
we
actually
understand
how
we
can
make
the
web
IDE
simpler
and
how
we
can
solve
the
problems,
but
the
web
ID.
Is
it
only
because
it's
a
misunderstanding
of
like
the
larger?
What
are
they
seeing
there?
Are
they
sold
out
of
the
engineering
background
that
they
don't
even
understand
the
general
purpose
of
all
of
this
or
are
they
having
different
problems?
B
There
are
hundreds
of
questions
we
could
explore
like
previously,
we
had
a
big
commit
button
everywhere
did
taking
that
one
away
lead
to
fewer
commits
and
these
people
creating
more
commits
in
the
single
file
editor.
Maybe
then
we
can
find
a
solution
for
that,
but
I
don't
think
we
have
understood
the
problem
yet
and
we
haven't
looked
at
which
ways
to
solve
it
and
a
modified
editor
is
one
option,
but
we
will
have
to
investigate
that,
in
my
opinion,
so
I'm
fully
with
it.
C
I
mean
I
think
that
what
we
have
heard
is
anecdotal
right.
We
haven't
done
a
formal
study
where
the
tasks
are
given,
but
we've
heard
both
internally
and
in
the
feedback
issue
that
there
is
a
major
barrier
to
something,
as
that's
presented
with
as
many
options
like
it's
it's
not
that
it
is
actually
harder
to
make
an
edit
in
the
new
web
ID
beta.
C
It
is
one
extra
click
to
go
over
to
the
source,
control
Tab
and
then
you
get
the
same
workflow,
but
things
are
much
more
they're
much
tinier
they're
cluttered
with
other
functionality
that
you
don't
need
every
day
again,
maybe
not
appropriate
for
public
video.
But
we've
heard
that
vs
code
struggles
with
this
their
team
struggles
with
this
as
well
and
anytime.
They
make
an
effort
to
simplify
they
get
pushback
from
developers.
C
C
Arguments
I
think
we
can
say
for
sure
that
we
understand
there's
a
problem
for
non-developers
who
feel
like
they
can't
use
the
web
ID,
even
though
with
a
little
training,
if
they,
if
they
were
to
work
on
it,
is
not
that
difficult.
There
is
a
barrier
that
they
choose
not
to
overcome
in.
In
most
cases,
I
think
the
single
file
editor
pairing
it
with
content.
C
Editor
will
solve
a
lot
of
the
markdown
like
workflows,
that
non-developers
will
will
interact
with,
and
so
I
think,
like
about
the
use
case
of
like
a
handbook
update
right.
So
you
have
maybe
three
pages
of
the
handbook
you're
trying
to
update
that.
Might
be
something
that
somebody
finds
intimidating
to
do
in
the
web
IDE,
even
though
it's
very
delightful
for
me,
some
other
people
might
not
enjoy
that
workflow.
C
C
A
Of
this
yeah
I
was
I
was
just
listing
the
the
the
use
cases
that
I
think
are
valid
use
cases
for
multiple
sport.
In
let's
say
we
limit
this
to
the
single
file
editor
and
there
are.
There
are
things
that
that
vs
code
just
simply
cannot
really
sold
like,
let's
assume
I
start
editing
a
file
in
single
file,
editor
and
then
I
realized
that
I
need
to
edit
another
file.
What
do
I
do?
A
I,
just
post
all
my
edits,
open
new
tab
with
vs
code
with
the
with
the
web
ID
and
try
to
replicate
the
same
changes
there
and
then
change
the
new
file.
This
is
by
far
not
the
optimal
solution,
especially
for
non-developers
the
the
the
handbook
edits
that
Eric
mentioned.
Those
are
a
good
good
example
of
of
the
need
for
multi-file
support
as
well,
but
I
think
I
think
we
can.
We
can
come
up
with
different
different
use
cases.
A
This
I'm
I'm-
to
be
honest,
I'm,
really
surprised
with
the
tension
concerning
this
this
question,
because
technically
nothing
really
really
prevents
us
from
making
this
and
then,
if
we
need
to.
If
we
want
to
say
that
this
design,
for
example,
is
going
beyond
our
group,
then
we
go
to
Foundation
to
help
with
the
design.
That's
that's
pretty
easy.
Still
in
the
engineering
implementation
will
be
on
us.
A
This
is
not
going
to
work
and
not
gonna
present
any
reliable
statistical
data.
Also,
when
we
talk
about
proper,
proper
testing,
anything
that
is
implemented
in
the
gitlab
UI
has
the
possibility
to
be
implemented
with
a
much
better
performance,
because
we
have
control
over
everything
comparing
to
go
into
completely
separate
thing.
That
is
web
ID,
and
this
is
again
sort
of
the
highlighting
of
The
Simple
Solution,
which
is
called
single
file.
A
Editor
now,
which
bring
like
which
comes
with
this
light,
lightweight
implementation,
which
can
be
very,
very
fast,
very
simple,
and
there
is
really
from
the
from
the
performance
side
point
of
view.
There
is
nothing
to
compare
here
in
my
opinion,
but
I
totally
understand
the
the
point
that
we
we
still
have
to
have
to
maintain
this.
If
we
start
this,
we
have
to
maintain
this,
and
that's
that's,
of
course.
True.
That's
that's
not
going
to
be
like.
A
We
start
this
and
somebody
else
picks
it
up
or
actually
we
did
this
with
Snippets
I.
Think,
but
that's
that's
another
story,
so
we
can
we
can.
We
can
take
as
much
as
we
want
or
as
little
as
we
want
from
this
effort,
and
we
can
go
as
far
as
we
want
with
this
effort,
because
it's
it's
very
modular,
it's
very
it's
possible
to
make
it
very
granular
to
the
point
where
we
can
get
reliable
statistical
data,
so
I.
In
my
opinion
there
is.
A
C
Yeah
I
think
for
for
me,
it's
not
so
much
about
thinking
about
why
not
it's
figuring
out
what
the
the
the
actual
use
cases
we
want
to
test
against
are
and
making
sure
that
the
implementation
that
we
put
in
place,
whether
it's
a
file
tree
or
I'm,
just
thinking
through
like
what,
if
you
know
you
open
it
up
and
there's
just
a
button
to
click
to
add
a
new
file
and
we
don't
bring
up
a
file
tree.
But
you
can
like
search
for
the
file
name
and
pull
it
up
in
the
content.
C
Like
that,
like
maybe
it's
more
intuitive
and
more
usable
to
not
show
a
file
tree,
I
think
that's
the
level
of
solution,
validation
that
we
need
to
get
into
in
the
context
of
the
web
editor,
which
we
should
probably
use
the
correct
term
so
that
we
don't
keep
talking
about
single
file
and
multi-file.
The
web
editor
is
something
where
what
I
would
want
to
test
and
the
only
reason
I
would
hesitate.
But
I
know
you
know,
there's
there's
other
potential
reasons,
but
the
only
reason
I
hesitate
in
rushing
right
into
implementation
is
I'm.
C
How
do
we
make
it
super
clear
that,
once
you
add
a
file
to
that
context,
you
add
three
or
four
more
files
like
you're
no
longer
in
the
edit
view
for
readme.markdown
right
you're
in
this
web
editor
and
right
now,
I
mean
I.
Just
think
it's
going
to
take
some
UI
and
ux
finesse
to
make
sure
that
context
feels
obvious
and
intentional,
but
I
think
there
are
a
few
different
solutions
to
a
few
different
problems.
C
B
From
the
X
side,
I
can
also
clarify
where
my
biggest
concerns
are
it's.
Currently,
we
have
a
couple
of
different
editing
options
and
we
try
to
position
them
at
the
most
extreme
use
cases
so
that
we
actually
have
clear
positioning
for
when
you
should
use
them.
If
we
now
introduce
another
option
like
a
multi-file
editor,
that's
sitting
somewhere
between
single
file
editor
and
the
web
ID
we're
going
to
need
to
be
extremely
clear
about
positioning.
Are
we
even
gonna
talk
about
that?
B
C
No,
this
would
just
be
the
the
web
editor
and
then,
in
the
context
of
the
editor,
you
could
like
add
a
file
to
your
edit
flow,
so
yeah,
just
we
we
should
have
at
the
very
most
to,
in
my
opinion,
at
the
very
most
to
editing
options.
I
think
I
still
think
that
it'd
be
great.
If
you
just
went
in
the
web
IDE
and
connected
to
the
remote
development
environment.
I
still
don't
know
if
that's
technically
impossible,
but
that's
not
the
scope
of
this
conversation.
A
That
I
think
I
think
I
think
the
the
the
the
the
there
was
no
discussion
to
introduce
another
option
like
there.
There
was
never
discussion
about
this
and
the
design
that
Julia
came
up
with.
It
clearly
indicates
the
button
in
the
single,
so
we
kind
of
have
the
web
editor.
We
have
the
button,
we
click
the
button,
we
get
the
side
panel
sliding
in
and
that's
that's,
how
we
sort
of
make
the
gradual
extension
of
the
of
the
experience
in
the
in
what
starts
a
single
file
later.
A
B
And
this
is
exactly
the
perfect
Next
Step,
because
when
we're
now
talking
about,
we
have
a
button
that
expands
a
file
tree
like
be
the
user
and
the
Persona
that
we're
talking
about
is
non-engineered.
They
are
exactly
the
users
who
are
not
working
around
our
UI
and
looking
at
like
what
are
the
new
features
that
we
have
and
like
using
all
of
the
extra
features.
B
They
are
the
ones
who
have
the
least
percentage
chance
to
come
across
that
button
when
they
need
it
and
expand
it
so
that
they
can
use
the
features,
and
so
this
is
what
my
big
concern
is.
We
are
making
the
UI
more
complex
for
the
user,
who
actually
needs
it,
the
least
complex
and
we
are
taking
it
for
everybody
by
adding
even
yet
more
buttons
into
it,
even
more
functionality
and
the
more
we
build
this
chrome
and
the
UI
around
it.
B
The
more
users
will
be
confused
about
like
what
can
I
do,
even
on
the
five
view.
Right
now,
when
I
click
the
button,
it
says
edit
file
and
I
land
in
an
edit
file
view
where
I
can
add
multiple
files
that
I
have
currently
not
seen
yet
and
then
in
the
file
tree.
I
also
have
to
navigate,
maybe
across
multiple
folders,
like
there's
a
ton
of
problems
that
these
kinds
of
users
that
are
non-engineers
have
with
our
editing
but
I,
don't
know
whether
moving
from
single
file
editing
to
multiple
file.
A
This
is
the
distribution.
The
situation
you
describe
is
a
perfect
confirmation
that
we
have
to
do
this
because
right
now,
users,
who
are
not
technical,
they
have
only
two
options:
either
stay
in
one
file
or
go
to
web
ID,
where
they
understand
nothing
right,
so
they
are
stuck.
They
do
not
have
options.
A
Bitcoin,
have
you
tried?
Have
you
tried
editing,
multiples
in
single
file
editor,
so
editing
one
file
making
commit
go
to
another
file
edit
make
commit
go
to
another
file
edit
make
commit.
So,
first
of
all,
your
your
project
administrators
will
hate
you
for
all
those
commits,
and
then
you
will
just
go
back
and
forth
back
and
forth
for
no
reason
really,
in
my
opinion,
that's
that's
my
opinion.
A
B
How
many
of
our
customers
do
have
multiple
markdown
files
in
their
handbook,
like
how
many
of
our
customers
have
their
handbooks
and
are
repositories
like?
Is
that
really
the
case
that
we
most
care
about,
and
is
that
a
realistic
case
that
we
care
about
so
much
that
we
make
the
UI
more
complex
and
add
more
functionality
that
everybody
will
have
to
understand
and
look
around
to
see
the
areas
that
they
care
about?.
A
B
If
users
have
trouble
using
the
web
ID
because
they
don't
understand
what
the
web
ID
is,
make
the
messaging
clearer
if
they
have
trouble
using
the
web
IDE,
because
they
don't
know
what
the
next
step
is.
Let's
Make,
a
very
clear
click
to
action.
That's
primary
like
we
don't
understand
the
problem,
but
we
are
talking
about
Solutions
and
that's
my
major
concern
here,
because
by
doing
this
we
can
actually
make
the
situation
worse
than
it
was
different.
A
C
Sorry,
what
I'm?
What
I'm
hearing
is
that?
Well
what
I'm
hearing
and
then
distilling
with
my
perspective
too,
we
know
there's
a
problem
because
people
voiced
it
when
we
moved
to
the
new
web
ID.
We
know
that
there's
a
problem
with
this
workflow
and
they
want
us
to
invest
in
workflows
that
make
it
easier
for
non-developers
to
contribute
to
gitlab.
So
we
need
to
distill
those
down
and
find
a
way
to
validate
them
with
research,
whether
that's
proofs
of
concept
or
prototypes
or
whatever.
C
We
can
figure
that
out
outside
the
context
of
this
meeting,
but
I
I'm
convinced
that
there
is
a
problem
we
can
explore
the
solutions
through
you
know
iteration
and
ex
and
solution
validation,
but
the
like
I
mentioned.
Maybe
the
answer
is
not
a
button
that
shows
the
file
tree,
but
a
button
that
allows
you
to
bring
up
another
file
in
some
context.
So
you
know
search
for
another
file
or
something
like
that.
We
don't
know.
C
What's
going
to
resonate,
we
need
to
identify
customers
who
are
having
these
problems
and
try
and
get
in
front
of
them
and
see
if
it's
solving
their
problems
better
than
the
web.
Ide
solves
it,
and,
if
not,
is
you
know?
What
is
what
are
they
responding
to
I?
Think,
that's
the
that's!
The
real
Next
Step,
defining
what
problems
we're
really
trying
to
solve
and
then
running
some
solution,
validation,
I!
Don't
think
that
there's
anything
unique
about
this
perspective,
I
think
it's
just
something.