►
From YouTube: Jenkins GSoC 2020 Retrospective - Part 1 (Sep 16, 2020)
Description
In 2020 the Jenkins project participated in Google Summer of Code 2020. This is the first retrospective meeting where we started reviewing and discussing feedback provided by GSoC participants. Public retrospective doc: https://docs.google.com/document/d/1NIszUtuXmHiu8X2WrgAEQFK6aVodsmM4I0RSNRf4TS0/edit?usp=sharing
A
Well,
if
you're
watching
this
recording
we're
doing
the
first
part
of
the
public
record
perspective
for
google
summer,
of
course,
2020.
just
clarify.
We
are
doing
public
retrospective
for
their
organization
for
projects.
We
recommend
all
teams
to
have
their
own
retrospectives
yeah.
We
know
that
many
things
have
already
done
that
and
this
feedback
is
most
likely
private,
but
yeah
for
organization
level.
We
rather
prefer
to
have
a
public
retrospective
for
that
we
have
sent
a
form
where
everyone
could
provide
feedback
and,
if
you
haven't
done
it
yet
please
do
so.
A
It
takes
well
maybe
10,
to
15
minutes,
and
it
will
be
much
appreciated
today.
The
plan
is
not
to
finish
the
phone,
but
just
to
go
through
feedback.
We
have
already
received
and
get
feedback
from
participants
of
this
call
and
mostly
to
discuss
what
would
be
improved
and
what
we
would
like
to
change
so.
A
B
Lecture,
so
I
think
what
I've
written
here.
So
if
you
see
the
last
the
highly
active
community
point,
that
is
what
I
wrote
as
a
feed
as
a
key
highlight
for
me.
So
one
of
the
first
impression
I
got
was,
which
is
which
was
very
important
for
me
personally,
is
that
money
is
not
the
driving
factor
for
someone
to
work
or
to
contribute
for
something
for
for
a
project
of
such
for
such
a
large
scale.
B
When,
when,
when
I
saw
the
amount
of
time
my
mentors
and
in
general,
the
jenkins
community,
the
people
they
they
give
within
this
community.
For
for
my
project,
the
technical
advice
I
was
being,
I
was
being
given
and
the
time
they've
been
provided.
I
I
that
personally
is
is
really
motivating
for
me
to
do
this
in
future,
because
I
I
I
personally
was
not
aware
of
how
open
source
community
works.
B
What
what
is
the
motivation
behind
a
person
to
contribute
in
an
open
source
project-
and
I
I
think
I've
learned
a
lot
in
terms
of
in
terms
of
the
reasons
why
someone
would
do
that,
and
I
think
that's
that's
a
great
thing.
That
was
a
great
thing.
For
me.
The
second
highlight
would
be
the
blogs
while
the
pro
while
I
was
doing
the
project
I
was
not.
I
did
not.
I
would
say
I
would
be
honest.
I
was
for
the
first
phase
of
the
second
phase.
I
was
not.
B
So
what
I
want
to
say
is
writing
a
blog
is
a
great
way
to
reflect
on
whatever
you've
done
in
each
phase
and
it's
a
great
way
for
for
other
people
to
understand
what
you've
done,
because
what
you're
dying
trying
to
do
through
writing.
That
blog
is
through
to
to
provide
an
abstract
concept
of
what
you've
done
throughout
that
phase
and
and
actually
that's
a
difficult
task
when
you,
when
you've,
been
trying
to
solve
a
complex
problem
and
you
and
you-
and
you
start
writing
a
blog,
it's
it's.
B
Actually,
it's
a
challenging
task
to
make
the
complex
concept
simple
enough,
so
that
people
who
do
not
have
maybe
more
than
a
minute
to
understand
what
you're
doing
and
be
impressed
about
what
you
may
be
impressed
enough
to
actually
look
and
use
what
you
want
to
provide
to
the
user.
So
I
think
it's
a
very
what
I
as
a
suggestion
for
my
it
was
a
suggestion
for
myself
and
I
think
for
the
future.
Students
is
that
they
should
not
start
writing
the
blog
before
maybe
two
or
three
days
at
the
deadline.
B
They
should
do
that
before
the
week.
The
mentor
should
get
a
draft
of
it;
they
should
review
it
first
and
it
should
be
as
important
as
the
coding
task,
although
it's
not
required
by
google.
It's
a
great.
I
think
it's
a
great
addition
by
the
jenkins
community,
but
it
should
be
it
should
the
weight
provided
to
the
to
that
task
should
be
equal
to
the
weight
we
provide
to
the
coding
tasks
in
each
phase
yeah.
I
think
that.
B
Okay,
biggest
challenge
for
me
was
to
actually
plan
how
to
so
in
my
project.
What
was
difficult
for
me
was
that
it
was
not
straightforward
coding
tasks
we
could
design.
It
was
not
just
designing
a
feature
and
then
delivering
it
to
production.
Before
that,
we
we
had
a
significant
amount
of
research.
We
had
to
do
to
understand
so
my
my
my
project
was
performance
improvements
in
git
plug-in
so
to
to
improve
performance.
B
We
first
needed
to
find
areas
where
we
could
improve
the
performance
so
now
doing
that
planning
for
the
the
whole
this
whole
project.
It
was
difficult
for
me
because
I
I
could
not
gauge
the
amount
of
time
it
would
take
for
me
to
research
or
to
you
know,
explore
time
I
would
take
in
the
exploration
to
find
an
area
within
the
gate
plugin
where
I
could
improve
the
performance.
So
I
would,
I
would
say
I
was
not.
B
Balancing
that
with
the
coding
tasks
was
a
difficult
aspect
for
me
within
the
project
and
then
the
second
thing
which
was
challenging
for
me,
was
to
take
the
code
from
my
personal
id
to
production.
I
did
not.
I
I
think
I
did
not
estimate
that
that
the
process
would
take
much
more
time,
especially
for
for
a
for
a
plug-in
which
is
used
by
which,
which
has
such
a
wide
audience.
That
is
planning
to
just
release.
A
single
feature
is
requires
much
more.
B
A
B
Yes,
actually
I,
when
I
was
whatever
I'm
saying,
I
was
saying
it
in
perspective
of
the
whole
in
general
g
soft
project,
not
because
of
course,
I
think
before.
While
writing
the
proposal
or
before
doing
the
project,
it
would
be
difficult
to
understand
how
much
time
it
would
take
for
a
student
to
write
a
code
and
to
take
it
to
production.
B
If
the
amount
of
time
it's
going
to
take
to
write
it
to
code
it
and
then
to
test
it
and
then
to
release
it
is,
is
considerable
so
count
that
time
when
you're
thinking
about
doing
ambitious,
maybe
thinking
about
doing
ambitious
features
or
it
just
it
just
would
be.
It
would
make
sure
that
the
proposal
or
the
after
the
proposal
planning
is
better.
B
A
C
A
D
A
D
A
D
A
A
A
A
E
E
I
think
those
things
just
helps
me
and
learn
the
whole
process
to
manage
a
software
during
its
life
circle
and
from
wooly.
I
just
learned
how
to
he
he
teach
me.
He
taught
me
many
tools,
I
studied
again
nss
tools
and
I
teach
and
taught
me
many
principles
how
to
build
a
robust
about
a
software
software
with
less
bug,
and
so
I
think
mentors.
F
E
E
It
would
be
helpful
for
the
green
hand
for
in
jenkins-
and
I
remember
when
I
when
I
was
first
jenkins-
I
read-
I-
I
get
get
to
know
those
things
from
some
youtubers
from
third-party
web
pages,
but
not
from
the
jenkins
official
of
official
site.
So
I
think
the
top
level
architecture
document,
or
even
just
some
object
graphs-
are
useful.
A
A
G
C
G
As
okay,
so
okay,
so
if
I
start
off
with
the
community,
I
think
you
know
one
of
the
biggest
highlights.
One
of
the
biggest
advantages
of
with
lincoln's
was,
I
think,
really
great
community,
so
that's
been
mentioned
before,
but
I
would
like
to
reiterate
that
their
mind.
The
team
I
got
you
know
with
respect
to
mentors
and
with
respect
to
even
other
contributors
who
were
helping
on
during
the
entire
course
of
the
project
was
it
was
awesome.
G
G
G
We
were
able
to
deliver
the
changes
that
we
had
proposed
to
the
community
on
time.
So
that
was
a
good
highlight,
I
think,
and
I
think
yeah
I
I
I
think
I
would
be
just
repeating
my
the
things
we
discussed
in
our
retrospective
meeting.
I
think
we
mentioned
everything
over
there
also
the
retrospective
we
had
for
our
project
so
yeah.
I
think
so
only
positive
things
from
my
side.
I
think
plus
one
on
everything
that
others
mentioned
so
yeah
yeah.
I
have.
G
We
also
had
we
had
a
hackfest
that
was
nice,
so
breakfast
was
awesome,
yeah
writing
getting
to
right
so
yeah.
So
I
think
with
the
blogs
that
richard
mentioned
it
it
actually,
I
think,
in
the
future.
Also
now
I
have
something
you
know
solid,
that
I
can
go
back
to
and
see
what
my
thought
process
was
back
then
and
have
something
for
myself.
So
those
blogs
are
amazing
for
the
community
also
for
me
also
personally
and
so
blogs
also
and
those
videos
that
we
made
during
our
presentations.
G
So
so
that
was
really
nice.
I
think
that
we
did
and
that
you
know
they,
so
the
all
guidance
decided
to
take
forward.
So
that
was
really
nice.
I
think
even
gsoc
officers
are
being
held,
so
I
think
I
attended
a
few
of
them,
but
that
was
really
nice
to
you
know
see
if
anything
was
going
wrong
or
something
so
you
know
I
knew
that
there
was
a
gso
office
hours
happening
every
week,
so
that
is
also
nice.
G
A
G
A
A
G
So
I
mean,
I
think
so
I
don't
think
that's
yeah.
I
I
don't
think
that's
a
wrong
thing.
I
mean
I
mean,
of
course
we
should
go
ahead.
I
mean
it
was
something
that
was
required
and
I
think
we
should
keep
doing.
I
think
yes,
definitely
we
should
architecture
focus
projects.
Yes,
so
so
so
do
you
mean
like
changes
to
jenkins
core?
So
that's
what
you
had
in
mind.
A
So
there
is
a
case
when
a
project
has
significant
community
value,
especially
strategically
like
changing
architecture,
but
at
the
same
time
it
is
most
likely
to
have
challenges
during
adoption
and
during
the
feedback
cycle
during
the
project.
So
basically,
for
example,
casual
was
working
on
github
checks
and
they
were
able
to
facilitate
feedback
really
quickly,
but
an
external
fingerprint
storage.
It
was
quite
opposite
mostly
due
to
the
project.
Specifics,
though,
it
also
has
a
quite
high
community
value.
G
I
think
so
so
so
the
two
things
you
mentioned
first
was
changes
architecturally.
I
think
that
is
a
good
thing,
because
that
gets
people
to
understand
jenkins
core
as
well.
So
so
I
think
we
know
that
you
know
getting
contributors.
There
also
is
one
of
the
challenges,
so
I
think
that
is
a
good
thing.
As
far
as
adoption,
at
least
my
understanding
is
it's,
it
may
be
a
bit
hard
to
predict
it
beforehand.
A
Well,
in
some
cases,
it's
possible
to
predict
that
adoption
will
be
relatively
low
right
right
because
yeah
there
are
deliverables
which
can
be
shipped
to
users
quickly
and
which
can
generate
a
lot
of
excitement
like
resolving
a
particular
problem.
They
providing
integration
for
machine
learning
or
github
checks
and
which
are
user
facing
there
might
be
features
which
have
which
face
administrators,
for
example,
windows,
services
and
there
might
be
features
which
actually
focus
on
architecture,
and
it
will
take
a
while
until
it
gets
to
users.
A
So,
for
example,
yeah
we
created
external
fingerprint
storage,
assuming
that
somebody
creates
a
plugin
which
heavily
relies
on
traceability
and
observability
of
items
in
jenkins.
It
will
be
really
useful
to
our
users,
but
it
will
take
a
while
until
it
gets
to
users,
it's
not
something
which
can
happen
in
three
months
yeah.
All
of
that
is
still
valid
types
of
the
project.
So
for
me,
I
rather
self
question
whether
such
kind
of
project
is
ideal
for
gsoc.
D
A
D
This
I'm
not
sure
who
provided
this
feedback,
so
that
was
that
was
one
from
rashad
from
me.
I
I
think
I'm
the
one
who
actually
wrote
the
text,
but
we
needed
to
rishov,
had
to
change
git
client
and
get
plug-in
both
under
control
of
the
mentors,
but
also
needed
to
submit
pull
requests
to
the
github
branch
source,
the
gitlab
branch
source
and
and
that
that
was
a
a
complexity
we
could
have
predicted
from
the
beginning.
Had
we
thought
about
it,
but
we
just
didn't
think
enough
about
it,
and
so
it
was
a
oh
yeah.
D
A
It
happens
quite
often,
so
sometimes
we
can
call
it
collateral
benefit.
So,
for
example,
if
we
change
something-
and
we
see
an
opportunity
to
improve
something
nearby,
for
example
submitting
capacity
to
upstream
library
or
upstream
component
or
the
drinkers
core-
it's
definitely
an
advantage.
So
sometimes
it
complicates
deliverables.
A
D
Right
and-
and
I
think
that
that
is
a
good
one
that
would
have
been
fit
well
into
community
bonding
if
we'd,
if
we
thought
more
carefully
about
oh,
this
is
going
to
happen
this
way,
and
this
way
in
this
way
had
we
done
a
better
job
of
predicting
the
future.
We
probably
would
have
had
a
better
experience
on
actually
arriving
at
the
future.
A
G
G
Page
live
for
the
next
year,
so
by
I
think,
november
or
december
jenkins
had
a
piece
of
2020
ideas
page,
and
I
could
just
google
this-
that
gsoc
2020
ideas,
page
and
so
jenkin
was
the
top
result
there.
So
so,
if
I
wanted
to
start
something
early
so
that
that
that
opportunity,
I
had
with
jenkins
that
I
did
not
have
with
you
know
so.
Other
communities
that
maybe
get
their
project
ideas
later,
so
so
that
quick
that
opportunity
for
me
to
start
early
was
that
that
idea
page
gave.
D
I
think
that's
ingenious
to
consider,
for
instance,
if
I
were
to
offer
get
plug-in
improvement
ideas
as
part
of
hacktoberfest
and
start
touting
them
on
on
social
media.
You
want
to
try
google
summer
of
code.
Here's
your
test
drive,
I
think
that's!
I
don't
know
that
anybody
would
be
interested,
but
I
think
it's
an
inter
it's
an
intriguing
idea
to
to
promote
more
actively.
Hey.
Here
are
some
ideas
that
we
might
pick
for.
Google
summer
of
code
oktoberfest
your
chance.
G
A
G
G
Just
just
one
last
point
and
what
did
go
well,
even
the
gsoc
office
hours
I
think
that
were
held.
You
know
I
those
were
happening
since
january
or
something
so
that
helped
you
know
in
community
bonding.
So
you
know
you
can
join
those
meetings
and
you
can
actually
ask
your
questions
verbally.
If
that
also
helps
right,
so
that
that
is
also
awesome.
A
A
A
B
A
Yes,
on
the
mentor
side,
I
would
say
that
a
activity
of
students
also
was,
let's
say,
one
of
the
most
important
inputs
for
us
when
making
decisions,
because
yeah
for
all
applications
we're
actually
able
to
do
educative
choices
of
what
application.
We
would
like
to
accept
yeah
a
lot
of
these
additional
information
we
collected
through
applications,
so
basically
our
whole
projects.
We
had
clear
expectation
about
what
would
be.
A
Of
chances
of
success
and
also
of
additional
challenges
which
might
need
to
be
addressed
during
community
management
later
it
was
mostly
unvisible
to
students,
but
as
mentors
and
as
always.
Actually
there
was
a
lot
of
discussions
about
that
so
far,
it's
actually
application
phase
and
yeah
all
these
new
family-friendly
issues,
office,
hours,
etc.
A
E
I
think
that's
as
that
could
be
a
a
real
big
reason
for
the
students
why
they
choose
jenkins
instead
of
some
other
projects,
and
so
I
think
we
should
keep
keep
going
on
there
and
providing
the
project
ideas
early
for
it.
With
details
already
for
the
students-
and
the
second
highlight
about
the
application
phase
is,
I
is
that
woody
I
just
provided
his
shared
his
development
environment
for
me
and
he
just
shared
it
on
github.
A
I
wouldn't
say
that
these
guidelines
feel
extensive
enough
for
any
of
the
projects
and
it's
something
we
definitely
need
to
study.
But
in
principle,
when
we
were
moving
the
project
idea
to
the
published
state,
we
will
require
a
quick
start
guide
and
also
we
cannot
find
the
issues
to
be
present
just
commented
to
some
extent
so
yeah.
We
definitely
should
keep
doing
that.
A
A
B
I
think
from
my
side,
particularly
from
my
project,
whatever
the
challenges
I
faced,
those
could
have
been
personally
I
could
have
been
initiated
or
from
well
in
general
from
our
team.
I
think
the
challenges
of
planning
could
have
been
solved
within
the
community
bonding.
We
were
more
focused
towards
actually
doing
the
project.
We
were
more
focused
towards
performance,
benchmarking
and
eliminating
the
finding
results
we
could
actually
use,
but
we
should
have
first
before
that.
B
We
should
have
made
sure
that
we
need
a
concrete
plan
for
the
three
months,
and
I
remember
that
one
of
the
mentors
parishes
who
was
who
did
g-shock
2019,
he
did
suggest
me
to
write
a
design
document
and
I
was,
and
when
I
started
to
write
a
design
document
I
was
actually
I
was.
I
was
finding
it
difficult
to
write
it
because
for
my
project
I
was
not
sure
in
terms
of
code
in
terms
of
design
what
I
would
design
before.
B
Even
I
I
needed
to
find
performance
improvements
first
and
then
I
would
design
a
way
to
inculcate
those
improvements
within
the
plugin.
So
that
was
like
a
step
two
for
my
project,
but
at
that
time
to
forecast
the
whole
design
was
I
I
could
not
do
that,
and
I
remember
that
I
did
not
publish
a
design
document
within
that
phase,
which
I
did
not
like
personally,
but
I
was.
I
was
confused.
How
I
I
can
do
it,
I
did.
B
B
I
I'm
actually
not
sure
I
am
not
sure
if
this
was
a
problem
from
if
there's
something
which
can
be
done
in
terms
of
maybe
maybe
submitting
a
design
document
by
the
end
of
by
the
end
of
the
community
say,
bonding
phase
could
be
like
I'm
not
sure.
I'm
actually
not
sure
this
would
me
being
pushing
to
provide
an
improvement.
I
think
it
was
more
of
an
issue
within
within
our
team
or
with
myself
rather
than
the
jenkins,
like
the
whole
g-soft
project.
D
D
It
would
have
shifted
the
work
though,
and
that
that
would
have
had
a
cost
right.
We
would
have
done
some
of
the
benchmarking
later
in
favor
of
doing
the
design
earlier
a
document
earlier.
That
was
expressing
something
we
didn't
yet
know
and
but
but
that's
something
I
think
the
mentors
might
be
encouraged
to
to
be
sure
that
you
have
a
a
detailed
design
discussions
and
the
result
probably
should
be
a
design
doc.
A
We
expect
to
see
at
least
forecast
vision,
whatever
are
well
too
granularity
which
would
be
possible
at
this
stage,
because
again
you
don't
need
a
design
dog
just
for
the
design
dock.
The
whole
objective
of
that
is
to
actually
help
the
team
to
do
that
and
to
ensure
that
they
can
iterate
when
the
coding
phase
starts.
D
Yeah,
I'm
I'm
fine
with
whatever
phrasing,
because
the
the
goal
was
to
understand
the
kinds
of
things
we
would
be
doing,
and
I
think
we
didn't
do
as
good
a
job
in
that
in
that
community
bonding.
We
had
really
good
good
interactions
and
we
had
really
great
results,
but
it
wasn't
as
focused
on
the
plan.
I
think,
as
it
was
on
getting
started
on
the
results.
F
B
G
I
I
think
I
think
what
was
something
more
specific
to
your
project
was
so
so
you
had
to
do
some
research
and
then
your
entire
coding
was
so.
If
I'm
getting
it
correctly.
I'm
not
sure
so
correct
me
if
I'm
wrong
that
you
have
to
do
some
research
right
and
later
on,
your
entire
code
was
dependent
on
the
results
of
that
research.
So
so
I
think
yeah.
So
so
that's
it!
That's
a
tough
problem
in
itself.
G
Right,
I
mean
so
it's
just
something
that
hard
to
it's
hard
to
predict
for
you,
so
you're
really
dependent
on
the
research.
I
think
the
best
thing
that
maybe
you
can
do
is
build
a
flow
chart
or
something,
but
I'm
not
sure.
If
that's
a
so,
I
think
that's
a,
I
think,
that's
a
problem
with
the
project.
That's
heavily
research
focused
and
then
you
know,
so
I'm
not
sure
if
I
have
a
solution
for
that.
B
A
A
A
A
Well,
even
if
you
read
json
guidelines
in
our
project,
we
rather
prefer
to
do
it
more
continuous
but
yeah,
for
example,
even
if,
when
you
submit
evaluation
for
student,
basically
there
is
a
question
of:
has
the
code
been
merged,
then
you
can
answer?
Yes,
no,
but
there
is
even
no
notion
of
convenience
integration
there
or
whatever
iterations.
There
is
no
way
to
specify,
let's
say
fifty
percent
first
or
whatever,
and
yeah
maybe
comes
from
that.
A
A
Myself
and
yeah,
we
are
going
cover
time
so
again,
yeah
retrospective
is
a
bit
tedious
task
and
yeah.
Our
main
objective
is
to
collect
feedback
so
asymptomatically,
if
you
submit
feedback
for
other
phrases,
for
example,
just
proposing
changes
in
this
google
doc,
because
I'm
meeting
feedback
form
would
be
much
appreciated
and
the
oracle
means
we'll
be
working
on
merging
everything
into
a
single
document,
and
then
you
will
keep
working
on
action
items.