►
From YouTube: The secret to writing high-quality code more efficiently
Description
To keep up with the ever-evolving tech landscape, DevOps leaders are forced to add more and more tools to their tech stack. But in the current economic environment, it's important that your development tools don't get in the way of business growth.
In this panel, we'll talk with Sherin Mirza, Competency Center Lead of Full Stack Development at Shell, Zoë Bosschaart, Cloud Engineer at Ahold Delhaize, and Adriaan Knapen, Senior DevOps Consultant at Eficode, to hear how updates to the integrated development environment (IDE) help their developers spend more time writing quality code and less time context switching between tools.
Stay up-to-date on all things GitHub by subscribing and following us at:
YouTube: http://bit.ly/subgithub
Blog: https://github.blog
Twitter: https://twitter.com/github
LinkedIn: https://linkedin.com/company/github
Instagram: https://www.instagram.com/github
TikTok: https://www.tiktok.com/@github
Facebook: http://fb.com/github
About GitHub
It’s where over 100 million developers create, share, and ship the best code possible. It’s a place for anyone, from anywhere, to build anything—it’s where the world builds software. https://github.com
A
Hello,
everyone
and
welcome
to
GitHub
Galaxy
we're
here
for
day,
one
we're
very
excited
to
have
you
with
us,
and
we've
been
keeping
an
eye
on
the
chat
and
we've
been
loving,
seeing
all
of
the
gifts
all
of
the
conversations
and
really
getting
a
feeling
of
the
diversity.
I
guess
that
we
have
across
the
region
here.
So
thank
you
for
joining
us
here
today.
A
My
name
is
Chris
Reddington
I'm,
a
senior
manager
at
GitHub,
I
work
with
many
Enterprises
startups
and
other
people
who
use
GitHub
day
today
for
their
work,
and
we're
really
excited
to
be
talking
with
you
today,
all
about
the
secret
to
writing
high
quality
code
efficiently,
which
is
such
an
important
topic
when
we
think
about
the
worlds
we
live
in.
Expectations
have
never
been
higher
in
terms
of
quality,
making
sure
that
the
apps
that
we
ship
the
services
that
we
ship
are
top
quality.
A
So
we're
excited
to
be
sharing
some
tips
and
tricks
here
with
you
today
before
we
jump
into
the
session,
and
we've
got
a
really
great
session
here
today
as
well.
By
the
way,
a
number
of
great
guests
I
just
want
to
run
through
some
quick
q,
a
just
to
make
sure
that
everyone's
on
the
same
page
and
that
you
can
really
enjoy
the
session
here.
So
if
you've
got
a
question,
there
is
a
q,
a
tab
on
the
panel
on
the
right
hand,
side.
A
So
please
do
go
and
use
that
and
we've
got
some
moderators
who
will
be
keeping
an
eye
on
that
and
bringing
those
to
our
attention
and
chat.
Moderators
are
here
to
assist
and,
of
course,
if
there's
anything
interesting
throughout
the
session,
maybe
you'd
like
to
explore
a
little
bit
further,
have
a
one-on-one
discussion
a
little
bit
later
on
and
please
feel
free
to
schedule
a
meeting
there's
a
button
on
the
top
of
your
screen,
where
you'll
be
able
to
go
ahead
and
do
that.
A
If
you
have
been
having
some
issues,
I
did
see
some
comments
in
the
chat
there
about
people
having
issues
in
terms
of
the
chat
being
slow
and
content.
Etc,
please
use
chrome
chrome
is
the
recommended
browser
for
this
particular
service.
This
particular
application.
So
any
issues.
Please
try
that
and
of
course,
if
you
are
seeing
issues
refresh
the
stream
you'll,
you
should
be
good.
There,
then
any
other
troubles
if
there's
vpns
or
other
things
that
might
be
running
on
your
devices.
A
Maybe
try
disabling
those
that
might
be
interfering
with
the
service
there
as
well.
So
just
keep
that
in
mind
any
other
issues.
There
are
some
great
troubleshooting
docs
out
there
available
as
well
for
you
to
go
and
use.
So
that's
the
housekeeping
out
of
the
way,
let's
go
and
get
kicked
off
with
the
session
here.
B
B
A
C
I'm
Adrian
I'm
a
senior
depth
consultant
at
efficode
at
Epico.
We
focus
on
delivering
consultancy
around
devops
to
help
our
customers
improve
their
software
delivery
capabilities.
We
do
things
like
consultancy
on
migration
to
get
up
and
how
to
get
the
most
out
of
it
around
having
GitHub
Enterprises
is
self-hosted
on
service
managed
by
us
to
be
here.
A
A
If
there's
downtime
of
my
favorite
game,
my
favorite
retail
service,
my
favorite
app
I
just
go
and
look
elsewhere
now,
and
quality
is
one
of
those
things
that
we've
really
come
to
expect
in
the
day-to-day,
in
everything
that
we
do
so,
let's
maybe
start
with
at
the
beginning
and
think
about
some
of
the
challenges
that
you
were
having.
So
what
were
the
challenges
that
started
you
along
this
path
and
thinking
about
investing
in
quality
across
your
organization?
B
B
Well,
there
were
quite
some
silos
people
working
on
the
same
things,
trying
to
event
the
the
same
wheel
there
and
yeah.
The
challenge
was
to
to
bring
that
all
together
and
starting
to
to
optimize
that
in
an
inner
Source
model
yeah,
that
was
basically
the
biggest
challenge
getting
everyone
together
and
optimize.
Everything.
A
Gotcha
yeah
that
whole
idea
of
Reinventing
the
wheel,
many
people
making
duplicate
things
all
that
to
something
suspiciously
similar
when
you
could
be
maybe
working
together,
doing
something
more
efficient
and
building
something
greater
than
the
sum
of
its
parts
is
absolutely
a
common
challenge.
So,
thanks
for
sharing
that
one
Zoe
Sharon,
maybe
to
yourself
next.
D
A
Excellent
excellent,
thank
you
for
sharing
there
Sharon
and
it's
interesting.
We've
just
got
a
poll
on
screen
here
now
asking
how
many
tools
are
folks
using
in
their
organization
day
to
day,
and
it
sounds
like
so
far
at
least
and
we'll
give
it
maybe
a
few
more
seconds.
There's
an
interesting
split.
A
lot
of
folks
are
saying
one
to
five,
so
fewer
tools,
but
there's
still
a
mix.
A
You
know
there's
some
where
there's
actually
five
to
ten
and
some
ten
plus
and
I
think
that
spread
of
different
tools
needing
to
integrate
everything
together
can
really
impact
some
of
those
quality
challenges,
because
you
start
having
to
think
about
the
plumbing
between
all
these
different
things
and
the
handoff
between
these
different
points
as
well.
So
some
very
interesting
insights
here,
Adrian.
Maybe
let's
move
over
to
yourself
and
some
of
the
trends
you
see
from
various
customers,
you're
working
with.
C
Yeah
yeah,
so
as
soon
as
we
are
like
well
as
a
result,
we
see
a
lot
of
these
snowflakes
and
one
of
the
kind
of
common
things
is
that,
like
even
after
migration
to
a
specific
School
kind
of
teams
are
still
kind
of
stuck
with
the
old
tools
and
all
the
way
of
working,
and
they
don't
really
yet
Embrace.
This
new
way
of
developing
and.
C
Of
culture
shift
you
need
afterwards
is
really
like
necessary
to
get
the
the
entire
organization
to
actually
kind
of
follow
in
the
transition
that
the
organization
is
trying
to
achieve
and
half
of
the
times.
It's
that
just
the
it's
just
like
a
way
of
kind
of
framing
it
and
getting
the
organization
aware
that
the
tools
have
changed
and
like
that,
there's
new
way
of
working
and
that
it
actually
helps
them
at
the
end
of
the
day
and
that
it
makes
their
them
more
productive.
C
B
C
A
Absolutely
I
think
this.
What
we're
talking
about
here
right
is
really
cultural
change
to
a
degree
when
I'm
thinking
of
all
of
the
different
themes,
I've
heard
so
far,
it's
not
just
about
the
tooling
change
and
bringing
some
of
that
quality
into
what
we're
doing.
But
there's
this
cultural
change,
I
think
Zoe
you
mentioned
about
this
inner
Source
culture
as
well
and
being
able
to
bring
everyone
into
this
open
world
that
we
work
in
rather
than
these
closed
silos.
So
maybe
Sharon
to
start
us
off
with
here.
A
D
Yeah
I
think
bringing
such
a
huge
cultural
change
and
also
the
technical
Excellence.
How
we
adopted
inner
Souls
cannot
happen
overnight,
but
what
we
have
done
at
Shell
is
we
created
an
inner
Source
Guild
that
allows
the
practitioners
to
form
multiple
inner
Source
communities
based
on
the
technology
stack,
whether.
D
As
code
or
you
are
doing,
full
stack
development
or
even
data
science
and
data
engineering
having
these
inner
Source
communities
will
help
the
practitioners
to
get
close
to
the
subject
matter.
Experts
and
these
inner
Source
communities
are
also
responsible
for
maintaining
the
inner
Source
assets
that
that
are
solely
build
on
that
reusable
concept.
I
think
that
really
helped
in
terms
of
adopting
some
of
these
inner
Source
assets
so
that
teams,
product
teams
don't
have
to
reinvent
the
way.
D
If
somebody
has
already
done
it,
they
could
reuse
that
code,
our
libraries
and
be
productive
and
do
it
much
more
faster.
But
what
is
more
important
is
the
quality
of
those
inner
Source
assets
is
even
more
important
because
that
is
reused
all
across
the
organization.
That's
where
we
have
created
lot
of
inner
Source,
Readiness
checks
and
Bots.
That
will
allow
you
to
identify
whether
you
needs
the
quality
criteria
that
can
be
that
this
asset
can
be
consumed
by
the
rest
of
the
practitioners.
A
Interesting,
no
thank
you
for
sharing
that
friend.
I
think
there's
some
really
interesting
insights
in
what
you
said
there,
and
also
looking
at
the
poll
here
as
well.
I've
been
watching
the
results
come
in
and
it's
been
quite
balanced
between
people
either
doing
inner
Source
or
not
doing
inner
source.
So
just
in
case
folks
aren't
aware,
the
idea
of
inner
source
is
really
this
concept
of
bringing
open
source
practices,
open
source
principles
and
using
them
inside
your
day-to-day
development.
A
So,
rather
than
having
different
teams
operate
in
silos,
you
operate
a
bit
like
open
source
communities.
Do
they
work
openly?
They
work
transparently.
They
are
Global
in
nature.
They
are
distributed.
You
know
they
work
asynchronously.
All
of
these
kind
of
things
remotely
as
well
are
principles
and
practices
that
we
start
bringing
into
how
we
work
day
to
day.
So
getting
rid
of
you
know
almost
those
closed
walls
of
development
and
building
something
bigger
and
better
and
greater
for
the
community
to
better
than
the
sum
of
our
parts.
A
So,
let's
maybe
jump
on
and
move
on
from
that
conversation,
maybe
to
yourself
sewing
because
I
suppose
to
get
this
kind
of
community
from
an
inner
Source
perspective.
We
saw
a
little
bit
earlier.
There's
some
variety
in
Tooling,
in
terms
of
where
folks
are
using
today,
tooling
and
non-standardized.
Tooling,
can
be
a
little
bit
of
a
challenge,
I
suppose
so.
Adopting
this
kind
of
community.
B
Yes,
so
when
we
were
starting,
our
initial
Journey,
especially
on
the
cloud
platform
that
we
were
building
standardized
tooling,
is
yeah
helps
a
lot
when
trying
to
achieve
effective
inner
Source
community,
and
what
really
helps
is
that
we
have
within
outdoes.
So
we
have
one
Global,
GitHub
organization,
where
all
codes
is
stored
and
everybody
in
that
organization
is
able
to
read
all
that
code.
So
you
easily
can
do
a
code
search.
B
If
you
want
to
to
look
something
up
to
see,
if
somebody
else
already
did
it
contact
that
person
which
makes
the
journey
a
lot
easier,
also
adopting
and
trying
to
change
the
culture
instead
of
people
emailing
us
with
with
a
question
motivating
them
to
either
raise
a
pull
request
to
to
to
a
request
certain
infrast
codes
or
raise
a
feature
request
through
issues.
So
for
that,
that's
the
change.
That's
that
culture
change
of
starting
to
work
in
within
a
source
model
tooling,
is
something
that
helps
a
lot.
A
Love
it
love
it
and
I
couldn't
have
said
it
anyway
telling
what
you
just
said.
There
I
think
there's
really
this
empowerment
isn't
there
for
the
developer
Community
within
a
source
you're
able
to
work
together.
I
the
example
you
gave
about
pull
request
versus
email,
I've
seen
this
in
so
many
organizations,
I've
worked
with
where
it's
really
this
cultural
transformation
as
well.
People
get
a
bit
nervous,
sometimes
that
maybe
their
code
is
readable
for
people
in
the
company
and
suddenly
you
know
they
feel
a
bit
vulnerable
in
that
sense.
A
But
it's
absolutely
a
cultural
change
and
and
many
good
benefits
that
come
from
that
as
well.
It's
interesting
seeing
the
chat
actually
I've,
seen
some
folks
talk
about
the
inner
Source
Commons
as
well,
which
is
one
of
these
neutral
organizations
that
focus
on
sharing
practices
and
ideas
of
different
organizations
that
have
used
and
adopted
in
a
source
so
definitely
want
to
go
and
check
out
this.
So
thank
you.
Thank
you
for
sharing
that
Nile
Adrian.
A
Let's
maybe
finish
this
up
with
yourself
here,
so
that
process
from
going
maybe
from
multiple
tools
or
that
previous
kind
of
world
into
this
kind
of
inner
Source
world
and
starting
to
standardize
some
of
those
tooling.
What
are
maybe
some
of
the
common
pitfalls
that
you've
seen
across
customers.
You've
worked
with.
A
A
A
So
then,
let's
maybe
move
on.
We've
talked
about
I.
Guess
the
themes
in
terms
of
I
suppose
what
those
early
challenges
were.
What
were
those
early
wins
then,
because
I
think,
when
we're
going
on
this
transformation
showcasing
some
value
showcasing,
some
wins
is
so
so
important.
So
let's
maybe
stick
with
yourself
here
agent.
Actually,
what
are
some
of
those
initial
wins?
Maybe
the
value
of
having
that
single
integrated
platform
there.
C
Yeah
so,
like
I,
think
with
the
single
platform
it's
already
mentioned
earlier,
it's
very
easy
to
kind
of
start
using
different
Services
very
easily,
but
also-
and
that's
made
me
bet
on
like
how
like
get
up
actions,
kind
of
read
things,
how
you
build
CI
workflows
and
make
it
very
easy
to
build
reusable
components,
to
use
reusable
workflows
and
kind
of
get
standardized
code,
quality
analysis
and
10
guys
ways
to
do
cicd
throughout
your
organization
without
everyone.
Just
writing
there,
two
three
four
five
bedroom
lines:
Jenkins
files,
which
just
works
in
one
repository.
A
If
we
don't
have
that
standardized
kind
of
tooling
and
approach
and
platform
trying
to
bring
some
of
those
recommended
practices
at
scale
is
just
really
going
to
be
a
barrier
and
going
to
be
challenging,
because
if
everyone
is
using
different
underlying
platforms,
we
can't
start
helping
people-
and
you
know
centrally
Empower,
let's
say
and
I
think
we'll
talk
a
bit
later
in
terms
of
like
guard
rails
and
how
you
Empower
versus
control
and
govern,
and
so
we'll
leave
that
one
aside
for
now.
But
it's
it's
such
a
interesting
point.
A
D
Yeah,
so
in
terms
of
adopting
software
engineering
best
practices
right,
are
we
delivering
high
quality
products,
reducing
the
rework?
If
the
team
is
adopting
a
developer
platform
that
can
allow
easily
to
build
a
solution
starting
from
inception
all
the
way
until
deployment
with
less
complexity,
to
integrate
with
lot
more
tools,
then
you
improve
the
efficiency
and
productivity
of
the
team.
The
way
we
were
able
to
do
it
is
we
were
able
to
Auto
provision,
user
access
and
also
Auto
provision
creation
of.
D
Again,
when
we
build
so
many
pipeline
orchestration
tools
into
these
devops
tool
set,
it's
gonna
complicate
having
GitHub
actions.
Our
teams
are
able
to
recognize
those
deployment
patterns
and
build
reusable
workflows
around
those
patterns.
So
if
any
team
is
using
the
same
pattern,
they
would
just
call
that
reusable
workflow
and
create
their
cicd
pipeline
within
minutes.
So
that's
that's
where
the
reusability
kicks
in
and
it
helps
the
team
to
deliver
and
adopt
the
best
practice
at
a
faster
Pace,
but
also
the
delivery
solution
at
a
faster
phase.
A
Love
that
and
one
of
the
things
which
is
really
close
to
my
heart,
in
what
you
said
there
was
about
abringing
quality.
Obviously,
the
purpose
of
this
session
here,
but
security
as
well
is
a
part
of
that
quality
and
when
we
think
of
the
inner
Source
idea
as
well,
it's
all
about
Community,
it's
all
about
bringing
together
and
working
for
that
same
overall
goal,
rather
than
almost
what
silos
can
bring
and
having
that
maybe
friction
between
those
different
teams
and
bringing
security
into
that
workflow.
A
Bringing
security
is
just
another
quality
check
along
the
way.
It's
such
an
important
part
of
that,
especially
in
the
world
today
that
we
live
in
where
we
have
some
of
these
critical
vulnerabilities
that
organizations
need
to
react
to
If.
We
can
just
make
that
part
of
the
flow
part
of
the
cycle
and
just
make
that
natural
in
terms
of
our
developer
life
cycle,
then
it's
a
win
and
I
absolutely
love
that
example.
So
thank
you
so
much
for
sharing
that
Zoe.
A
B
Definitely
I
recognize
a
lot
about
Sharon
and
Adrian
already
told,
but
maybe
nice
thing
to
to
add
on
that-
is
that
when
we
started
to
Inner
Source
our
Cloud
platform,
first
well,
our
customers.
So
to
say
they
came
to
us
with
a
question
and
they
had
to
erase
that
feature
request
or
a
bug
on
our
backlog,
and
they
had
to
wait
a
long
time
and
well
starting
inner
Source,
motivating
those
people
to
do
race
or
spool
requests
themselves
or
raise
an
issue.
B
There
were
a
lot
of
manual
tasks
elaborated
or
eliminated
in
that
process
and
by
using
get
a
projects,
for
example,
with
automated
workflows
that
adds
those
or
yeah
gathers
those
pull
requests
and
issues
onto
one
board
for
the
for
the
cloud
team,
it's
really
easy
to
see
what
is
wished
for
and
I
saw
also
a
question
how
to
encourage
people
to
contribute.
Well,
this
is
one
major
win.
B
People
don't
have
to
wait
a
long
time
anymore
before
we
have
refined
stories
for
their
feature,
requests
put
them
on
the
backlog,
and
now
they
can
can
contribute
themselves
and
I.
Think
that
not
having
to
wait
that
long
again,
only
for
us
to
having
to
review
their
pull
requests
is
a
major
Pro
on
encouraging
people
to
contribute.
There.
A
Super
and
there's
also
some
bits
we
should
pull
out
to
that
as
well.
I
think
this
inner
Source
culture
that
we've
been
talking
about
here,
where
other
teams
in
our
organization
can
contribute
into
what
we
do
and
there's
several
several
benefits
from
that
like
it
all,
builds
upon
these
devops
Concepts
that
we're
used
to
and
that
we're
familiar
with
so
continuous
integration,
continuous
delivery
and
the
beauty
is
that
those
quality
checks,
so
whether
the
code
builds,
whether
unit
tests
execute
successfully
integration
tests,
security
tests,
linting,
whatever
kind
of
checks.
A
You
are
relevant
for
your
particular
scenario:
accessibility
testing
that
just
becomes
a
check
for
anyone.
So
it
doesn't
matter
if
you're
on
that
host
team
and
you're
the
team
that
maintains
that
project
or,
if
you're,
a
team
somewhere
else
in
the
organization
contributing
in
you
still
have
to
meet
the
same
standards
so
bringing
those
devops
practices
that
we're
familiar
with
is
just
part
of
this
natural
kind
of
development
life
cycle.
A
So
it's
great
because,
as
you
say,
that
friction
between
those
teams
then
starts
disappearing,
because
it's
not
about
having
to
raise
the
issue
with
another
team.
Instead,
it's
about
right
is
this
something
that
is
on
that
team's
backlog,
yes
or
no.
If
it
is
great
and
they're
able
to
get
to
work
on
it
soon
great
if
they
can't
okay,
if
it's
important
for
us,
let's
go
ahead
and
actually
prioritize
that
and
make
that
as
a
contribution
to
their
project
from
our
team.
A
So
it
really
builds
this
kind
of
collaboration
and
fostering
this
productivity
and
quality
is
really
at
the
center
of
all
of
that
as
well,
which
is
which
is
absolutely
awesome
and
I
loved
hearing
theme
between
sharing
yourself
and
between
Zoe
all
around
Automation
and
I.
Think
we'll
cover
this
a
little
bit
later
as
well.
But
you
know
GitHub,
action's,
very,
very
flexible.
Being
able
to
do
things
like
reusable
workflows,
builds
those
best
practices
once
and
allow
the
organization
to
adopt
them
at
scale,
but
equally
you're
not
just
limited
to
code.
A
You
know
it's
not
just
about
building
and
releasing.
You
can
react
to
say
a
new
issue
being
created
a
project
card
being
created
a
milestone
being
created.
So
it
gives
you
this
ability
to
automate
some
of
that
mundane
stuff.
That
actually,
then
allows
us,
as
developers
and
Engineers,
to
focus
on
the
important
thing
delivering
value
to
our
users,
building
quality
into
everything
that
we
do
so
really
really
awesome
to
see
that
there
interesting
poll
here
actually
as
well.
A
So
while
we've
been
chatting
who
in
your
organization,
is
using
GitHub,
probably
unsurprisingly,
a
majority
of
answers
on
app
developers
followed
by
data
professionals,
Ops,
community
and
product
teams,
GitHub
is
something
which
any
of
those
groups
can
use.
If
you
think
about
your
data
professionals,
probably
using
Jupiter,
notebooks
they're,
writing
SQL
scripts,
they
obviously
called
queries.
Their
Ops
Community
might
be
writing
terraform,
Powershell
bash.
Your
product
teams
are
probably
writing
product
specs,
for
example,
and
design
documents
and
things
all
of
that
could
be
defined
as
code.
A
Well,
you
know
some
of
that
is
code
and
bringing
some
of
those
quality
ideas
into
those
processes
as
well
is
absolutely
something
you
can
do
so
interesting
to
see
those
results
there
Adrian.
Maybe
let's
talk
about
one
other
thing
here
in
terms
of
winds
as
well
and
I
know
before
going
live,
we
were
talking
a
little
bit
about
GitHub,
co-pilot
and
there's
obviously
been
lots
of
news
over
the
last
week
or
so
with
co-pilot
X
as
well.
How
are
you
finding
from
your
experience,
working
with
customers
that
GitHub
co-pilot
wins
as
well.
C
C
It
lowers
like
the
barrier
to
actually
start
doing
this,
which,
in
the
end,
gives
this
like
higher
quality
of
code,
and
also
it
will
force
you
to
think
about
what
you're
actually
trying
to
achieve,
because
even
if
it's
wrong
or
not
exactly
right,
you
will
have
to
kind
of
think
like.
Why
was
the
suggestion
wrong
and
you're
not
just
bluntly
copying,
your
implementation?
A
Sure
and
it
it
allows
us
to
take
away
from
some
of
those
mundane,
boilerplate
type
things
and,
as
you
say,
focus
on
that
wider
problem
and
completely
right.
You
know
we
we
can't
kind
of
just
accept
anything
from
it.
We
need
to
put
it
through
like
any
code,
we
need
to
put
it
through
the
right
checks
and
balances
which
again,
because
we're
let's
say
going
on
this
inner
Source
kind
of
culture,
because
we're
using
devops
principles
and
baking
quality
into
everything
that
we
do
you
know
has
to
pass.
A
A
build
has
to
pass
a
unit
test
has
to
pass
security
checks
Etc
when
we
bring
that
code
into
what
we're
doing
it
just
then
goes
through
the
same
quality
checks,
because
we've
built
it
into
our
CI
CD
workflow.
So
love
that
seeing
it
all
come
together
there
good.
So
then,
let's
keep
moving
here,
because
can
you
believe
we're
already
halfway
through
the
session
here?
This
has
been
flying
by
let's
carry
on
thinking
then
about
that
Journey
you've
been
going
through.
A
So
we
were
talking
about
winds
just
there
a
moment
ago,
but
of
course
to
get
some
of
those
wins.
You
need
to
work
with
your
development
Community
internally
and
I
use
the
word
Community
very
explicit
there,
because
it's
it's
in
harmony.
It's
together,
you
know
you're,
not
working
as
a
separate
Silo.
This
absolutely
needs
to
be
this
kind
of
cultural
journey
together.
So
Sharon.
D
D
On
top
of
it,
collecting
the
ideas
from
what
developers
would
think
would
better
the
community
or
better
the
organization
we
were
able
to
create
the
GitHub
repo
and
where
we
can
initiate
the
discussions
right
in
these
discussions,
you
can
go
ahead
and
start
posting
the
queries.
These
queries
initiate
more
and
more
responses
that
eventually
translate
an
idea
into
an
implementation.
You
can
use
the
ability
to
pull
certain
ideas
so
that
that
gets
prioritized
to
implement
so
getting
that
transparency
and
visibility.
A
A
What
perspectives
can
you
share
about
consuming
and
contributing
as
well,
because
I
guess
they're
two
ends
of
that
inner
Source
way
of
working,
let's
say
and
maybe
sometimes
people
think
they're
going
to
get
a
free
lunch,
suddenly
they're
going
to
get
lots
of
contributions
coming
in
but
I
guess
it's
about
balance.
Isn't
it.
D
Yes,
I
think
it
is
definitely
a
balance
wherever
we
see
a
strong
sense
of
urgency
or
need
for
a
specific
component
that
could
be
reusable
for
any
product.
For
example,
somebody
is
developing
a
web
application
and
they
need
role-based
access
control.
How
do
we
Implement
that,
if
we
have
a
reusable
component
already
developed
as
a
part
of
inner
Source?
This
is
where
making
that
available
to
the
community
and
they
adopting
that
component
and
adding
back
if
they
find
any
issues
in
that
right.
D
Enhancing
that
consumption
is
one
part,
then,
if
they
would
like
to
contribute
back
and
through
the
enhancements
or
even
logging,
an
issue
against
it.
If
something
is
not
working,
locking
an
issue
against
it
is
also
considered
as
a
as
a
contribution
back.
So
when
you
have
multiple
developers
contributing
back
from
all
different
time
zones
and
organizations,
then
the
quality
of
that
product,
our
solution
gets
eventually
better.
A
Love
that
love
that
and
I
love
the
point
you
made
there
that
an
issue
is
a
contribution
as
well.
I
think
that's
one
of
the
so
so
common
points
that
I
have
to
make.
Is
that
it's
not
all
about
code?
You
know
we
can
create
an
issue,
because
maybe
the
project
team
that
we're
working
with
they
haven't
thought
about
something
on
their
roadmap
and
by
raising
that
issue,
you're,
actually
making
them
think
about
a
different
problem,
but
their
project
could
solve,
and
then
it
creates
this
constructive
discussion
around.
A
Should
we
include
this
in
our
project?
Should
we
not
and
it's
absolutely
fine
if
they
decide,
you
know
what
we're
not
going
to
include
it
in
the
project,
because
it's
enabled
that
discussion
and
that
collaboration
as
opposed
to
that
kind
of
closed
world
where
teams
are
working
in
silos
and
they're
just
duplicating
without
even
knowing
they're
duplicating
so
it
starts
bringing
the
community
together.
So
thank
you
for
sharing
that
example.
Love
that
I
love
that
Zoe,
how
about
yourself
in
terms
of
partnering
with
the
developer
Community?
What
are
you
seeing
there.
B
B
Now
we
set
up,
at
least
in
the
beginning
already
for
the
cloud
platform,
special
interest
groups
and,
in
short,
six
and
those
six
had
certain
topics,
for
example,
automation,
security
architecture
and
people
from
the
developer
Community,
who
join
those
open
meetings.
So
those
sick
meetings
are
open,
Agenda
is
published
and
you
are
free
to
join
if
you're
interested
in
that
topic,
and
that's
of
course
had
to
start.
B
We
needed
some
time
until
those
were
known
in
the
community,
a
few
to
people
that
are
there's
really
good
marketing
for
us
within
the
business
for
to
to
reach
the
right
people
and
that's
how
we
work
together
as
a
the
core
team
that
works
on
the
cloud
platform
with
our
business
and
the
people
that
we
really
want
to
contribute
on
the
projects
by
Inner
sorting.
So
that's
that
works
quite
good
for
us.
A
Awesome
well,
thank
you
for
sharing.
It's
been
interesting
watching
the
poll
results
again,
whilst
we've
been
chatting
again
here,
quite
a
mix
of
how
people
are
actually
improving
the
quality
of
their
code
and
the
steps
they're
taking
so
about
30
of
people
are
still
seeing
manual
views
so
I
guess.
Pull
requests
is
a
key
part
of
that
about
28
with
automated
builds
and
tests,
not
as
much
on
the
security
checks.
A
Obviously,
this
balance
between
empowering
your
developer
community
being
able
to
make
them
be
productive,
being
able
to
make
them
ship
faster,
do
more
and
and
build
up
those
kind
of
standardized
patterns
and
practices
versus
guard
rails,
in
maybe
some
of
those
more
regulated
or
traditional
organizations
where
they
need
to
ensure
compliance
or
ensure
certain
things
are
done
in
a
certain
way.
Let's
say
how:
how
do
you
balance
that
inside
your
organization,
so
maybe
Sharon?
Let's
start
with
yourself:
I
can
imagine
that's
something
top
of
mind
for
you.
D
Yes,
I
think
they
definitely
need
to
be
a
balance
between
empowerment
and
putting
some
guard
rights
because
end
of
the
day,
the
solution
that
you
develop
gets
deployed
to
protection
and
it
will
impact
hundreds
and
thousands
of
end
users
right
so
in
terms
of
empowerment,
bringing
the
developer
Community
together
and
providing
them
the
right
Integrations
to
integrate
code,
quality
and
security
check
within
their
unmandating
that,
as
a
part
of
their
full
request,
every
every
time
anybody
tries
to
raise
a
pull
request.
It
must
pass
these
validation
checks.
Maybe
you
are
doing
so.
D
One
one
another
example
between
the
empowerment
and
Guardians
is:
let's
say
you
have
the
repo.
The
guard
rail
here
would
be.
How
do
we
protect
our
default
branches?
How
do
we
protect
these
repo
by
not
having
everybody
as
admin
to
this
repo
right?
So
those
are
the
guardrails
that
are
required
for
the
sanity
of
your
source
code
and
your
application,
but
from
the
empowerment
perspective
right,
how
quickly
can
I
get
access
to
this?
D
A
For
sure
it's
whilst
you've
been
talking
about
that
one
we've
had
a
poll
going
in
the
background
about
whether
folks
are
using
Branch
protection
rules,
which
I
think
is
just
well
one
of
those
really
easy
ways
to
bring
in
some
of
that.
Some
of
those
guardrails,
you
know,
has
someone
else
reviewed
that
code
before
it's
merged
into
your
main
branch.
A
Have
you
got
those
automated
checks
and
balances
in
place,
reassuring
to
see
a
lot
of
people
are
there's
still
some
who
are
not
so
maybe
that's
an
opportunity
after
the
session
to
go
and
explore
Branch
protection
rules,
try
them
out
and
start
using
them
in
your
organization
here
as
well
super.
So
then,
if
we
think
about
I
suppose
these
empowerment
versus
guardrails
discussion
continuing
on
here
Adrian
from
your
perspective,
I've
seen
some
chats
about
GitHub
actions
as
well
in
in
the
chat
here
as
well.
C
C
Yeah,
so
when
you
were
saying
earlier
that,
like
I'm,
hiring
in
government,
Governors
is
kind
of
conflicting
I.
Don't
think
it
always
is,
at
least
as
empowering
is
like
in
the
sense
of
kind
of
allowing
your
your
team
to
kind
of
write,
better
code
and
be
more
productive,
and
that's
because
these
Gardens
Governors
is
kind
of
forcing
you
to
fit
to
a
certain
mode.
C
This
kind
of
standardization,
and
if
you
use
kind
of
standardized
tooling
throughout
your
through
your
organization
or
you
encapsulate
this
knowledge
on
how
to
be
compliant,
and
you
allow
other
teams
to
reuse
that,
then
you
can
both
give
them
this
Improvement
and
productivity
and,
at
the
same
time,
kind
of
get
compliance
and
I
think
get
up.
Actions
with
these,
like
reusable
GitHub
workflows,
actually
fits
that
very
well.
C
A
And
I
guess
really
really
valid
points
and
thank
you
for
picking
up
on
what
I
said.
I
guess
it's
about!
Maybe
rethinking
how
we
think
about
compliance
and
governance.
Isn't
it
I
think
it's
a
bit
like
security?
Sometimes
it's
often
thought
maybe
in
the
projects
I've
been
involved
in
at
least
maybe
this
is
showing
maybe
some
of
the
scenarios
I've
worked
in,
but
it's
often
thought
as
a
almost
a
check
box
or
an
exercise
that
happens.
A
Maybe
just
once
before
you
go
to
production,
maybe
just
once
before
you
have
to
go
that
initial
go
live
and
then
you've
done
it
and
everything's
fine.
But
when
you
can
start
automating
things
in
that
way
and
bring
them
as
checks
into
your
life
cycle
from
a
development
perspective,
bring
those
compliance
checks,
bring
those
quality
checks,
bring
those
just
standards,
whether
the
code
builds
testing,
etc,
etc.
When
it
starts
becoming
part
of
the
life
cycle,
it
becomes
repeatable
and
it
becomes
less.
C
As
long
as
there's,
not
all
the
teams
have
to
solve
how
to
how
to
get
a
checkbox
detect
every
time,
then
you
kind
of
see
the
upside.
If
everything,
if
you
see
compliance
that
there's
something
every
team
need
to
deal
with
themselves,
then
it's
gonna
be
hugeable
like
and
then
indeed
it
will
kind
of
conflict.
A
B
We
always
try
to
think
of
how
we
can
better
yeah
guards
our
goats
and
what's
being
employed,
but
also
make
it
user
friendly.
So
that
is
the
the
the
most
important
part
I
think
in
inviting
people
to
contribute,
but
also
have
those
guardrails
up
and
the
way
that
we
try
to
make
it
most
user
friendly
is
to
have
it
all
automated.
B
Also,
what
I
said
in
the
beginning
of
this
talk
is
that
everybody
in
our
organization
is
reader
on
all
repositories
and
everybody
can
join
those
special
interest
groups,
but
you
are
not
automatically
a
writer
on
those
repositories.
So
if
you
are
in
those
special
interest
groups,
you
get
right
permissions
on
those
pieces
of
of
codes
of
and
via
that
way,
we
give
the
the
yeah.
A
And
that's
such
an
important
word
there
Trust
and
it
inner
Source
fundamentally
relies
upon
this.
Doesn't
it
is
that
you
all
trust
each
other
in
this
community
and
again
bringing
it
back
to
it's,
not
just
about
the
tooling,
even
though
we've
kind
of
hinted
at
it
a
lot
in
the
session
there's
this
cultural
transformation
that
happens
alongside
as
well.
All
of
this
that
we're
talking
about
here,
one
thing:
I'd
love
to
just
pull
out
as
well,
and
we
can
do
maybe
a
quick,
yes
or
no
and
in
the
chat
as
well.
A
D
D
A
Gotcha
gotcha,
it's
interesting
reading
the
chat
as
well
quite
a
few
yeses.
Some
knows
so
again:
Branch
protection
rules,
code
owners,
great
ways
of
being
able
to
bring
that
those
checks
and
balances
along
the
way.
So
if
there
are
certain
parts
of
the
code
where
maybe
they're
a
little
bit
more
sensitive
or
you
need
certain
teams
to
review
it
for
whatever
reason,
a
great
way
to
to
enforce
that
as
part
of
what
you're
doing
then
good,
so
I'm
conscious
that
we're
very
much
coming
up
to
the
end
of
our
time.
A
A
D
Yeah
I
think
if
we
would
have
done
it
little
bit
differently,
we
would
have
much
more
focused
on
establishing
the
developer
Community
right,
where
we
will
be
able
to
share
all
these
migration
tools.
You
want
to
migrate
from
multiple
version
controls
back
to
GitHub.
How
do
you
do
that
efficiently?
Drive
that
Automation
in
terms
of
migration
of
your
source
code
and
Integrations,
to
GitHub
and
and
also
ability
to
communicate
better
with
your
practitioner
communities
with
constant
trainings
with
constant
upskilling
that
is
required.
D
Not
everybody
is
in
the
same
pace
so
that
upskilling
and
training
aspect
is
very
important
and
also
recognize
the
subject
matter.
Experts
in
your
organization
who
are
willing
to
go
above
and
beyond
to
come
and
share
their
experience
and
learnings.
There
could
be
some
tricks
and
tips
and
tricks
that
they
implemented
for
theirs.
B
Yes,
I'm
I
was
thinking
during
Sharon's
talk.
What
what
my
wish
was,
what
that
we
had
done
sooner
and
I
would
I
would
say
coming
back
to
what
Sharon
also
mentions
about
recognizing
your
smes,
even
though,
as
a
team
within
the
organization,
you
are
the
codes
owners
and
in
the
end
responsible
for
that
code,
recognize
somebody
from
a
whole
different
team
that
is
really
interested
and
really
wanting
to
contribute.
B
It
took
a
quite
some
time
to
to
have
that
trust
in
in
those
people,
and
that
is
a
learning
curve,
of
course,
but
knowing
that
now
now
that
we
are
well
underway
already,
I
would
say
have
that
trust,
just
repeating
what?
Basically
we
already
already
said,
and
also
that
you
don't
have
to
be
afraid
to
fail.
So
don't
try
and
think
everything
out
on
forehand
and
try
to
make
the
best
way
of
working.
A
I
love
that
I
think
I
preface
the
session
with
this
idea
of
the
cloud
world
we
live
in
being
always
on
expectations
and
I.
Think
that's
one
of
the
things
from
a
cloud
perspective.
We
expect
infrastructure
to
fail
because
that's
kind
of
nature
of
cloud
and
it's
important
when
we
think
about
this
cultural
Journey,
we're
going
on
failure
is
going
to
happen.
We're
making
some
big
changes
here,
comparing
to
how
it
works
in
the
past
and
actually
at
GitHub.
A
We
have
a
principle
that
we
work
by,
which
is
ship
to
learn,
and
this
idea
that
you
know
it
might
not
be
perfect,
but
it's
an
enhancement.
It's
a
change,
it's
something
that
we're
growing
and
improving
over
time,
so
absolutely
that
ship
to
learn,
mentality
and
that
idea
of
being
able
to
continually
grow.
C
A
A
Awesome
and
I
think
if
I
encapsulate
some
of
my
thoughts
here,
what
I've
been
talking
about
as
well.
The
inner
Source
Journey
has
been
a
theme
I
think,
even
though
we've
been
talking
about
quality
has
really
been
a
theme
that
has
threaded
throughout
all
of
the
discussion
and
through
the
examples
from
from
everyone
here
and
I.
Think
what's
been
really
interesting
is
hearing
just
how
broadly
you're
using
gitter.
You
know
it's
not
just
the
Version
Control.
A
It's
not
just
we're
using
actions
here
and
we're
doing
this,
and
this
and
this
you're
using
it
as
this
end-to-end
platform
to
help
you
bring
security
into
that
life
cycle.
To
help
you
be
more
productive
to
bring
that
collaboration
amongst
your
teams
with
that
inner
Source
platform.
So
hearing
that
ends
to
end
the
platform.
A
A
A
community
so
really
really
awesome
session
I've
really
enjoyed
it.
Thank
you
very
much.
Everyone
for
joining
us
here,
just
as
you
can
see
on
screen
here,
is
our
final
closing
poll.
We've
got
how
folks
are
governing
CI
CD
adoption
across
their
organization,
interesting
to
see
the
love
for
reusable
workflows.
That's
the
highest
one.
They're
voted
for,
and
still
a
lot
of
room
to.
A
So
definitely
one
to
look
at
and
passwordless
deployments
I
gave
it
biased,
I
wrote
a
blog
post
in
January
about
that
which
I
think
is
awesome,
so
you
should
definitely
all
go
check
that
out,
but
again,
a
great
feature
to
help
reduce
Toil
and
things
like
that
and
again
just
allow
the
community
to
focus
on
what's
important
rather
than
the
operational
overhead
of
things
delivering
value
to
the
end
users.
So
really.
C
A
Interesting
insights
throughout
the
session
there
so
folks,
thank
you
so
much
for
joining
I
I
think
I'll
move
us
on
now
to
closing
thoughts.
What's
coming
up
for
the
rest
of
Galaxy
so
again
panel.
Thank
you
for
joining
and
feel
free
to
jump
backstage
if
you'd,
rather,
thank
you
good,
so
folks
we're
coming
to
the
end
of
our
time
here,
so
just
to
make
sure
you're
aware
of
everything
that
is
coming
up
in
terms
of
GitHub
Galaxy.
A
A
That's
going
to
be
awesome,
so
I
recommend
definitely
going
and
checking
that
one
out
later
today,
tomorrow
is
very
much
focused
on
security,
so
how
to
implement
native
security
patterns
that
deliver
customer
value
and
optimize
the
developer
experience,
and
then,
in
the
afternoon
tomorrow
how
a
global
community
of
security
researchers
can
help.
You
scale
your
security
team,
because
again,
security
is
one
of
these
things.
That
is
a
Cornerstone
of
what
we
do.
A
Thank
you
so
much
for
joining
us
just
as
a
reminder.
If
there
have
been
questions
in
the
chats
that
we
haven't
been
able
to
handle
during
the
discussion,
because
we've
had
a
very
full
on
session
here
and
please
use
the
button
at
the
top
of
the
screen
to
book
a
meeting
and
we'd
love
to
be
able
to
carry
on
that
discussion
further
with
you
and,
of
course
like
any
of
these
kind
of
events.
We'd
love
your
feedback.