►
Description
Colin Dean, a software engineer with IBM Watson, discusses the benefits and challenges of Code Review within organizations. Code Review is not a new concept, but a specific term for an older concept -- Peer Review -- that focuses the review process on the code under examination instead of the person who submitted it. While Code Review is common in open source projects, organizations developing in private often employ inefficient, frustrating, or virtually non-existent review processes.
This talk looks at Code Review from an architect's viewpoint, arguing that Code Review is an essential component in a product's architectural plan because of the quality attributes it may provide. It also covers tips and sets expectations for what Code Review can and cannot solve.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
Hi
I'm
Colin
Dean
and
today
I'm
going
to
talk
to
you
about
code,
review
and
architecture.
This
is
me
I
like
to
engineer
quality
software
and
build
events
and
organizations
that
help
others
build
quality.
Software.
Of
course,
I
have
to
say
this
that
my
words
are
my
own,
not
of
any
my
employers
and
also
please
save
your
questions
to
the
end
of
the
presentation.
A
Here's
an
agenda
for
the
things
I'm
going
to
cover.
Tell
you
a
quick
anecdote
about
myself.
Will
define
code
review
talk
about
some
of
the
problems
that
code
review
solves
some
of
the
quality
attributes,
the
architectural
quality
attributes?
The
code
review
ensures
talk
about
some
good
tips,
that
I
have
for
doing
code
reviews
and,
of
course,
some
limitations
of
code
reviews
I.
A
First
experience
with
getting
my
work
reviewed
was
as
a
member
of
the
student
newspaper
in
college.
First,
as
a
copy
editor
and
later
as
a
layout,
editor
and
eventually
rose
to
become
the
editor-in-chief
of
the
newspaper
for
two
years.
This
was
despite
being
a
computer
science,
major
in
a
sea
of
English
majors
in
a
primarily
English
college,
for
about
three
and
a
half
years.
A
I
read
everything
that
was
fit
to
print
and
a
whole
lot
that
wasn't
even
as
the
editor
writing
my
own
weekly
column,
nothing
that
I
wrote
went
into
the
newspaper
without
at
least
one
other
person
generally
three
other
people
reviewing
it
for
grammar,
spelling
and
well
am
I
actually
making
sense?
No
one
was
exempt
from
the
dreaded
red
pen
or
in
these
modern
times
the
record
changes
feature.
A
A
Sometimes,
though,
in
layout,
we
would
use
X's
to
mark
that
something
was
necessary
to
be
fixed
generally
as
a
headline
we
didn't
want
to
think
of
a
headline
that
might
be
missed.
So
is
easier
to
just
put
some
X's
one
time.
I
violated
that
rule
and
my
pre-press
operator
calls
me
up
and
she
says:
hey
take
a
look
at
the
headline
on
a
eight
you'll
see.
It
says
something
like
what
the
is
this.
It
was
a
picture
of
a
piece
of
pizza.
A
A
Wikipedias
definition
is
a
little
more
succinct.
Wikipedia
says:
code
review
is
the
systematic
examination
of
computer
source
code.
This
definition
allows
for
some
broader
techniques.
Then
I
myself
prepared
to
care
to
participate
in,
but
the
similarity
in
our
two
approaches
is
bolded.
The
act
is
an
examination
and
the
examination
must
be
systematic.
A
You
may
be
familiar
with
the
term
peer
review
and
asking
yourself:
aren't
peer
review
and
code
review
the
same?
Well
yes,
but
I
dislike,
calling
them
peer
reviews,
as
we
girls
and
some
of
the
other
authors
on
code
review
peer
review.
Do
because
it
puts
too
much
focus
on
the
pier
that
is
being
reviewed
and
not
enough
focus
on
the
code
by
specifying
in
our
nomenclature
that
we're
reviewing
code.
We
very
specifically
say
we
care
about
the
code,
not
about
the
person
we're
reviewing
the
code
and
talking
about
the
code,
not
talking
about
the
person.
A
Moreover,
everything
is
code.
These
days,
architecture
and
design
documents
can
be
expressed
in
code.
You
do
use
some
kind
of
configuration
management
software
like
chef
or
puppet
in
your
environments
right
well.
Those
are
infrastructure
is
code.
One
problem,
typo
somewhere
in
there
could
be
an
almost
immediate
tenfold
cost
increase
throughout
this
presentation.
I'll
use
these
five
words:
change,
submission,
submitter,
reviewer
and
annotation.
These
are
probably
a
little
bit
more
easily
expressed
in
context.
A
A
My
concept
of
code
review
and
my
team's
practice
of
code
review
falls
somewhere
between
team
review
and
pair
programming.
We
will,
from
time
to
time
allow
our
pairs
to
review
their
own
changes
at
their
own
discretion.
However,
our
general
rule
is,
if
you
wrote
it,
you
shouldn't
review
it.
The
biggest
difference
from
wiegers
description
is
that
we
don't
have
formal
meetings
at
the
end
of
our
spectrum.
A
Our
engineering
teams
at
IBM
Watson
have
found
them
to
be
inefficient
at
best
and
excruciating
Lee
painful
at
worst.
Rather,
code
reviews
are
conducted
at
the
reviewers
leisure
asynchronously,
but
not
ad
hoc
I
like
to
do
them
in
the
morning
personally,
because
it
gets
me
reading
other
people's
code
and
gets
my
brain
going
before
I
go
out
and
write
some
of
my
own
I.
A
Would
say
how
many
of
you
are
familiar
with
github,
but
assuming
since
you're
here
probably
are
pretty
familiar
with
github.
We
use
github
internally
for
our
source.
Many
of
our
newer
projects
and
get
ups
pull
request
system
is
a
pretty
stellar
example
of
a
good
code
review
system,
pretty
eager
to
try
out
the
new
review
system
that
was
announced
yesterday
whenever
that
gets
integrated
into
github
enterprise.
A
So
next,
let's
talk
about
some
of
the
problems
that
code
review
solves
it's
pretty
clear
that
the
primary
go.
The
primary
goal
of
code
review
is
to
find
defects
before
they
enter
the
maintained
code
base.
However,
there
are
two
human
problems
that
code
review.
Also
solves
code
review,
solves
mental
model.
Synchronization
you've
got
five
people
on
your
team.
Are
you
certain
that
they
all
have
a
pretty
good
concept
of
where
the
architecture
is
going?
What
they're
supposed
to
be
doing
in
the
long
term?
A
Probably
not?
Hopefully
they
are,
they
are
similar
code
review,
reduces
the
feedback
cycle
so
that
people
can
keep
their
mental
model
in
synchronization
with
the
architecture
and
the
implementation,
even
as
it
changes,
and
it
should
change
over
time
with
that
in
mind,
they're
best
equipped
to
mindful
e,
implement
the
architecture
and
provide
feedback
on
its
design,
as
well
as
the
document
it.
But
what,
if
somebody
has
a
different
idea
entirely
one
that's
so
worth
exploring
that
it
could
change
the
architecture.
A
This
has
happened
frequently
on
my
team
over
the
last
several
months,
where
discussions
on
individual
lines
of
code
ended
up
turning
into
new
issues,
new
poor
quest,
new
features
and
new
architecture
changes
code
review
is
an
excellent
way
to
develop
and
keep
a
live
tribal
knowledge.
Tribal
knowledge
is
the
sum
of
stories
of
what
was
try.
What
was
failed,
what
succeeded,
how
best
to
handle
certain
problems
that
are
commonly
faced
and
to
define
a
certain
sense
of
how
things
came
to
be
this
way.
A
Code
review
also
thus
enables
architects,
because
then
the
developers
and
any
architects
who
aren't
writing
code
can
continuously
review
changes
to
the
architecture
and
the
implementation
and
have
that
same
audit
trail
with
the
logic
and
discussion
behind
all
of
those
changes
as
well,
because
developers
are
included
in
this
conversation
or
can
be
included.
In
this
conversation,
the
architecture
documents
should
live
in
the
same
repository
as
the
code.
The
architecture
describes.
A
A
Let's
talk
about
three
specific
quality
attributes
that
code
review
ensures
if
you
value
these
quality
attributes
in
your
architecture,
and
you
should,
then
you
should
most
definitely
be
doing
code
reviews
when
authors,
the
original
authors
of
a
project
move
on
from
that
project,
who's
who's
going
to
care
for
it
is
it
going
to
live
in
abandonment?
Maybe
if
it's
inside
a
company,
probably
not
somebody
has
to
maintain
it.
People
are
not
forever.
They
move
on
to
other
projects.
They
leave
the
company,
they
win.
The
lottery
or
get
hit
by
bus.
A
Unfortunately,
neither
are
their
minds
forever.
I,
for
one
can
barely
remember
what
I
did
last
week,
let
alone
a
month
ago
or
a
year
ago,
it's
vital
than
an
architecture
maintains
an
architecture
of
values
maintainability.
So
let's
talk
about
that.
First
to
me,
value
maintainability
in
an
architecture
necessitates
that
the
engineers
right
maintainable
code
code
that
can
be
picked
up
easily
and
quickly
modified
by
new
developers.
It
also
needs
to
have
a
design
that
is
useful
and
understandable
for
non
developers,
architects,
executives,
etc.
Code
review
drives.
All
of
these.
A
A
This
project
shows
this
chart
shows
the
modalities
for
learning
in
a
reviewing
situation.
Pairing
is
great,
but
we
need
to
spend
just
as
much
time
reviewing
in
order
to
transfer
knowledge
to
the
next
generation
of
engineers.
We
need
to
read
solid
code
and
we
need
to
read
code
that
can
be
improved.
We
want
to
point
out
problems
to
solidify
problem
code,
but
we
also
need
to
have
our
misunderstandings.
Our
personal
type,
one
false
positive
errors
about
a
problem.
Those
errors
must
be
corrected
by
others
as
a
secondary
comment
to
say,
hey.
A
No,
this
is
actually
correct
that
helps
us
learn
in
the
process
Oh
in
that
next
generation.
That's
not
just
a
younger
engineer.
That's
fresh
out
of
school
coming
in
to
fill
in
for
you
it's
also
some
guy
taking
over
for
you
some
woman
taking
over
for
you.
Whenever
you
move
on
to
something
cooler,
it's
vital
to
ensures
that
the
developers
on
a
project
understand
the
architecture
and
the
implementation
decisions
alike.
Well,
they
may
not
be
involved
with
every
architectural
and
implementation
decision.
A
Code
review
enables
them
to
be
aware
of
changes
to
see
those
pull
requests
coming
in
in
their
inbox,
and
this
enables
them
to
ask
questions
as
the
project
and
the
architecture
evolve.
In
doing
so,
they
better
understand
that
architecture
and
then
implementation
and
are
better
equipped
to
to
understand
and
identify
the
undesirable,
as
well
as
the
entirely
desirable
changes
to
the
architecture
from
the
established
best
plan
and
best
practice.
A
This
builds
that
tribal
knowledge
right
for
passing
to
others,
including
to
that
executive,
who
was
going
to
grant
you
promotion
or
that
investor
who's
going
to
drop.
20
million
dollars
on
your
company
serviceability
focuses
on
the
ability
of
a
technical
support
team
to
provide
that
support
by
exposing
new
configuration,
hiding,
unnecessary
debugging
configuration
and
agreeing
on
use.
A
Lenz's
law
applies
here
from
the
cathedral
in
the
bazaar,
the
problems
are
more
likely
to
be
seen
if
more
people
looking
at
the
source
of
the
problem,
so
to
me,
code
review,
ensures
maintainability
by
encouraging
engineers
to
write
code
that
meets
a
consensus
agreement
on
maintainability
code
that
can
be
modified
quickly
code
that
can
be
easily
picked
up
by
new
developers
and
code.
That
is
easy
for
non
developers
to
understand
or
really
architecture.
It
is
easy
for
non
developers
to
understand
these
quality
attributes
are
all
intertwined
as
well.
Service
systems
that
are
serviceable
are
understandable.
A
My
first
programming
job
out
of
school
was
with
a
business-to-business
imprinting
company.
We
use
subversion.
It
was
pretty
cool
at
the
time.
Our
engineering
process
was
interesting,
though
then
I
say
interesting,
with
kind
of
a
negative
connotation
there.
It
was
largely
do
this
thing
now.
Go
do
another
thing
now.
Good
note
do
do
another
thing:
oh
and
don't
break
the
build,
but
we
didn't
really
have
a
reliable
build
system.
It
was
easy
to
switch
off.
I
didn't
have
to
deal
with
production
bugs
because
the
company
didn't
want
us
to
work
outside
of
regular
business
hours.
A
This
should
blow
your
mind,
blew
my
mind
to
the
rare
outages.
Were
the
responsibility,
the
sole
responsibility
of
the
sole
person
in
our
who
was
responsible
for
working
outside
hours,
our
tech
lead
because
he
wasn't
reviewing
any
code
any
time
there
was
an
outage.
It
took
him
hours
and
hours
to
resolve
it
because
he
would
end
up
having
to
look
through
the
change
history.
Look
through
the
code
to
try
to
find
that
obvious
error.
A
The
lack
of
code
review
in
this
company
was
a
very
clear
problem.
Those
outages
were
rare,
but,
as
I
said,
they
were
generally
one
letter
change
or
one
bad
line
of
code
after
a
few
months
or
a
few
months
after
I
left,
one
guy
cost
the
company
thousands
of
dollars
in
lost
revenue
because
he
left
his
own
email
address
in
Viron
variable
instead
of
referencing
an
environment
variable.
A
A
Code
review
also
drives
auditability
version.
Control
can
show
what
changed
and
the
reason
for
the
change,
but
it
doesn't
describe
the
decisions
that
were
dropped.
You
know
the
phrase
history
is
written
by
the
victor.
Well,
on
projects
get
history
is
written
by
the
victorious
commit
idioma,
Tissa
t
there's
a
new
word,
for
you
is
the
quality
of
using
the
tools
chosen
for
the
project
in
the
best
way
they
were
designed
to
be
used
ever
seen
java
that
looked
like
c
lisp
littered
with
let's
all
kinds
of
mutate,
abul
variables
in
your
scala
these
violations.
A
These
are
violations
of
the
idioms
that
these
tools
and
languages
prescribe
idiom
violations
can
make
for
less
performant
code
and
often
less
readable
code.
Writing
idiomatic
code
enables
the
compiler
of
the
interpreter
to
run
the
code
as
it
was
really
originally
designed
to
be
done.
This
produces
faster
and
more
maintainable
code.
A
My
second
job
out
of
school
was
a
consulting
role
as
an
applications
engineer
first
time
it
had
an
engineer
in
my
title.
The
lack
of
control
and
review
cost
us
a
lot
of
time
and
money
from
customers.
Technical
people
going
in
and
messing
around
with
the
configuration
that
we
had
so
carefully
crafted
and
then
not
owning
up
to
it,
to
not
having
enough
of
an
audit
trail
to
sufficiently
point
the
finger
when
there
was
a
compromise
at
a
government
facility,
although
we
had
no
evidence
that
it
was
ever
exploited.
A
My
first
professional
code
review
experience
was
a
group
meeting.
Wiegers
calls
them
for
formal
inspections.
It
was
very
painful.
I
was
the
the
subject
matter:
expert
in
the
back
of
the
room,
saying
no,
no,
no
you're
doing
it
all
wrong
and,
unfortunately,
I
developed
the
tool
that
enabled
this
group
to
do
code
review
on
my
part
of
the
project,
a
multi-million
dollar
that
100
million
dollar
project.
A
Imagine
this
if
you
will,
but
with
almost
everybody
looking
at
their
mobile
or
their
laptop,
and
that
guy
that's
just
like
chilling
back
there.
That's
me
a
little
bit
angrier,
though
everyone
wanted
to
get
ahead.
I
didn't
blame
them,
but
the
incentives
in
that
team,
weren't
aligned
employees
got
lots
of
overtime
while
already
making
pretty
lucrative
salaries
for
the
DC
area
contractors
and
subcontractors
who
exhausted
their
budget
ended
up
having
to
do
free
work
just
so
that
they
wouldn't
look
bad
and
be
made
to
look
bad
by
the
other
contractors.
A
A
The
project
did
eventually
launch,
but
by
many
metrics
was
not
successful.
The
primary
contractor
lost
the
renewal.
Most
of
that
waste
could
have
been
eliminated
through
a
better
code
review
process.
The
formality
of
the
inspections
may
have
been
a
symptom
rather
than
the
source
of
the
problem,
but
I
wasn't
party
to
discussions
that
actually
mandated
them,
nor
did
I
have
any
say
in
the
process
that
was
going
on.
A
Thirdly,
of
the
quality
attributes
and,
lastly,
of
the
quality
attributes
code
review
ensure
security.
We
want
to
spot
vulnerabilities
before
they
ship
and
teach
a
defensive
posture.
The
defensive
posture
part
is
especially
critical
to
teach
new
developers.
Lettuces
law
applies
equally
to
security,
as
it
does
to
other
parts
of
the
quality
attributes.
Spectrum.
The
best
way
to
keep
bugs
and
vulnerabilities
out
of
the
code
is
to
call
out
unnecessary
features,
unnecessary
bells
in
wage
with
bells
and
whistles.
Excuse
me:
you
ain't
going
to
need
it
in
this
situation.
Reviewers
are
like
your
lawyer.
A
A
Next,
some
tips.
When
should
you
integrate
code
review
a
couple
of
places,
because
the
structure
of
an
architecture
eventually
mirrors
that
of
the
developing
organization,
in
vice
versa,
waise
law?
It
is
vital
that
an
architecture
include
code
review
as
not
only
a
technical
technical
requirement
at
the
same
level
of
choice
as
a
language
or
a
framework
or
an
inter
process.
Communication
methodology,
but
also
as
a
project
requirement
that
describes
how
the
members
of
the
project
are
expected
to
interact
with
each
other
and
provide
feedback
to
strengthen
the
project
and
the
architecture
and
the
implementation.
A
A
A
Firstly,
code
review
should
occupy
units
of
work.
That
is,
if
your
team
is
using
story
points
or
some
other
system
to
estimate
effort
necessary
to
complete
a
task
also
estimate
the
time
necessary
to
go
through
the
code
review
process.
My
team
uses
a
Fibonacci
story
point
system.
Most
of
our
views
are
one
or
two
points.
If
it's
a
big
change
or
a
potentially
controversial
change,
will
increase
the
number
of
points
to
account
for
the
back-and-forth
it's
going
to
that's
going
to
occur,
except
that
not
everything
is
perfect.
A
A
good
code
review
system
will
enable
reviewers
or
submitters
to
create
new
issues.
New
work
items
quickly
and
easily
directly
in
line
github
feature
request,
identify
areas
that
see
a
lot
of
changes
understand
why
that
is
there's
a
whole
field
of
study
dedicated
to
understanding
churn
in
software
development,
so
don't
get
too
deep
into
it,
but
still
understand
it.
A
It's
also
very
important
not
to
be
petty,
keeping
it
professional
and
learning
when
to
speak
in
person
rather
than
angrily
typing
out.
A
comment
is
very
vital,
but
most
of
all
make
progress.
Don't
let
reviews
slow
down
development
unnecessarily?
If
you
find
that
they're
getting
backed
up
dogpile,
the
reviews
don't
write
any
new
code
until
the
reviews
are
completed,
or
at
least
stable.
A
Certain
projects
have
certain
concerns,
so
I'm
sure
of
it
other
languages.
Other
snacks
excuse
me
other
stacks-
have
their
own
separate
concerns.
I
must,
however,
stress
the
value
and
importance
of
automation.
Here,
a
few
months
ago,
my
team
integrated
style
checking
to
a
newer
project
that
we
just
not
done
at
the
start
of
it
like.
We
should
have
the
amount
of
time
that
our
pull
requests
spent
in
code
review
went
down
considerably
because
we
stopped
arguing
over
the
one
thing
that
everybody
was
easy.
A
A
Lastly,
let's
talk
about
some
limitations
of
code
review
code.
Review
cannot
really
easily
expose
how
the
code
changes,
how
the
proposed
changes
affect
the
runtime
environment.
The
reviewers
are
certainly
encouraged
to
download
and
execute
the
code
run.
The
tests
see
how
it
works
on
their
own
machine,
but
doing
this
too
often
can
significantly
slow
down
that
reviewer
they're
better
off
going
and
visiting
with
the
submitter
pairing
together
to
say:
hey,
let's
run
the
tests
in
your
environment
sure
this
introduces
environmental
problems,
but
those
are
things
that
should
be
caught
in
your
regression.
A
Billed
to
your
continuous
integration
system.
Reviewers
must
learn
when
to
communicate
in
person.
Constantly
writing
comments
back
and
forth.
380
sexing.
If
you
will,
can
really
draw
out
review
it's
one
thing
to
talk
in
person.
You
can
also
talk
through
hangouts
skype,
whatever
you
have,
but
it's
still
useful
to
consider
what
reference
that
online
conversation
whenever
you
need
to
do
code,
examples
or
hyperlinks.
A
Lastly,
the
code
review
cannot
solve
political
problems.
Code
review
will
not
get
your
boss
off
of
you.
It
will
not
get
QA
off
of
you
and
it
most
certainly
will
not
stop
layoffs.
In
fact,
code
of
you
can
sometimes
be
a
barrier
to
one's
own
ownership
of
their
contributions.
A
reviewer
with
an
agenda
could
effectively
block
another
submitter
through
combative
or
unnecessary
annotations
or
to
steal
credit
for
their
own
submission
by
simply
slightly
reworking
it
and
submitting
it
as
their
own
and
using
administrative
privileges
to
delete
the
other
one
one
woman
developer
cited.
A
This
is
a
reason
for
leaving
a
company
later
filing
lawsuits
against
the
company
alleging
sexism
she
held
at
a
coworker's.
She
snubbed,
romantically,
blocked
her
work
and
would
waste
time
altering
it
needlessly.
This
put
probably
put
them
behind
schedule.
A
counter
to
this
very
specific
problem,
ensure
that
no
one
reviewer
is
a
bottleneck,
no
single
point
of
failure
and
ensure
that
multiple
reviewers
can
and
actually
do,
review
anyone
submitters
code.
A
So
that's
about
it,
but
don't
have
to
take
my
word
for
it.
Microsoft
Research
published
a
paper
in
2013
expectations,
outcomes
and
challenges
of
modern
code
review,
part
of
which
asked
developers
for
their
motivations
for
performing
code
reviews.
Their
definition
of
code
reviews
matches
very
closely
with
the
one
that
I
cited
earlier
from
this.
We
can
observe
more
empirically
some
of
the
outcomes
from
code
review.
All
of
these
are
desirable,
and
thus
code
review
should
be
desirable
and
a
part
of
your
process.
A
We've
talked
about
the
definition
of
code
review
and
my
new
definition
is
the
systematic
examination
of
proposed
changes
to
a
code
base.
We've
talked
about
the
problems
that
code
review,
solves
modeling
and
knowledge.
Sharing.
We've
talked
about
the
primarily
quality
attributes
that
code
review,
insurers,
maintainability
compliance
and
security.
And,
lastly,
we
reviewed
some
of
the
tips,
suggestions
and
caveats
about
how
best
to
do
code
review.
A
So
please
go
forth
and
review
code,
but
before
you
do
I,
of
course,
do
you
have
to
do
a
shameless
plug
for
a
community
I,
organize
Pittsburgh
code
and
supply,
we're
Pittsburgh's
largest
group
of
software
developers.
We
just
held
abstractions
a
1500
person
conference,
Multi,
multi
disciplinary
conference
with
nearly
Universal
praised,
we'll
be
doing
another
smaller
event
in
2017.
So
please
keep
your
eyes
peeled
for
that
I'm
calling
Dean.
Thank
you
for
listening.
A
B
A
Question
does
does
this
change
for
remote
teams?
I
haven't
worked
specifically
on
a
fully
remote
team
in
a
while.
Actually,
I
have
worked
with
several
open
source
projects
that
did
obviously
did
have
a
very
remote
team
and
found
that
are
the
methods
that
we
use.
Their
didn't
really
deviate
a
whole
lot
from
what
we
use
for
our
co-located
team.
It's
obviously
easier
to
throw
a
boot
at
somebody
or
to
go
and
pass
them
on
the
back
when
they're.
A
Video
chat
was
a
thing,
but
it
wasn't
as
nice
it
as
it
is
now.
So
everything
was
through
IRC.
We
used
there's
a
thing
called
a
!,
em,
bang
em,
it's
like
a
motivational
thing
and
it's
like
a
nice
way
to
say:
okay,
this
is
really
good
or
to
talk
things
out
in
public
while
maintaining
maintaining
decorum.
That's
a
very
important
part
of
saying,
okay,
I
think
you
can
improve
this
and
carrying
that
conversation
in
a
way
that
others
can
contribute
to
it
as
well.