►
From YouTube: YUI Open Roundtable 11/29/2012
Description
First YUI Open Roundtable.
B
E
Right
for
the
the
pre
pre
show
boxing
I
think
we're
ready
to
go
so
I
have
on
the
wiki
in
github
an
agenda
for
today
class.
This
is
I,
don't
think
we're
going
to
get
through
everything.
So
this
is
just
going
to
be
an
ongoing
agenda.
The
most
important
things
will
try
to
bubble
up
to
the
top
and
just
get
through
as
many
things
as
possible.
E
You
treat,
and
then
we
also
have
ad
hoc
hangouts
to
deal
with
specific
technical
topics
that
we
want
to
deep
dive
into,
for
instance,
code
reviews
or
design
reviews.
So
we'll
continue
to
have
those
four
dedicated
topics.
This
is
more
just
informal
forum
to
discuss.
You
know
smaller
topics
and
make
decisions
that
need
to
be
made.
Otherwise
would
just
continue
to
not
get
me.
We've
traditionally
also
use
this
time
to
review,
pull
requests
that
need
to
be
approved
or
commented
on,
and
just
talk
about
bugs.
That
may
be
a
sign,
but
are
important.
E
A
E
H
E
B
E
G
K
M
We're
making
it
a
default
for
now.
Okay.
So
if
you'd
know
from
the
Yui
conference,
I
was
working
on
the
skidder
demo
and
a
couple
of
the
issues
that
came
up
with
changing
colors
dynamically
for
skins.
What
was
the
slider,
because
the
slider
is
this
visualization
is
all
made
up
of
bitmaps,
so
that
doesn't
play
very
well
when
you're
changing
background
colors
colors
of
other
things.
So
I
worked
on
that
little
bit
and
took
the
the
Dom
nodes
and
remove
the
bitmaps
from
them
using
only
CSS
and
then
in
the
same
CSS.
M
I
modified
the
end
caps
and
the
rail
and
the
thumb
thumb
container
without
the
images
in
it
to
look
like
a
slider.
So
I
now
have
a
an
imageless
slider
that
still
uses
all
the
same
codes.
So
there's
no
changes
to
anything
except
CSS
to
get
this
slider
and
then
I
was
able
to
put
this
back
into
this
demo
of
Skinner
so
that
you
can
have
a
slider,
instantiating
and
maybe
being
played
with
hey.
M
E
M
N
A
M
M
That's
it
for
that,
and
the
other
thing
that
was
giving
us
a
bit
of
trouble
with
existing
CSS
were
the
fact
that
we
were
using
some
arrow
shapes
in
data
table
and
in
menu
for
the
indicators
that
there
was
an
additional
level
of
venue
fly
out
and
the
arrows
at
calendar.
So
I
just
did
some
work
on
creating
some
arrows
that
are
made
with
CSS.
Instead
of
images,
image
rights.
A
When
I
was,
I
tried
to
do
the
same
thing
I.
I
guess
my
CSS
foo
is
not
what
yours
is,
but
I
had
some
trouble
getting
cross-browser
compatibility
in
terms
of
the
display
of,
in
particular,
the
double
arrow
and
to
some
pixel.
Precision
on
the
placement
of
the
individual
areas
as
well,
but
especially
the
double
arrow
started
to
look
wonky
and
various
browsers,
but
it
could
just
be
that
your
CSS
is
stronger
than
mine,
I'll.
M
M
E
E
And
discuss
where
we
thought
we
were
with
this
particular
item
as
a
team
as
a
project,
we
wanted
to
be
able
to
establish
performance
baselines
for
critical
paths
in
the
system
and
also
some
important
leaf
nodes
like
charts,
for
instance,
so
I
don't
know
if
all
the
right
personnel
are
here
to
really
discuss
this
in
great
detail.
But
I
wanted
to
do
a
pulse
check
and
see
where
we
felt
like
we
were
the
where
we
left
it
was
what
we
were
going
to
be
checking
in
performance
tests
into
our
tests
directory.
H
H
E
K
E
H
H
And
yeah
well,
when
we
switch
it
over
by
the
end
of
the
year.
Getting
will
provide
that
for
the
bills
that
eternally
you
know
as
far
as
having
that
pushing
that
out
like
that's
something
that
we
do
also.
So
why
do
I
push
the
reports
to
my
baguette,
avec,
mom
I,
believe
we're
also
including
the
duration,
and
it
not
as
easy
to
add,
and
so
will
you
switched
yet.
Ii
will
also
have
that's
a
good
bill.
Maybe
what
we
can
do
is
is
show
charts
over
time
or
what
you
know.
H
E
H
C
Well,
what
could
be
interesting
is
I
mean
if
you
can
expose
this
historical
performance
result
data
via
some
kind
of
API
or
just
you
know,
parsable
JSON
or
something
you
could.
You
could
build
tooling
and
maybe
even
see
I
infrastructure
so
that
when
you
do
a
performance
run
either
developer
on
their
machine
or
on
the
CI
system.
It
can
then
hit
the
API
and
see
like
you
know
this
run
completed
in
X
number
of
seconds.
Historically,
the
average
has
been
X
number
of
seconds.
If
there's
a
huge
deviation,
then
maybe
something's
wrong.
You
could.
N
N
E
O
C
C
P
P
E
D
D
E
So
I
think
this
is
something
women
can
revisit,
try
to
get
more
hands
in
the
room
to
just
just
show
the
current
state
of
what
people
have
actually
built
and
then
take
it
from
there
and
then
that
will
give
us
a
good
opportunity
to
figure
out
the
common
documentation
that
we
need
to
write.
Allow
any
contributor
to
be
helping
us
write
more
performance,
benchmark
tests
right.
P
And
what
one
thing
I
kilo
about-
and
this
oh
and
maybe
an
even
intermediary,
said
before,
like
full
automation,
would
be
at
least
be
able
to
like
Amy
hey
is
anybody
could
write
this,
be
able
to
write
out
the
results
into
a
file
or
something
like
that,
so
that
you
wouldn't
have
to
like
actually
comp
a
copy
them
to
compare?
Oh.
E
E
E
J
E
Let
me
post
the
URL
challenge,
so
we
have
a
first
pass
up
there
on
the
wiki,
and
so
I
would
like
to
pretty
soon
here
come
to
a
close
on
this
and
stamp
it
as
a
first
version,
I'm,
not
really
sure
the
right
process,
you
didn't
get
that
so
I
think
what
I'd
like
to
do
is
to
go
over
it.
Just
some
final
discussion
and
then
put
it
out
for
objections
and
if
we
here
are
no
objections
and
we're
just
going
to
ratify
it
and
move
on
unless
there
are
objections
to
the
process.
E
E
E
Okay,
so
users
is
the
lowest
common
denominator.
Anyone
can
use
the
project,
and
that
makes
you
a
user
a
contributor.
It's
basically
someone
who
has
submitted
a
scientist
ela
and
by
extension
contributors
also
have
why
a
library
com
account
which
allows
you
to
file
bugs
and
post
on
the
forum.
There's
also
this
idea
of
a
mailing
list
and
that's
something
that
we've
been
kind
of
going
back
and
forth
about
the
mailing
list
is
going
to
need
a
central
place
to
have
discussions.
E
So
at
this
point,
we're
pretty
sure
to
give
the
google
group-
and
at
least
committers
and
reviewers
are
going
to
be
on
that
mailing
list.
It's
going
to
be,
for
instance,
gonna,
be
where
I
would
email
the
mailing
list
and
say
here's.
The
latest
version
of
this
contribute
contributor
model.
Are
there
any
objections?
If
there
are
no
objections,
I'm
going
to
ratify
it
and
then
that's
it.
E
If
you
beat
down
to
the
voting
model
nice
to
stop?
There's
this
notion
of
modi
will
just
muscle
in
our
mind
and
contributors
actually
don't
have
a
binding
vote.
They
just
have
a
voice,
and
so
is
that
going
to
be
too
much
noise
than
to
filter
out
who
is
a
contributor
versus
who
has
a
binding
vote
and
that's
the
real
concern
there
is
that
if
someone
on
the
mailing
list,
s
plus
1,
we
now
need
to
figure
out
a
way
to
figure
out
that
vote
it's
by
they
more
than
I.
E
So
to
make
things
simpler,
you
know
I'm,
proposing
that
we
just
start
at
least
have
the
mentalist
become
theirs
and
reviewers
only
and
may
be.
Contributors
can
read
the
mentalist,
but
not
post
to
it.
Until
we
have
a
sub
cooling
in
place
to
make
it
really
obvious
who's.
A
computer
versus
in
there
yeah
I
think.
C
I
really
like
the
idea
of
a
mailing
list,
but
I
think
I
would
lean
more
towards
an
open
mailing
list,
at
least
inviting
contributors
in
and
I.
Think
I
wouldn't
expect
it
to
get
too
noisy
because
I
doubt
we're
going
to
see
a
huge
number
of
people
become
committers,
at
least
not
for
a
while,
and
it
should
be
fairly
easy
to
to
say
you
know
if
it's,
if
it's
me
or
Luke
or
Dave
or
Eric,
or
somebody
like
that,
then
it's
a
binding
vote.
A
I
agree:
actually,
I
think
that
having
a
be
an
open
list
and
contributors
have
the
opportunity
to
or
just
have
it
be
opened
or
whoever
wants
to
subscribe
to
it,
and
if
they
want
to
subscribe
to
it,
they
can
participate
in
it
and
by
means
of
their
participation,
it
also
informs
the
team
who
are
the
active
contributors.
How
are
they
contributing
to
the
conversation
and
should
they
be
promoted
to
a
committer?
C
C
Really
I
mean
so
one
example
of
this
would
be
initially.
The
the
nodejs
project
only
had
a
single
mailing
list,
and
that
was
where
all
development
discussion
happened
and
sort
of
all.
You
know:
contributor,
discussion
and
even
user
discussions
and
then,
as
the
user
community
got
a
bigger
and
bigger
and
it
got
noisier
and
noisier
and
people
were
talking
more
about
just
simple
technical
questions.
C
Instead
of
development
issues,
they
broke
it
off
into
another
mailing
list
and
they
said
you
know
this
new
list
is,
for
you
know,
actual
development
discussions
about
core
and
you
can
keep
using
whatever
the
old
one
was,
for
you
know
your
your
tech
support
questions
and
that
actually
worked
wasn't
believable.
You.
P
C
A
C
E
C
C
H
E
P
E
E
Issues
only
pull
requests
that
kind
of
serve
their
company
or
their
projects
needs
without
taking
into
account
the
benefit
of
co
change
for
the
platform
as
a
whole,
or
you
know,
making
design
decisions
that
are
again
just
kind
of
one
track
minded
rather
than
to
the
benefit
of
the
whole
community.
That
would
you
know
that's
something
that
might
limit
your
contributor
sure.
E
So
we
want
people
who
really
understand
the
8k,
we're
ready
for
you
to
our
community
and
provide
coach
ages
that
benefit
the
entire
community
as
a
platform
you
can
so
there's
a
nomination
and
I
voting
process
and
reviewers
rain
commuters
on
board
see
he.
I
don't
know
if
this
is
called
out
here,
but
the
fact
that
your
committee
are
basically
means
that
you
have
write
access
to
our
repo
on
github.
So
that's
probably
something
I
should
sell
out
here.
E
E
Of
everyone
in
the
community
to
kind
of
have
that
oversight,
but
when
push
comes
to
shove,
a
kind
of
looking
at
the
buck
stops
at
the
reviewer
level.
The
other
part
cabbage
that
reviewers
are
not
subject
to
this
type
of
heat
thing
and
the
sense
that
they
are
kind
of
trusted
to
be
able
to
make
a
changes
that
are
not
a
drastic
effects.
So.
G
E
And
then,
when
there's
a
problem
with
achieving
consensus,
then
the
reviewers
group
will
resolve
any
conflicts
and
make
a
final
decision,
and
the
idea
here
is
to
not
get
bottlenecked
by
a
lack
of
decision-making.
So
ultimately,
it's
up
to
reviewers
to
make
sure
that
all
decisions
can
be
made
and
the
project
for
the
bomb
and
there's
a
private
mailing
list
for
reviewers
that
that
you
can
talk
about
bowing
and
legal
matters
and
other
than
that
everything
that's
technical
in
nature
needs
to
be
on
that
open
mailing
list.
E
There
are
some
detail
around
how
you
can
qualify
to
be
a
committer
or
a
reviewer,
so
I
do
encourage
argument
to
take
a
moment.
Read
it
to
yourself
and
figure
out.
If
you
have
any
feedback
in
those
areas,
we
do
acknowledge
that
it's
kind
of
arbitrary,
so
we
just
kind
of
put
a
line
in
the
sand
thing:
okay,
we'll
just
call
it
50
and
see
how
it
goes
if
it's
not
working
out
and
can
certainly
modify
that
that
baseline.
E
This
is
just
a
caveat
to
say
that
support
is
voluntary
and
not
guaranteed,
and
then
there
are
multiple
channels
of
getting
support,
mainly
from
in
a
forum
for
IRC.
So
then,
why
did
we
get
to
talking
about
code?
There
are
our
contribution
standards
which
will
review
after
this
document
that
all
contributions,
one
of
me
and
we
want
to
qualify.
E
It
be
pretty
specific
about
the
bar
of
excellence
that
we
want
to
have,
as
it
comes
in
code
and
authentication
and
tested
everything,
so
that
it's
not
a
guessing
game
and
that
everyone,
whether
we
work
for
Yahoo,
whether
you're
on
the
Yui
for
committee
or
not,
whether
you're
a
user
or
sign
a
computer
or
a
reviewer,
everyone's
gonna,
think
I
see
rules.
Because
it's
because
I
could
do
it
and.
E
So
now
we
get
into
some
detail
about
voting
and
what
gets
voted
on
that
good
stuff,
I'll
review
at
a
high
level.
So
please
take
some
time
to
dive
a
little
deeper
and
provide
a
feedback
in
general
technical
decisions.
We
want
to
ratify
for
lazy
consensus
and
that
basically
means
there's
a
healthy
discussion
and
then
it
goes
to
the
boat.
If
no
one
objects,
then
the
thing
is
a
fruit
and
that's
true
on
the
mailing
list
and
that's
also
true
in
github
pull
requests.
So
a
pull
request
is
just.
E
A
change,
it's
actually
good
preferred
way
of
requesting
a
change
to
the
library
so
I,
maybe
I
should
yeah
there
we
go.
They
can
issue
a
horrible
sin,
github
or
post
the
mailing
list,
and
so,
let's
take
a
pull
request.
If
you
want
to
change
some
code
in
the
library,
you
change
it
in
your
for
your
issue,
a
pull
request
and
as
long
as
no
one
objects
within
72
hours,
that
thing
can
get
merged
in,
and
so
that's
true
for
committers
and
reviewers,
because
they
have
write
access.
L
E
To
allow
people
you
know
all
over
the
world,
whether
you're
in
a
different
time
zone
or
whatever,
to
have
enough
time
to
do
that
with
you
and
I
do
mention
that
you
know
reviewers
are
the
ultimate
gatekeepers
in
this
process
of
minus
letting
or
having
an
objection.
If
they
don't,
they
don't
make
some
coaches
the
version,
but
it
really
is
up
to
the
entire
community
to
be
looking
at
more
questions
provided
to
be
back.
So
we
hope
that
that's
really
hot
as
ever
right
now
is.
F
E
L
C
E
E
J
E
F
One
thing
that
I
was
just
thinking
about
that
would
be
really
neat
is
like
we
have
the
Eric,
provided
the
chrome
plugin
for
the
those
who
have
signed
the
CLA
that
has
the
drop
down.
If
there
was
something
like
that
for
the
library
status
and
actually,
if
we
know
of
known
issues
for
CDN
problems
or
something
like
that,
did
I
not.
G
Working
on
this
next
quarter
was
like
an
app
that
would
allow
me
to
see
like
the
status.
It
builds
no
trees
hoping
to
closed.
You
know
this
could
also
be
a
Chrome
extension
as
well.
Were
you
just
basically
current
status
of
things,
so
it
might
be
something
that
began
that
tree
is
open.
Trees
close
as
I've
done.
C
A
A
J
N
E
E
Yeah,
that's
what
I
said
so
now.
Not
all
technical
decisions
can
be
and
using
consensus.
So
there
are
larger
issues.
It's
not
really
easy
to
codify
exactly
what
gets
you
voted
on
formally
addressed,
lacy
consensus,
but
larger
things
like
you
know,
refactoring
or
introduction
of
new
modules,
bigger
decisions,
I
think
we'll
flip
it
into
this
territory
and
the
more.
E
That
line
is
I.
Think
too.
So
when
we
vote
it's
going
to
be
on
the
mailing
list,
or
it
could
also
be
in
a
whole
class
but
usually
didn't
get
much
bigger
changes,
so
probably
not
pull
request
and
then
there's
this
idea
of
the
binding
versus
non
binding
and
a
non-binding
is
anyone?
That's
a
user
or
a
contributor,
a
binding,
motifs,
knitters
and
reviewers,
and
then
so
that's
this
is
this
section
talks
about
the
process
by
which
to
vote,
and
then
this
section
talks
about
these
are
the
different
types
of
votes.
E
So
there
are
boats
where,
as
long
as
you
have
more
Plus
Ones
than
minus
ones,
it's
okay-
or
this
request
three
plus
ones,
with
no
objections
in
order
to
be
ratified,
etc.
And
then
this
is
the
part
that
is
kind
of
the
first
pass
or
line
in
the
sand
and
I'm
sure
will
evolve
over
time.
So
when
do
we
need
about
documentation
or
adding
tasks
so
visit
our
non
code
changes
to
the
repo
and
that's
no
vote
is
ever
required.
E
If
you
wanna
take
a
dancer,
it's
a
typo
or
add
a
test
by
all
means:
I'm
gonna,
slaughter
juice.
Then,
when
you
have
a
code
change,
we
do
want
to
follow
the
lazy
consensus
role
when,
as
long
as
there
are
no
objections
with
its
own,
it
to
RSS
can
be
merchant.
Oh
and
the
other
thing
that's
up
there,
that
I
didn't
cover.
E
If
a
reviewer
wants
to
merge
code
in
it
does
it
did
say
that
reviewers
don't
need
to
be
reviewed,
so
they're
trusted
to
to
be
always
ripping
coded
without
the
72
are
waiting
period,
and
so,
by
extension,
if
there's
a
pull,
request
and
reviewer
says
hey,
this
looks
good
to
go,
no
need
to
wait
the
72
hours,
then
back
code
can
also
be
merged
in
right
away.
If
not,
we
do
want
to
leave
that
72-hour
window
open
so
that
anyone
in
the
community
has
a
chance
to
make
an
objection.
E
So
I
believe
it's
the
role
of
ever
in
a
community
to
to
make
sure
that
everyone
else's.
You
know
abiding
by
what
we
have
defined
here.
So
if,
if
something
gets
ripped
into
early,
then
anyone
can
objectives
in
Vegas
conversion
too
early.
But
then
it
is
up
to
reviewers
and
vote
on
action
if
never
needs
dr.
Ritter
shouldn't
vote
and
that's
really
the
only
action
that
can
be
taken
under.
L
E
Absolutely
so
that's
yeah,
that's
the
bottom
of
this
table.
So
so
there's
the
co
changed,
lazy
consensus,
a
bigger
architectural
change,
we're
singing
two-third
majority
of
reviewers
can
Brad
find
that
changes
so
that
through
a
formal
vote
in
the
mailing
list
or
I
guess,
a
pull
request
is
also
possible,
although
unlikely
and
then
so.
Those
are
the
only
two
types
of
co
changes,
we're
going
to
identify
it
normal
changes
and
then
it
changes
and
then
we've
got
new
computers
such
as
approval
by
reviewers.
J
E
E
E
E
A
G
C
A
Bots
see
I,
think
yeah
I
noticed
this
concern
in
IRC
is
will
about
the
bots
I
I
would
be
less
concerned
about
the
bots,
because
the
box,
the
bots
that
we
were
talking
about
specifically,
were
to
notify
poor
people
that
issue
a
pull
request,
that
their
pull
request
is
falling
inside
of
a
code
freeze
and
because
it's
falling
inside
of
a
code
freeze.
That
means
that
yet
it
isn't
applicable
for
the
72-hour
lazy
commit
well,
but
otherwise
it
the
bot
should
be
doing
nothing.
A
I
mean
it's
mainly
just
to
inform
you
that
you've
fallen
in
this
window
and
then
so,
if
the
the
notion
of
a
bot
to
do
a
lot
of
a
lot
of
a
lot
of
other
things,
a
lot
more,
we
start
adding
more
and
more
butts
than
I
can
see.
I
can
see
that
concern,
but
I
think
as
a
starting
point.
It's
this
using
a,
but
for
that
function
is
a
really
good
way
to
expose
that
information
that
might
not
be
as
accessible.
Otherwise
it
puts
it
right
there
in
your
face.
If
you
issue.
E
A
E
E
E
E
You
know
we
want
everyone
to
be
on
the
same
page
before
we
are
today
and
then,
when
you're
writing
the
new
component,
we
need
to
provide
a
well-written
user
guide
and
my
well
written
I
need
in
content.
So
we
have
any
services
at
your
disposal.
So
as
long
as
the
content
is
all
there,
we
can
serve
with
clean
up
any
grammar,
or
you
know
hello
of
ideas
and
things
like
that,
and
then
we
have
automated
our
functional
examples
to
serve.
I
C
And
then
one
other
separate
comment
on
that
on
the
user
guides
and
examples
I
think
that
makes
perfect
sense
before
pulling
something
another
library,
I
think
it
should
have
user
guides
and
examples,
but
I
think
for
the
review
process.
It
can
be
useful
to
for
somebody
to
maybe
create
a
pull
request
for
a
component
to
get
the
code
reviewed
and
maybe
get
a
tentative
like
once
you
write
a
user
guide
in
examples.
We
would
like
to
pull
this
into
the
library
before
spending
all
that
time
on.
These
are
guiding
examples.
Oh.
E
So
I
mean
there's
a
whole
process
like
if
you
aren't
going
to
be
contributing
a
new
component,
then
there's
a
whole
process.
I
think
that
you
should
follow
that
I
guess
could
be
better
better
outline
Peter,
where
you
start
with
an
API
review,
and
then
you
move
on
to
a
design
review,
and
then
you
do
a
further
ado
and
they're.
C
So
it's
like
one
case
where
this
happened
was
a
template
down
micro
right,
so
I
had
already
written
that.
So
then
I,
you
know:
I
I
wanted
to
go
through
the
review
process
to
get
the
feedback
from
the
team,
and
so
that
was
very
valuable
from
the
code
perspective
before
I
had
written
any
documentation
and
then
the
assumption
was,
if
the
team
likes
this
and
decides
that
it
should
get
pulled
in
then
I
would
write
documentation.
C
Think
I
don't
know
if
there's
a
way
to
call
that
out
in
the
document
as
I
don't
know
to
somehow
codify,
but
this
is
something
you
can
do.
If
you
want
to
get
code
feedback
before
you
spend
all
this
time
on
documentation
you,
maybe
you
can
go
ahead
and
file
a
pull
request,
get
the
feedback.
And
then,
if
consensus
on
the
pull
request
is
good,
then
add
the
docs
to
the
pull
request
and
then
it'll
get
pulled
in
you.
F
If
you
go
ahead
and
write
the
component
right,
all
the
documentation
and
unit
tests
and
all
that
and
then
there's
changes,
then
that's
just
on
you,
then
you
didn't
start
to
slip
one
or
like
you
took
it
upon
yourself
to
start
at
a
certain
phase
like
if
Ryan
had
already
had
documentation
up
and
then
there
were
changes
to
be
made
to
it.
Then
he
would
know
that
he
would
have
to
go
back
and
change
the
documentation.
F
E
G
Think
one
thing
is
to
realize
that
a
fork
West
isn't
it's
not
like
it's
going
to
happen
to
two
hours
there.
You
may
want
to
pull
request
and
sort
the
process
rolling.
So
it
is
it's
not
like
an
assumption
of
where
work
was
like
the
end
of
the
process.
It
could
be
that
isn't
where
you're
saying
I
mean
yeah.
G
E
F
I
think
I
think
I'm
the
way
that
the
proposal
process
is
set
up
right
now,
where
there's
an
open
communication,
if
that's
something
that
can
go
in
as
a
pull
request,
even
if
it's
like
a
markdown
file
somewhere
I'm,
not
really
sure.
Where
would
how
that,
where
that
would
live
to,
have
it
as
a
pull
request
against
the
against
the
the
whole
project?
F
C
A
J
C
E
C
E
G
B
C
E
And
then
I
do
want
to
stress
proper
connect
logs.
We
are
going
to
get
so.
You
know
there's
some
some
tactical
things,
but
we
want
to
reference
bugs
properly
went
on
fixing
bugs
and
we
want
to
attribute
contributions
when
it's
full
request,
so
we're
going
to
have
to
document
the
proper
ways
of
getting
that
into
the
glove.
C
E
C
E
C
K
C
E
E
So
you
know,
Davis
put
a
lot
of
effort
into
making
the
contribution
process
a
lot
easier
and
I
mean
this
is
so.
These
are
all
tools
that
help
everyone
sitting
at
this
table
life
easier
and
also
everyone
and
then
hang
out
too
so
I
think
that's
a
really
good
thing.
I
would
love
a
little
more
beefing
up
of
the
definition
around
how
to
really
use
these
tools
like.
Q
E
G
L
C
C
G
So
you
need
to
be
anything
that
comes
about
from
the
elevator.
He
elevates
on
the
gallery
like
if
something
is
wholly
being
moved
out
for
the
gallery
door
back
end.
That's
just
something
that
reviewers
decide
like
what
puts
the
1
million
minus
core
versus
gallery.
That's
imposition.
The
question
is
like
so
someone's
checking
in
phones
worked
on
something
on
the
gallery
for
a
long
time
in
their
ad
to
edit
core.
G
E
A
E
All
right
and
then
we
have
a
couple
different
pages
on
the
website
that
will
be
superseded
by
this,
but
this
is
all
about
the
fact
that
github
com
has
our
source
of
truth,
repo,
how
to
point
to
it
and
how
to
manage
the
different
branches
that
we
use.
So
we
are
adopting
a
pre-commit
model
where
the
dev
gosh
x
branches
are
where
coach
Eckels
go
into
and
then
once
a
code
passes
through
CI
after
successful
build,
then
the
code
change
can
then
be
merged
into
the
master
or
30
x
branch.
E
C
C
C
C
C
F
C
And
releasable
and
yeah,
if
you
were
to
change
the
default
branch
so
that
pull
requests
went
to
death
master,
then
that
would
always
that
would
also
mean
that
the
first
thing
people
see
when
they
go
to
github.com
/
yui
such
Yui
3,
is
dev
master
instead
of
master.
So
then
they
end
up
potentially,
depending
on
you
know,
development
code
instead
of
the
stable
stuff,
which
is
the
opposite
of
what
you
want.
People.
E
C
E
C
Changing
the
default
branch
wouldn't
actually
solve
the
problem.
It
would
just
I
mean
changing
the
default
branch
to
death.
Master
would
be
just
like
saying,
you
know,
instead
of
rolling
releases
off
master,
let's
roll
release
stuff
a
different
branch
you're,
just
you're,
making
that
change
via
a
different
process
also.
L
G
C
C
J
E
Believe
their
technical
complexities
that
make
that
expensive,
so
I'll
have
to
wait
until
date
gets
back
to
walk
us
through
those
countries,
de
let's
hold
off
on
that
change
for
now,
but
to
go
back
to
one's
question,
let
me
just
clarify
for
everyone:
the
difference
between
master
and
food
items,
so
we
have
adopted
a
hybrid
for
semantic
versioning
scheme.
For
from
what
my
like
me,
and
in
that
we
have
three
release
numbers.
E
Fourth,
there
are
major
architectural
changes
that
break
proper
compatibility
for
every
component
in
the
system.
We've
also
left
room
for
emergency
hotfix
releases,
and
in
that
case
we
would
introduce
a
fourth
number,
so
we
go
373
dash
1.
I'm
sorry
actually
goes
3,
so
3
plus
1,
which
would
indicate
that
we
are.
E
E
So,
given
that
model,
the
master
branch
indicates
all
code
changes
that
are
appropriate
for
a
bug-fix
release
of
going
from
3732
374
any
code
change
that
would
fit
under
that
is
going
to
master,
and
that
makes
master
always
releasable.
So
we
can
at
any
point
cut
at
374
and
feel
fairly
confident
in
the
in
the
regression
rest.
All
development
happening
on
a
free
dot.
X
branch
indicates
the
next
major
release,
which
would
be
with
the
38
release,
is.
J
E
We're
having
working
on
so
that's
bigger
functionality,
changes
new
api's
that
are
being
confused
and
API
breakages.
So
it's
just
an
indicator
meeting
that
when
you
go
from
373
2374,
you
can
feel
fairly
confident
in
that
upgrade
and
then
372
38
you're
going
to
get
some
new
features,
but
there
is
slightly
more
other
regression
risk.
So
you
know:
do
the
appropriate
testing
of
your
app.
E
E
So
any
questions
around
so
that's
are
branching
strategy,
master,
vs,
3,
X
and
then
the
dev
dash
indicates
all
code
that
can
go
in
in
before
CI
and
then
after
see,
I
that
cold
lands
in
the
branch
without
the
Deaf
dash.
So
yeah
I
think
that
it
could
be
named
better.
If
we
can
clear
some
of
the
technical
hurdles
that
we
feel
are
blockiness,
then
we
might
go
ahead
and
rename
to
be
a
little
bit
more
intuitive.
E
We
have
pretty
specific
guidelines
and
how
so
you
get
environment
and
then
here's
the
overall
workflow
that
I
think
you
know
as
intervention.
The
screencast
would
be
a
good
addition
to
this
content,
so
we
always
want
to
see
feature
branches
from
our
contributors
and
that
really
allows
for
I
silly
overviews
through
the
floor
requests.
So.
L
E
You're
not
working
in
a
branch,
then
your
forward
press
is
going
to
be
really
unreasonable,
work
with.
Then
we
have
our
contribution
standards
that
we
want
you
to
follow
after
you
commit
your
changes,
push
them
to
your
fork
on
github
and
then
issue
the
pull
request.
So
here
we
can
do
a
lot
better
and
explaining
the
three
different
branches.
Oh
well,
I've
got
Speicher
didn't
like
her
a
bit.
That
is
a
definite
issue,
only
changes
that
we
can
push
to
the
website
very
easily
without
any
friction
at
all.
So
we
encourage
any
trip.
E
E
Okay,
so
then
happy
to
be
a
pull
request.
That's
where
we
want
to
see
that
community
feedback
happening
and
have
discussions
and
objections,
and
all
that,
then
you
can
incorporate
whatever
feedback
you
got,
get
it
up
to
where
you
have
no
objections
and
then,
when
you,
when
you're
working
on
a
feature
branch
and
you
have
issued
a
photo
quest
and
you
incorporate
recode
into
that
branch,
the
four
requests
can
automatically
update,
which
is
a
really
great
feature
of
github.
So.
E
E
E
E
E
Forum
for
general
discussions
that
are
not
on
for
requests,
alright,
so,
okay,
three
two
one
I
have
a
couple
like
technical
discussions
that
are
not
processor
community
related
than
I'd
like
to
move
on
to
before
we
move
on.
Does
anyone
have
any
press
box
on
the
stuff
we
were
talking
about
so
far
alrighty?
L
A
C
E
So
in
general,
I
have
a
bucket
of
bugs
like
this.
That
I
feel
are
relatively
contained,
improvements
to
the
codebase
that
aren't
really
actively
being
worked
on
by
anyone.
So
I
would
like
to
use
this
forum,
and
maybe
the
nailing
list,
to
throw
them
out
there
to
the
community
for
discussion
using
the
tools
that
we
have
today.
E
C
Thing
you
could
do
is
just
have
a
page
on
the
wiki
that
has
you
know.
This
is
a
looks
like
a
small
issue
that
somebody
just
needs
to
investigate
and
figure
out.
It's
been
around
for
a
while
and
just
have
a
list
of
links
to
things
that
if
people
are
looking
for
a
project
to
learn
more
about
developing
for
Yui
or
or
just
born,
100.
E
Okay,
so
I,
don't
I,
don't
I,
don't
know,
there's
anything
worth
discussing
at
this
meeting
without
you
know
having
people
actually
do
some
background
on,
but
I
did
wanted
to
introduce
the
idea
that
I
do
have
a
number
of
folks
that
fit
into
that
category.
So
let
me
get
that
set
up
and
get
that
report
set
up
and
then
we
can
have.
We
can
evangelize
the
lips
say:
hey
here's,
a
list
of
constant
bugs
if
anyone's
interested
in
picking
something
up
sure
what
clued
it
is
almost
like.
E
And
I
do
think
this
is
a
good
form
if
you
are
in
the
community
and
you're.
Looking
at
this
and
you're
like
oh,
let
me
take
a
look
and
then
you
take
a
look
in
your
life.
I,
like
you,
spend
much
warmer
bring
it
up
in
the
mailing
list,
write
a
pull
request
or
in
this
one
and
gets
a
discussion
going
and
see
what
people
think
about
your
different.
Maybe.
M
E
G
E
C
That's
you're
gonna
invite
a
world
of
pain
there.
I
think
it's
a
it's
a
worthy
goal:
to
try
and
have
you
know
as
few
lint
failures
as
possible,
but
they're
they're
always
going
to
be
edge
cases
where
you
need
to
do
something
in
the
library
that's
going
to
cause
Lynn
feel
like
like
I
know
in
Yui
core,
actually,
just
the
other
day,
I
noticed
there's
a
bit
of
place
now,
where
we're
doing
a
function,
constructor
call
which
results
in
a
valid
code,
and
that
would
be
a
limb
failure
are.
E
L
F
O
O
C
C
P
The
technology
turn
it
out,
but
they
have
a
lot
of
places.
Basically,
I'm
doing
string
comparisons
that
are
done
string
comparison
to
double
equal
is
actually
better
than
triple
equal
in
this
case,
because
there
is
the
obstacle
cash
where
a
string
object
would
cause
a
fail
and
that
I
don't
want
that.
I
mean
text
technically
the
account
that
it's
such
an
edge
case.
But
if
you're
going
to
be,
you
know
granular
about
it,
you
miss
will
be
right
in
yep.
P
P
L
N
C
I
think
I
mean
just
just
speaking
philosophically
I
think
there's
more
value
in
knowing
say,
there's
a
file
where
you're
doing
one
thing
that
the
linter
complains
about,
but
you
know
that
you're
doing
it
for
a
reason.
You
put
a
comment
there
that
says
this
is
why
I'm
doing
this
and
you
see
that
lint
output,
you
see
that
lint
morning
whenever
you
build,
but
that's
fine
as
long
as
it
doesn't
feel
the
bill
that
lint
wearing.
As
a
reminder,
I'm
doing
this
non-standard
thing,
and
I
need
to
remember
that
this.
P
P
C
P
I
mean
that's,
that's
my
idea.
I
can
definitely
look
into
that
because
personally
I
want
to
get
rid
of
all
the
crop
because
it
makes
it
harder
to
if
you've
got
like
just
the
terminal
full
of
a
warnings
and
you
you
know
there
may
be
something
in
there
that
you
didn't
see
when
you
scanned
that
you
accidentally
look
into
so
you
just
want
to
be
able
to.
P
G
E
E
E
It's
gonna
make
things
easier
as
we
open
up
the
gallery
to
have
an
automated
process
that
does
the
lint
and
have
you
get
a
badge
if
you
have
no
lint
errors,
if
we
can
have
a
tool
that
is
reasonable
enough
just
to
set
the
standard
and
use
that
tool,
then
that's
just
going
to
make
whole
process
a
lot
easier.
I
think.
G
P
P
R
P
G
F
E
F
So
the
the
idea
behind
this
is
that
there's
a
lot
of
talk
in
the
community
about
having
the
the
calendar
as
a
pop-up
module
or
having
pop-up
abilities
to
it.
But
calendar
isn't
the
only
widget
that
could
they
could
benefit
from
having
something
like
this.
So
the
idea
is
to
have
a
generic
or
an
abstracted
module
that
provides
any
widget
with
a
pop-up
modal
ability
and
so
that
the
wiki
page
that's
created
its
link.
F
There
is
generally
just
a
like
a
brain
dump
from
hatch
and
I
earlier
today,
like
three
options:
the
three
conceivable
options
where
it's
it's
an
object
that
you
specify
which
widget
you
want
to
be
rendered
inside
of
the
pop-up
another
one
is
a
plug-in
onto
the
widget
that
adds
that
functionality
and
then
the
other.
The
third
option
was
a
mix
in
we're
just
including
it
or
using.
F
It
would
be
the
what
actually
augment
widget
to
allow
pop
up
functionality,
where
you
would
just
pass
that
into
the
configuration
so
just
basically
trying
to
brainstorm
how
it
should
be
architected.
So
anybody
who
has
any
thoughts
on
that
please
feel
free
to
make
comments
or
edit
the
page
jump
in
the
IRC
and
talk
to
us.
F
But
what
the
thing
that
I'm
wanting
to
solve
is
the
ability
to
have
a
pop-up
calendar,
popup
color
picker,
whenever
there's
a
color
picker
picker
widget
available,
whether
it's
in
the
gallery
or
the
core,
a
volume
slider
or
if
it's
hidden
behind
a
volume
button
and
anything
like
that
that
you,
you
would
click
on
a
button
to
show
another
widget
in
a
pop-up
type.
Setting.
L
Not
you
I,
don't
know
if
it's
a
universal
solution,
I
think
the
conversation
here
is
for
to
get
reversal
solution,
so
I
think
hatch,
specifically
use
T,
whoa,
slow
down
tools
and
extensions
to
create
the
counter
that
is
currently
in
the
gallery
and
I.
Think
that
a
lot
of
the
solutions
that
Tilo
built
are
useful
for
this
purpose.
I.
E
L
F
The
the
current
one
that
hatch
has
gallery
sorry,
the
current
one
that
hatch
has
in
the
gallery,
actually
extends
calendar
and
mixes
in
the
the
modality
features
right,
and
so
this
would
be
something
that
would
do
something
very
similar
to
that.
If
that's,
the
correct
approach
is
mixing
in
to
the
widget,
without
actually
with
just
augmenting
the
the
instance
level,
without
augmenting
the
actual
global
widget,
namespace
I,
say.
E
L
Modality
extensions
on
the
widget
modality
that
t-mobile,
it's
just
a
matter
of
how
into
like
Stanton
and
what
the
other
pieces
are
for,
passing
the
data
back
and
forth
and
triggering
up
to
give
the
pop-up
dialog
so
yeah,
that's
I
mean
it
sounds
like
a
lot
of
the
work
is
already
done.
Just
needs
to
be
structured
at
some
reason.
Virtualized.
C
It
sounds
to
me
like
so
so
there
are
two
limitations
that
I
see.
One
is
why
why
limit
this
to
widgets?
You
know
this
could
be
useful
for
views
or
it
could
be
useful
for
even
just
nodes
on
a
page
and
then
the
other,
the
other
one
is
the.
It
looks
like
the
height
on
and
show
on.
Events
right
now
are
limited
to
events
on
nodes,
but
what,
if
I,
wanted
to
hide
or
show
a
pop-up
based
on
a
history
event
or
based
on
a
route
being
triggered
in
a
router
or
something
like
that?
C
F
So
if
you
had
a
node
that
you
wanted
any
event
or
focusing
blur
events
to
trigger
something
and
the
idea
behind
it
being
a
plug-in
would
be
that
anything,
that's
a
plug-in
host,
whether
it's
a
model
or
view
or
any
other
plug-in
hosts
that
could
possibly
be
on
the
page.
Then
it
could
be
plugged
into
that
and
that
functionality
would
just
in
surround
or
encapsulate
that
whatever
the
plug-in
host
is.
C
F
C
Q
C
J
C
C
Q
C
It
seems
like,
even
in
the
widget
case,
the
pop-up
would
have
to
expose
its
own
events
and-
and
you
would
use
those
instead
of
instead
of
listening
for
visible
change
right
if
it
wants
to
ensure
that
it
works
in
all
cases,
whether
it's
a
widget
or
just
a
base
class
of
some
kind
yeah.
What
I'm
wondering
is.
Q
If,
if
you
had
a
widget
popping
up,
would
you
want
to
listen
to
the
widget
visibility
changer?
Would
you
listen
to
the
pop-up
change
and
just
quickly
thinking
about
it
here?
I
would
probably
want
to
listen
to
just
the
pop-up
change,
because
if
the
popups
up,
you
can
generally
assume
that
the
widget
is
also
in
there
yeah.
F
C
F
C
Yeah,
but
that
seems
to
violate
the
concept
of
a
plugin.
The
the
idea
of
a
plug-in
is:
is
the
plug-in?
Does
it
stuff
within
its
own
plug-in
namespace,
so
you
have
widget
dot,
plug
a
namespace,
stop
whatever
and
that's
where
the
plugins
methods
live.
That's
where
it's
events
are
subscribed
and
then
that
keeps
it
separate
from
whatever
it's
being
plugged
into
so
that
it
can
be
more
generic.
It
can
be
more.
You
have
a
separation
of
concerns
there
and
I
think
if
the
plug-in
decides
to
start
publishing
and
firing.