►
From YouTube: Accelerate shipping with GitHub projects
Description
#30minutestomerge
Organizations today are under pressure to do more with less. That's why productivity is such an important issue. And that's where project planning comes in.
Project planning is a critical tool for organizations of all sizes. It can help you ship products faster, increase efficiency, and improve communication among team members. In this demo, Senior Software Engineer Jed Verity will show you how to use GitHub Projects to boost productivity in your organization. You'll learn how to create and manage projects, set deadlines, and track progress. You'll also learn how to use project planning to resolve conflicts and make better decisions about priorities. By the end of this talk, you'll have a better understanding of how project planning with GitHub Projects can help your organization succeed.
About our Speaker:
Having been both a manager and engineer at GitHub, not to mention a lifelong productivity nerd, Jed is deeply interested in tools and practices that help teams and individuals do their best work. Before joining GitHub, he was a Senior Manager of Systems Architecture at Maxar Technologies, but across a career that spans multiple decades he has been a founder, CTO, and, maybe the best title of all, "Fulfillment Manager" at Canto Software, Inc.
Jed also speaks 5 languages and holds a PhD in Tibetan Buddhism, but that can be hard to explain in the context of a career in technology, so he usually includes those facts in bios just to sound smart and interesting.
Jed lives in Charlottesville, VA with his family.
A
A
A
A
Second,
hopefully
you
enjoy
the
questions
that
I
ask
so
typically,
I
ask
them
like
what
kind
of
hobbies
they
have
and
jed
is
a
huge
baker.
He
just
told
me
what
he
made:
it's
a
japanese
milk
bread.
I
believe
it's
called
show
to
pan.
I
probably
butchered
that
pronunciation,
but
that's
the
go-to
when
he's
making
bread,
but
he
likes
to
mill
his
own
grain
and
stuff.
So
obviously
he's
like
really
into
the
bread
making
gimmick
they
do
currently
have
a
cat,
it's
kind
of
old,
it's
19
years
old.
A
He
grew
up
as
a
dog
person,
so
if
you're
a
dog
person,
he
is
one
of
us.
However,
he's
also
kind
of
converted
to
the
dark
side
and
enjoys
hanging
out
with
cats,
including
having
up
to
four
while
I
lived
in
a
tiny
apartment
in
san
francisco,
so
shout
out
to
six
people
in
a
small
apartment
in
terms
of
like
recent
purchases,
something
that
I
always
like
to
ask,
because
I
think
it's
interesting.
A
He
says
it's
boring,
I
think
it's
great
stuff,
so
he
bought
some
door,
stops
a
dehumidifier
and
a
shower
head
all
things
that
are
kind
of
normal
once
you
get
into
like
the
home
ownership
game
but
yeah
to
me.
Those
are
great
things
to
just
recently
buy,
but
to
others
it
probably
is
kind
of
boring
he's
currently
not
involved
in
too
many
open
source
projects.
A
He
decided
that
he'd
want
to
build
some
form
of
like
a
light,
bulb
flashing
action
that
would
alert
his
co-workers
whenever
he
sent
them
a
shout
out
in
a
commit
or
in
an
issue
or
something,
but
unfortunately
none
of
his
co-workers
have
given
him
access
to
their
iot.
So
when
that
happens,
he's
going
to
be
flashing
all
the
lights,
but
until
then
his
co-workers
are
just
going
to
be
left
in
the
dark.
So
with
that
I'd
love
to
bring
out
our
guest.
A
B
Thank
you,
sir
very
happy
to
be
here
with
everybody
today.
As
you
heard,
I
am
jed
verdi,
an
engineer
here
at
github,
currently
working
on
our
projects,
product
and
feature
set,
and
I'm
going
to
tell
you
a
little
bit
about
that
here
today.
So
I
have
just
like
one
and
a
half
slides
that
I'd
like
to
share
sorry,
as
I
look
over
to
the
side
make
sure
we
got
everything
right.
B
So
the
official
title
of
this
presentation
is
engineers
to
vps
accelerate
shipping
with
github
projects,
and
I
just
wanted
to
dissect
that
a
little
bit
to
manage
expectations.
So,
first
of
all,
I
do
not
have
any
magical,
incantations
or
tooling
or
process
that
will
reduce
your
shipping
time
by
some
percentage.
B
If
you
read
my
blog
post,
which
I
don't
I
assume
most
of
you
have
not
I'll
include
a
link
for
that
also.
You
know
that
to
me
one
of
the
most
compelling
things
about
github
projects
is
that
it's
not
especially
opinionated
about
a
particular
workflow
or
style
like
agile
and
so
forth.
It's
really
a
collection
of
primitives
in
what
I
hope
is
an
intuitive
interface
that
you
can
then
compose
into
whatever
kinds
of
experiences
you
want.
B
What
that
means
is
it's
very
useful,
I
believe
for
everybody
from
individual
contributors,
engineers,
designers
and
so
forth,
up
through
managers,
directors,
vps
and
beyond,
because
you
can
just
dial
in
whatever
particular
experience
you're
looking
for
so
with
that.
Let
me
see
if
I
can
start
sharing
my
screen
and
take
you
through
some
of
this,
I'm
going
to
show
you
a
few
things,
and
then
we
are
going
to
jump
into
a
demo
of
sorts
I'll,
explain
that
more
in
a
second
okay.
So
to
start
with,
I
want
to
just
give
you
some
places.
B
You
can
go
to
look
at
some
things
if
you
haven't
been
here.
This
is
our
marketing
page
for
issues
and
projects,
and
this
is
the
splashiest
way
to
just
get
a
quick
glimpse
at
some
of
our
most
compelling
features.
Although
I'll
show
some
of
them
to
you
today,
there's
a
video,
that's
fun
to
watch
these
high
level
overview
of
features
like
toggling
between
board
and
table
sub
tasks
in
markdown,
a
command
palette
for
super
users.
B
That
is
the
context
for
this
session
today,
but
I
have
nothing
else
to
show
you
in
the
way
of
slides
or
marketing
material.
What
I
really
want
to
do
is
share
a
different
screen
now
and
we
are
going
to
build
a
project
from
scratch
together
as
what
I
hope
will
be
the
best
way
to
really
meaningfully
there
we
go.
That's
the
one
give
you
a
sense
of
how
this
all
works
and
how
it's
useful
for
engineers
and
managers,
directors,
vps
alike,
so
for
our
demo.
Today,
I've
created
this
organization.
B
So
if
you
go
to
your
organization
or
to
your
user
account,
you
should
have
a
projects
tab
and
traditionally
this
has
had
our
kanban
board
style
version
of
projects
which
was
very
limited
and
frankly,
in
my
view,
not
terribly
useful.
Just
recently,
we
have
shipped
this
v2
version
of
projects
that
I'm
showing
here
today
and
it's
much
much
more
useful
and
it
is
growing
quickly.
We
try
to
ship
twice
a
week,
new
features
and
fixes,
and
so
that's
what
we're
going
to
use
today.
B
B
So
I'm
going
to
just
start
a
brain
dump
in
here
of
what
I
think
might
help
us
get
started.
Building
notifications
for
reactions
and
the
way
that
I
like
to
start.
As
I
know
many
folks
do,
is
with
a
user
story.
This
is
probably
familiar
to
many
of
you
here,
but
for
those
of
you
who
are
not
familiar
with
that,
it's
a
way
to
articulate
something
from
the
perspective
of
the
user,
so
that
you're
not
prejudicing
based
on
particular
implementation
details
or
anything
like
that,
you're
just
trying
to
capture
the
value
to
a
user.
A
B
B
Should
we
batch
notifications
or
send
once
a
day,
so
they
don't
get
overwhelmed
and
see.
I'm
just
dumping
these
thoughts
right
now,
total
serializing
my
thought
process
into
what
are
called
draft
issues,
I'm
going
to
put
some
more
in
here
in
a
second,
but
let's
take
a
quick
sidebar
as
it
were
for
draft
issues,
because
this
is
a
new
concept
for
github.
It
does
not
map
to
any
repo.
You
cannot
find
these
currently
via
repo.
They
exist
only
in
the
project,
space
and
they're
kind
of
an
issue
light.
B
So
you
have
a
description
field
where
you
can
put
in
some
details,
you
can
add
assignees
and
put
a
status
on
it,
but
that's
basically
it
so
I'm
not
going
to
get
too
much
into
that
now
just
to
to
let
you
know
that
that's
what
these
are
and
we'll
convert
some
of
these
to
real
issues
in
just
a
minute.
So
what
other
questions
do
I
have
here?
Should
we
group
notifications
by
emoji
a
bunch
of
these
questions
coming
out
and
in
my
mind
I
have
this
view
of
all
right.
B
There's
gonna,
be
notifications
showing
up
in
this
notifications
view
which
you
can
get
to
by
clicking
the
bell,
and
so
I'm
trying
to
map
my
vision
for
what
this
is
and
there'd
be
other
people
involved
if
it's
our
whole
team
working
on
this
product
managers,
designers
and
so
forth.
So
I'm
trying
to
figure
out
how
this
is
going
to
work
and,
ultimately
for
now
to
ship
soon
and
to
not
try
to
over
engineer
or
overthink
this.
B
B
So,
as
I'm
serializing
my
thoughts
into
this
project,
I'm
starting
to
see
that
there
are
some
different
kinds
of
thoughts
and
different
kinds
of
issues
appearing
and
so
just
to
keep
the
interface
clean
and
focused
I'm
going
to
create
a
new
field
that
we'll
just
call
category
for
now,
I'm
going
to
make
it
a
single
select
so
that
I
can
pick
from
a
list
and
we'll
just
say
right
now.
We
have
two
kinds
of
things.
We
have
a
story
and
we
have
a
question.
B
B
This
gives
me
kind
of
a
cleaner
way
to
see
what
we're
really
talking
about
here
and
at
this
point
I
can
keep
filling
up
with
questions,
but
I
want
to
start
moving
forward
a
little
bit,
and
so
the
first
thing
I'm
going
to
do
is
map
a
feature
to
each
of
these
stories.
Sometimes,
stories
have
multiple
features
that
are
necessary
to
ship
in
order
to
execute
on
the
story,
but
for
now,
let's
just
say:
there's
there's
kind
of
one
each.
So
I'm
going
to
pop
it
in
here.
B
For
starters
and
just
say:
there's
one
feature
for
this
first
story,
which
is
just
show
and
notification
in
the
notifications
ui
after
a
reaction,
I'm
not
saying
it's
the
best
wording,
but
let's
call
it
that
for
now-
and
you
can
see,
I'm
I'm
putting
it
in
the
stories
group
for
now,
which
doesn't
make
sense.
So
I
think
we've
got
a
new
category
here.
Let's
actually
add
a
feature
category
that
seems
more
important
than
question,
so
I'm
going
to
save
that.
Go
back!
B
Call
this
a
feature
and
all
right
now
I've
got
that
new
grip
group
and
then
there's
another
one
which
is
just
like
toggle
reaction
notification:
settings.
Okay.
So
now
I'm
expecting
this
feature
to
be
maybe
the
longest
living
item
in
this
project
that,
like
this,
won't
go
away
until
the
feature
is
actually
shipped.
So
I'm
feeling
quite
certain
that
this
needs
to
be
an
issue
that
we're
tracking
in
the
repo,
and
so
this
is
one
way
to
do
it.
B
There
are
a
number
of
ways,
but
I'll
just
show
you
this
simplest
one
for
now,
which
is
to
click
on
this
context.
Menu
convert
to
issue
pick
your
repo,
repo
and
and
this
organization
is
called
github.
I'm
going
to
convert
this
one
also
and
now
I
have
full
featured
issues
available
to
me
and
I
could
click
to
it
in
the
classic
interface.
B
If
I
wanted
to
or
view
it
in
this
sidebar,
I've
got
all
the
things
here
that
I
would
expect
to
see
from
a
full-fledged
issue
and
now
that
I'm
looking
at
these
I'm
realizing
for
this
demo,
I
will
not
have
the
time
to
sh
to
flesh
out
all
of
these,
and
so
I'm
going
to
focus
on
the
simpler
one,
which
is
this
notification
settings,
and
to
do
that,
I'm
going
to
create
a
separate
tab.
That's
a
little
more
focused.
B
I'm
going
to
call
this
overview,
because
this
has
just
everything
in
it
could
be
good
for
searching
and
filtering.
Then
I'm
going
to
create
a
view
that
is
just
focused
on
well
I'll.
Tell
you
what
let's,
let's
create
one
that
is
by
feature,
and
this
would
be
a
nice
way
for
us
to
encapsulate
the
work
connected
with
the
two
features.
But
to
do
that,
I
don't
have
any
way
to
really
meaningfully
group
these
into
separate
buckets.
B
And
these
are
really
kind
of
more
connected
into
notifications
for
now.
So
let's
go
back
into
feature
and
let's
add
that
field
and
group
by
it.
This
gives
us
a
way
to
just
encapsulate
by
the
feature.
I
don't
know
if
this
is
necessarily
useful
to
folks,
although
it
gives
us
a
sense
of
what
scope
of
issues
are
there
for
each
of
the
features.
B
B
You
can
also
use
command,
f
and
just
filter
on
the
things
you
want
to
see
here,
and
in
this
case
we
know
we
have
this
feature
field
and
we're
just
interested
in
the
settings
feature,
and
so
I'm
going
to
keep
this
view
filtered
to
that,
and
I'm
going
to
group
this
to
make
it
a
little
clearer
in
a
second.
But
let's
start
phyllis
filling
this
up
again
a
little
bit.
We've
got
a
story
that
helps
give
us
context.
B
We've
got
the
feature,
that's
going
to
be
our
longest
running
top
level
item
and
now
what
are
some
of
the
other
things
that
come
to
mind
for
this?
First
of
all,
I'm
thinking
we're
going
to
need
this
to
show
up
in
the
interface
somewhere
in
the
github
experience,
and
my
guess
is
maybe
this
is
going
to
be
here
in
this
notification
settings,
but
I'm
not
sure
this
is
not
my
job
per
se.
I'm
I'm
an
engineer.
B
I
may
have
input,
but
let's
just
create
an
issue
for
this
design:
the
ui
ux
for
the
notification
all
right,
so
I
know
we're
going
to
need
to
do
that
from
the
engineering
side,
I'm
starting
to
decompose
the
work
that
this
will
require,
and
I
can
think
of
a
few
different
things.
First,
we're
going
to
need
to
post
this
toggle
choice
to
our
api
so
that
it
can
be
persistent.
B
Probably
a
database,
but
anyway
just
know
we
need
to
do
that
somewhere,
okay,
and
so
now,
I'm
looking
at
these
again
and
saying
these
are
definitely
some
different
kinds
of
issues
now,
and
it's
not
helpful
to
just
look
at
all
of
this
in
a
flat
list,
so
I'm
seeing
some
clear
design
and
engineering
tasks,
and
so,
let's
just
create
some
more
categories
for
now
to
bucket
these
a
little
more
clearly,
okay,
this
is
a
design
task.
This
is
an
engineering
task.
B
Engineering,
engineering
designer
probably
doesn't
care
about
these,
and
so,
let's
now
bucket
by
these,
to
make
it
clear,
okay.
So
now
this
interface
is
starting
to
become
useful
for
executing
on
everything
necessary
to
deliver
this
feature.
I
can
see
the
story,
that's
driving
it
the
feature,
that's
tracking
it
design,
work,
engineering,
work
and
so
forth
as
an
engineer,
I'm
most
interested
in
the
engineering
section.
So
I
have
some
questions
now
about
these
issues
that
are
drilling
into
the
actual
implementation.
For
example,
do
we
already
have
an
endpoint?
B
Now
I
could
categorize
these
as
questions,
but
now
I'm
feeling
like
my
questions
category
is
not
that
useful
anymore.
It's
like
are
they
engineering
questions,
product
questions
which
feature
they
relate
to,
and
so
I'm
starting
to
recognize
that
these
actually
are
the
kinds
of
questions
that
lead
to
adrs
an
adr.
If
you're
not
familiar
is
an
architectural
design
decision
record
and
it
is
a
way
to
focus
and
surface
conversation
and
ultimately
decisions
about
what
kind
of
architecture
we're
going
to
design
or
leverage,
and
this
is
a
really
it's
an
engineering
concern.
B
It
often
comes
out
of
engineering,
but
it's
pretty
useful
to
surface,
because
people
who
are
onboarding
a
project,
sometimes
even
technical
project
managers
and
and
project
management,
product
managers
and
project
management,
folks
like
to
have
a
clear
sense
of.
Why
did
we
do
that
right?
If
things
are
taking
a
long
time,
and
it's
because
of
this
decision,
why
did
we
even
do
that?
B
Should
we
go
back
to
the
other,
so
I
kind
of
like
having
these
surfaced,
but
now,
as
an
engineer,
I'm
feeling
a
little
bit
annoyed
that
every
time
I
come
into
our
feature
view
engineering
is
like
getting
pushed
down
and
out
of
below
the
fold,
and
so
really
what
I
would
like
now
is
an
engineering
specific
view.
So,
let's
create
that
we
will
filter
by
category
engineering
and
I've
realized
now
that
adr
is
something
I
also
want
to
have
present
in
here.
B
B
Let's
do
both
of
these
and
then
I'd
like
to
link
these
also
into
the
issues
that
they
relate
to,
and
I
expect
this
is
going
to
be
my
task
or
somebody's
task
eventually,
and
so,
let's
create
issues
out
of
all
of
these
and
let's
start
to
put
statuses
on
them,
and
you
know
what
I'm
feeling
like.
I
don't
want
to
keep
having
to
add
the
to
do.
B
I
want
to
just
by
default,
to
put
a
to-do
status
on
there,
so
we
have
this
workflow
already
in
place
when
a
issue
or
pull
request
is
added
to
the
project
automatically
set
it
to
to
do
so,
I'm
going
to
enable
that
come
back
here.
I
do
have
to
do
these,
though,
since
they're
already
created
okay
and
now,
let's
just
go
ahead
and
link
these
into
the
issues
that
they're
relevant
to
so
in
this
case,
toggling
posting
to
the
api
is
relevant
to
this
question
of
whether
we
have
an
endpoint
or
not.
B
Here
I'm
using
task
lists
which
again
give
us
some
bi-directional
linking
across
issues
automatically
and
we
can
close
them
and
see
their
status
here
from
the
issue
that
they're
embedded
in
that
adr
is
also
relevant
to
this
issue
include
the
checks
checkbox
just
so
that
we
can
actually
check
them
off
here.
You
could
still
just
put
a
bullet
point
in
there
if
you
wanted
to.
If
you
preferred
that,
and
then
the
persistence
adr
is
related
to
this.
B
Okay,
all
right,
so
these
are
linked
together
now
and
it's
feeling
like
we
can
start
rolling
on
this,
and
let's
say
that
I
know
for
sure
under
my
alter
ego
goes
or
zool
that
I'm
going
to
be
the
one
to
do
this
discovery
work
at
this
point.
I
can
come
in
here
and
see
everything
pretty
clearly.
We
can
use
a
board
view
if
we
prefer
to
actually
have
a
more
kanban
like
experience
to
task
this
out
and
track
progress.
B
But
what
I
personally
like
to
do-
and
I
know
a
bunch
of
engineers
like
to
do-
is
to
have
a
me
tab
or
in
some
cases
a
me
board
and,
having
this
view
filtered
by
assignee
me
gives
us
a
focused
place
to
say
what
is
on
my
list
of
things
to
do
just
me
and
everybody
can
use
this
since
the
assignee
is
not
hard-coded
uses.
The
special
me
filter
and
I
may
choose
to
group
this
by
status
or
by
other
dimensions.
B
You
can
also
have
the
setup
differently
across
table
and
board
views,
but
I'm
not
going
to
go
too
deep
in
that
for
now.
Just
going
to
point
out
the
value
and
having
this
now
here
is
one
little
optimization
that
may
or
may
not
be
relevant
to
everybody.
On
this
call,
we
have
some
teams
using
this
and
other
teams
that
are
not
using
this
to
show
this
off.
Well,
I'm
going
to
actually
also
create
a
design
view
filtered
by
design
put
it
over
here
and
basically
the
workflow
goes
like
this.
A
B
We
want
to
try
to
include
context
that
doesn't
require
flipping
through
tabs
and
trying
to
find
the
right
issue
in
the
right
place,
but
there
are
some
issues
with
this
right
like
if
design
is
only
going
to
be
working
on
settings
and
it's
seeing
all
features
that
have
been
added
to
this
board.
We
have,
for
starters,
an
additional
filtering
opportunity
here.
So
let's
start
here
and
just
add
in
this
first
approach
of
filtering
only
by
settings,
that's
useful.
B
Here
is
an
optimization
that
may
help
it
requires
some
setup,
but
once
you've
got
it,
you
can
use
it
pretty
pretty
regularly
without
additional
legwork,
and
the
idea
here
is
to
actually
enrich
our
status
options
with
values
that
can
indicate
readiness
for
a
particular
team
to
work
on
a
given
issue.
So
the
way
I'm
going
to
do
this
for
now
is
just
say
all
right:
we've
got
a
feature
phase
which
is
defining
requirements,
and
maybe
this
is
all
or
mostly
on
the
product
team.
B
B
B
These
are
the
phases
that
I
care
about
as
a
designer
or
design
team,
and
so,
if
we
come
back
to
our
feature
here,
it
currently
has
no
status
and
it's
not
showing
up
in
our
design
tab
and
if
it
were
in
defining
requirements,
it
would
still
not
show
up
in
that
tab.
But
as
soon
as
let's
say
a
product
manager
is,
is
finished
with
that
and
says.
Okay,
we've
got
everything
we
not.
B
Again,
this
all
of
this
filtering
work
here,
which
is
admittedly
a
bit
gnarly.
You
can
just
persist
into
your
view,
so
that
you
only
have
to
do
it
once
so
now,
designers
are
working
on
it
and
it
gets
put
into
in
progress
still
working
on
it
and
then
finally
says
great.
Now
we
are
ready
for
design.
The
feature
disappears
from
their
view
and
it
shows
up
here
and
ready
for
engineering.
Of
course,
we
may
say
well
actually,
we've
worked
on
this,
but
there
is
still
something
necessary
to
be
done.
B
Here
comes
back
into
design,
so
on
and
so
forth
doesn't
work
for
everybody
for
every
workflow,
but
in
really
busy
boards
and
environments
it
can
be
a
nice
way
to
just
focus
only
the
content
that
you
care
about.
Okay.
So
I'm
close
to
the
end
of
time
that
we
have
available
for
this,
but
I
want
to
show
one
last
feature,
one
last
workflow
that
you
can
use
projects
for,
and
that
is
to
bubble
up
to
manager,
director
vp
level
from
these
same
issues
without
too
much
additional
legwork.
B
So
right
now
we
have
the
me
view
scoped
to
an
individual
engineer
or
an
individual
contributor
of
any
of
any
kind.
We've
got
the
engineering
view,
which
is
maybe
useful
for
an
engineering
team
for
a
dri,
a
directly
responsible
individual
who
is
leading
the
work
possibly
for
the
engineering
manager.
We
have
design
for
the
individual
or
team.
B
We
have
the
feature
which
can
be
useful
for
project
managers
also
for
other
managers
who
want
to
see
the
whole
scope
of
what
we're
working
on,
and
then
we
have
these
views,
which
have
you
know,
questionable
value
for
a
particular
persona,
but
which
still
give
us
a
particular
slice
and
dice
of
the
view.
So
what
I
want
to
create
now
is
something
called
the
org
view,
and
let's
put
this
over
here
and
at
this
level,
let's
say
that
we
as
directors
and
potentially
even
vps,
are
not
really
concerned.
B
B
Let's
just
say
for
now
that
really
all
we
want
to
see
are
the
features
that
we're
shipping
and
this
could
be
even
rolled
up
one
higher
right,
like
especially
for
vps,
like
reaction
notifications,
but
for
now,
let's
just
keep
it
at
this
grain
and
say
we
just
care
about
seeing
the
features
and
what
I
may
care
about
here.
First
is
like
target
date
to
ship.
So,
let's
create
a
date
field
and
let's
say
this,
one
hasn't
even
started,
so
it
doesn't
have
a
date.
B
But
this
one
we're
shipping
tomorrow
exciting
and
another
thing
we
might
care
about
is
something
we
could
call
health
or
status,
and
this
is
just
to
show
like.
Are
we
on
track
or
are
things
in
trouble
and
do
we
have
enough
context
to
understand?
Why
do
we
need
more
resources
time
or
do
we
need
to
cut
scope?
B
B
More
syntax
highlighting
and
that's
repos,
and
in
this
way
somebody
at
what
we
call
an
m2
or
higher
level
managing
managers
can
really
see
what's
happening
across
the
entire
org,
I'm
so
sorry
for
taking
us
past
our
stop
time.
That
is
the
end
of
the
presentation.
For
now,
if
people
are
interested
in
sticking
around
to
ask
any
questions
or
go
deeper
and
hack
on
this
together,
I'm
happy
to
do
that,
but
yeah
leave
it
at
that.
For
now,.
A
It's
pretty
dope.
Thank
you
very
much
for
kind
of
walking
us
through
the
new
the
new
and
improved
version
of
github
projects.
As
someone
who's
been
at
github
for
a
hot
minute,
it's
been
a
blast
to
kind
of
watch
projects,
kind
of
grow
and
change
over
the
years
and
I
kind
of
agree.
The
kanban
board
like
worked
for
like
a
subset
of
people,
but
the
new
version
of
projects.
A
A
There's
a
comment
in
chat
to
continue
to
the
discussion
at
github.com
30
minutes
and
that's
30
with
two
numbers
there
for
an
async
q,
a
where
jen
and
I
will
be
answering
any
questions
that
you
might
have.
It's
also
a
great
spot.
The
github
community
has
a
bunch
of
different
discussions
happening.
So
if
you
don't
have
any
questions
on
projects,
but
you
do
on
say,
github
advanced
security
or
actions.
People
are
definitely
answering
questions
there
as
well.
But,
as
always,
I
appreciate
jed.
A
Absolutely
it's
always
a
pleasure
to
show
the
community
what
we've
been
working
on,
but
yeah.
If
you
thanks
again
for
signing
in
again,
if
this
is
your
first
time,
hopefully
you'll
join
us
again
and
if
you've
been
a
long
time
watcher.
I
appreciate
you
a
whole
bunch.
So
thanks
again,
I
hope
you
all
have
a
great
rest
of
your
day
rest
of
your
week
and
have
a
safe
weekend,
but
thanks
all
have
a
great
one,
and
that's
us.