►
From YouTube: 2022 05 10 Inclusive Naming
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Welcome
this
is
the
inclusive
naming
project
as
part
of
shecode
africa.
Contributon
april
20
22.
today
is
may
the
10th.
Let's
get
that
in
the
notes?
May
10
and
great
to
have
you
all
here
thanks
for
being
here
and
topics
that
I
had
on
my
list
was:
let's
review
progress
to
date.
A
Looking
at
the
list
of
pull
requests
that
have
been
assembled,
etc
and
code
reviews
likely
needed
on
the
pull
requests,
special
thanks
to
anjalik
yard
who's,
been
doing
a
number
of
code
reviews
and
then
peace
and
catherine.
If
you
have
questions,
we
should
probably
put
your
questions
first
on
the
list,
because
we're
in
the
last
week
of
actually
I'll
put
it
on
the
list
as
a
timeline
reminder
we're
in
the
last
week
of
the
project.
A
Good
question
yes,
and
that's
last
week
of
the
project,
but
not
last,
but
not
the
last
week
of
meetings.
Yes,
there
will
be
good
good
points.
So
let's
talk
about
that.
What's
next
and
what's
what
happens
in
the
last
two
weeks
in
the
last
two
weeks
of
may.
C
Okay,
in
the
inclusive
naming
and
sheets,
I
saw
something
like
the
last
progress
is,
creates,
build
and
something
like
that
in
the
inclusive
naming
sheet.
That's
the
spreadsheet.
D
B
A
C
A
A
A
A
A
C
Okay,
on
my
on
the
inclusive
naming
sheet,
I
there
was
one
indicated
post
that
was
on
the
inclusive
naming
spreadsheets.
C
C
C
Because,
when
I,
when,
in
that
doc
file,
if
you
scroll
down,
you
see
one
doc
file
when
you
change
the
white
list
to
allow
the
the
english
term
does
not
it's
not
sounding
correct
again,.
A
A
E
A
straightforward
replacement
term
in
allow
list.
However,
I
found
that
subjectively
just
doing
the
straight
forward
replacement
of
whitelist
with
allow
list
sometimes
was
not
particularly
helpful,
or
it
just
gave
the
impression
that
you're
missing
some
information
there.
So
we
have
a
straightforward
one,
but
I
would
recommend
thinking
about
well.
Is
there
a
better
way
to
phrase
this
to
indicate
what
is
being
allowed.
A
This
variable
name,
given
that
this
is
sample
code
actually
could
be
replaced,
and
likewise
because
this
is
sample
code,
this
def
thing
could
be
could
be
replaced.
So
this
is
one
of
those
one
of
those
conditions
where,
because
it's
sample
inside
a
document,
we
can
actually
do
the
replacement
most
times.
I
would
say:
oh
it's
code,
don't
don't
touch
it
because
you'll
break
it,
but
in
this
case
you
actually
can
use
better
wording
to
describe
what
what
it
means
so
filtering
recipients
based
on
the
list
of
allowed
user
allowed
email
recipients.
C
Confused
I,
if
I
delete
the
white
list
and
write
aloud
the
the
phrase
is
not
sounding
correct
and
I'll
be
like.
What's
going
on.
A
Exactly
yeah
that
you're
you're
exactly
correct,
and
that's
that's
just
exactly
as
daniel
noted
that,
yes,
we
could
do
the
simple
textual
replacement,
but
then
it
feels
like
you're
missing
information
right.
It
doesn't
feel
right
to
say,
allow
list,
it's
just
not
telling
the
user
what
they
really
need
to
know
very
good.
Thank
you.
A
Is
this
talking
about
a
branch
that
is
exactly
the
branch
name
of
a
specific
repository
and
that
repository
is
master
as
its
convention?
Or
is
it
a
reference
to
the
primary
default
branch
of
this
repository,
and
in
that
case
it
could
be
use
the
term
main
branch
or
primary
branch
again.
This
is
one
to
check
in
with
daniel
since
he's
here
with
us
daniel.
What's
your
experience
been
on
referring
to
the
names
of
default
branches
in
git.
E
So
exactly
that
so
historically
git
github
and
so
on,
used
master
as
the
default
branch
name,
and
so
every
everyone
just
said,
master
branch
and
all
the
repos
still
have
that
as
the
branch
name
now.
The
problem,
as
far
as
I'm
aware
is
github
specifically,
if
you
create
a
new
repository,
will
use
the
main
branch
and
they
kind
of
nudge
people
towards
that
name,
even
in
existing
repositories,
but
there's
still
a
lot
of
repositories
around
that
use,
master
and
git
the
tool
itself.
As
far
as
I'm
aware,
still
uses
the
master
name.
E
So
since
there's
no
longer
this
fairly
strong
convention
to
have
a
master
branch
name
and
it
defers
on
it,
it's
different
on
the
various
environments,
my
recommendation
would
be
to
call
it
the
default
branch
as
just
a
more
generic
identifier
of
if
you
mean
the
default
branch.
Now
there
are
two
limitations
here.
One
is
as
mark,
as
you
said,
if
it's
a
specific
repository
and
it
has
a
master
branch,
we're
going
to
call
it
the
master
branch.
E
We
still
have
not
been
able
to
migrate
from
the
implicit
default
branch
name
master,
because
that
would
break
all
existing
configurations
that
rely
on
this
being
the
historical
default.
So,
in
that
specific
context
that
you
will
be
able
to
describe
much
more
accurately
than
I
am,
it
would
remain
master
as
well.
A
B
A
Thank
you
so
so
good
point
that
whitelist
blacklist
and
master
all
have
cases
where
we've
got
to.
We
have
to
think
more
more
deeply
about
what
we're,
describing
and
read
the
text
that
we're
using
to
to
fill
them
in
more
more
accurately,
very
good,
excellent
and
yeah.
As
as
daniel
said,
I
could
tell
you
some
horror
stories
about
certain
certain
plugins
inside
jenkins
that
struggle
mightily
when
people
change
the
default
branch
name,
it's
a
very
reasonable
thing
to
do
and
command
line.
A
Git
has
actually
now
made
it
an
option
so
that
you
can
say
my
default
for
all
new
git
repositories
with
very
recent
command
line.
Git
versions
will
be
named
main
instead
of
master
or
default
or
something
else
primary.
You
could
choose
the
name,
but
that
means
certain
plugins
have
really
challenging
situations.
And
how
do
we
deal
with
that
change?
B
If
you
go
back
to
the
sheet,
you
can
see
the
areas
that
I
had
highlighted
in
yellow
and
those
were
the
areas
that
I
had
queries
in
the
latest
one.
The
latest
edit.
B
Yes,
there
are,
there
are
a
couple
of
plugins
that
have
like,
like
the
fast
highlight
that
have
a
similar
rip
of
a
github
repo
to
another
plugin.
A
Yes,
very,
very
good
and
good
observation.
So
here
what
we
see
is
pipeline
stage
tags
metadata,
oddly
enough
uses
the
same
exact
git
repository
as
two
or
three
other
plugins,
and
and
if
you
look
at,
if
I
remember
correctly,
it's
the
blue
ocean
plug-in
has
a
similar
thing
where
it
has
multiple
plug-ins
delivered
from
a
single
repository
and
usually
that's
because
it
made
sense
for
the
development
of
that
plugin
to
to
develop
to
place
multiple
plugins
into
a
single
repository,
because
they
were
strongly
connected
to
one
another
in
the
case
of
pipeline
stage
tags
metadata.
A
I
believe
it's
because
it
is
a
fundamental
component
of
the
jenkins
declarative
pipeline
and
the
repository
it's
in
is
actually
the
jenkins
declarative
pipeline
repository,
so
so
you're
correct
to
say:
hey.
This
is
the
same
repo
now,
the
the
other
one
that
you
note
here,
the
handlebars
repo,
that's
the
same
repo,
but
for
a
slightly
different
reason.
A
A
B
No,
no
one
that
had
a
lot
of
issues
we
tackled
it
last
time.
A
B
A
Great
excellent,
so
yeah,
so
what
you're
and
you
I
think,
you'll
find
the
same
thing
in
in
a
number
of
other
open
source
projects
and
in
a
number
of
commercial
projects
where
sometimes
the
boundaries
between
repositories
and
things
we're
delivering,
are
intentionally
shuffled
in
order
to
make
it
easier
for
the
development
team
to
maintain
that
thing.
By
putting
them
all
in
one
repository.
In
some
cases,
it
makes
it
easier
to
make
changes.
B
A
Right-
and
I
I
think,
if
we
look
at
moment.js,
we'll
see
that
it's
it's
release,
what
would
you
call
it?
It's
when
was
yeah
the
last
the
last
time
it
was
released
was
six
years
ago,
and
this
these
links
are
in
general,
only
updated
when
we
do
a
new
release
and
we
we
don't
in
this
case,
need
to
release
a
new
version
of
moment.js.
A
A
A
A
B
A
Oh,
no,
no,
no,
no,
not
even
close,
catherine,
okay,
no,
no!
No!
No!
No!
No!
No!
No!
No!
No!
No!
Absolutely
not
what
what
we're
going
to
do
with
this
sheet!
What
what
what
we
will
continue
to
do
as
a
project
with
the
sheet
is
we're
going
to
use
this
to
guide
our
efforts,
so
you've
already
done
some
looking
to
see
if
there
were
changes
needed.
So
we
now
know
we
can
skip
over
these.
We'll
can
we'll
use
this
sheet
con
in
an
ongoing
basis
to
do
more
work
on
these
kinds
of
efforts?
A
So
no,
no
you
do
not.
I
I
feel,
like
you've
done
a
great
job.
I
would
love
for
you
to
do
even
more
before
the
end
of
the
week,
but
my
sense
is:
there's
no
way
did
we
ever
expect
that
you
would
complete?
Well,
let's
look
at
the
number
1
800
repositories.
No,
no!
No!
Never,
never
assumed
anything
like
that.
It
was
just
we'll
work
as
many
as
we
can.
We
start
with
the
most
popular
first
and
keep
working
down
the
list.
A
Super
now
I
did
get
a
question
in
a
preceding
meeting.
Are
we
allowed
to
continue
doing
this
even
after
the
project
ends?
And
the
answer
is
yes
absolutely,
but
we
also
understand
that
the
project
is
intentionally
for
a
specific
time
and
it's
funded
so
that
you
can
afford
the
time
to
do
it.
We
know
that
you've
got
lives
outside
of
the
jenkins
project
and
you've
got
work
or
school
or
family,
and
we
understand
that,
but
if
you're
able
to
continue,
we
certainly
welcome
you
to
continue
as
well.
A
D
D
D
D
A
Good
good
question
all
right,
so
so
in
general.
No,
so
that
that's
a
so
let
me
let
me
highlight
what
nafissa
is
indicating
so
in
the
projects
folder
that
we
had
on
on
google
drive,
we
have
an
inclusive
naming
or
we
have
an
inclusive
naming
folder.
We
also
had
a
people
folder
where,
for
each
of
the
participants,
we
put
a
folder
for
you,
so
catherine's
folder
is
here
and
pieces
pieces
folders
right
here.
What
nafissa
was
asking
is:
do
you
need
to
update
your
copy
of
the
document
that
we
put
there
for
convenience?
A
The
answer
is
no.
That
was
just
to
help
you
as
a
as
a
participant
as
you
were,
organizing
your
thoughts
you're
welcome
to
provide
your
summaries
separately
you're.
Welcome
to
keep
that
private.
If
you
wish,
you
don't
need
to
feel
like
you
have
to
share
your
insights
or
comments
publicly,
because
if
there
was
something
that
went
really
badly
with
the
project
or
that
you
think,
I
really
need
to
say
something
very
harsh
about
mark
waite.
A
C
On
the
on
the
onboarding,
I
remember
them:
zenob
made
a
statement
that
which
the
report
should
be
made
published.
Oh.
A
Well,
okay,
so
so,
if
you
would
like
to
make
it
public,
we've
got
a
great.
I
had
forgotten
xenob's
guidance
and
she
certainly
is
the
one
who
would
who
would
be
the
more
important
one
to
listen
to
on
that.
If
you
would
like
to
post
it
publicly
and
wouldn't
mind
posting
it
on
the
jenkins
blogs,
each
of
you
all,
I
can.
We
could
certainly
do
a
session
after
the
end
of
project
to
show
you
how
to
do
a
jenkins
blog
post.
A
D
C
Yes,
that
was
what
zenob
said
like
we
should
post
it.
We
should
make
a
blog
post
about
it,
and
then
we
will
forward
the
link
to
the
to
africa.
A
Well,
very
good!
So,
let's
I
I
had
forgotten
that
so,
let's,
let's
use,
I
would
propose.
We
use
community.jenkins.io.
A
As
the
public
location
for
your
for
your
report,
because
that
lets
you
want
to,
let
you
embed
pictures,
if
you
want,
you
can
insert
graphs,
you
can
do
you've,
certainly
got
text
and
it's
easy
text
editing.
So
it's
it's
far
simpler
to
do
a
posting
to
community.jenkins.io
than
it
is
to
do
a
new
blog
post
on
on
the
jenkins.io
doc
site.
C
Okay,
please
can
I
ask
a
question,
but
it's
not
it's
not
related
to
this.
This
particular
topic,
but
it's
something
concerning
the
github.
Is
there
a
way
that
we
can,
for
example,
the
last
time
I
commented
on
the
I
made
a
comment
on
the
git
on
one
of
the
github
plugin.
I
made
a
mistake.
I
wanted
to
correct
it
before
creating
a
pull
request,
but
I
am
finding
difficulty
correcting
it.
I
want
to
ask:
is
there
a
way
we
can
correct
mistake?
C
A
A
A
C
No,
I
mean
this
master
already
this
one
the
commits
I
already
made
like
I
can
sold
master
and
used
controller.
Maybe
I
want
to
change
that
controller
to
main
or
something
else
without.
A
So
that's
that's
the
easy
way,
and
that
shows
a
history.
Then
the
person
who
receives
who
reviews
the
pull
request
may
choose
if
they
wish
to
do
what's
called
a
squash
merge
and
what
that
does.
Is
it
takes
your
multiple
commits
and
combines
them
into
a
single
commit
so
that
your
all
of
your
well,
in
my
case,
I
make
many
mistakes,
while
I'm
doing
these
things-
and
I
squash
merge
because
it
hides
all
my
stakes,
all
my
mistakes
into
a
single
commit.
A
A
There
is
another
way
to
do
it
if
you're
willing
to
bring
out
command
line
git
where
you
clone
it
locally
and
you
do
a
a
git
commit
minus
minus,
amend,
that's
a-m-e-n-d,
amend
and
what
it
lets
you
do
is
rewrite
the
thing
and
you
can
change
the
message.
You
can
change
the
contents,
but
then,
in
order
to
push
it
to
github,
you
have
to
use
the
very
dangerous
option:
minus
minus
force-
and
I
say
very
dangerous
because
it's
destructive
so
so
avoid
the
option
minus
minus
force,
if
you
possibly
can,
but
it's
available.
A
So
there
are
those
two
ways
to
correct
a
mistake:
the
easy
one
which-
and
I
think
should
be
the
almost
in
99
of
the
cases
you
should
use
the
easy
one
submit
a
new
commit
the
hard
one
is
overwrite
the
commit
and
force
it
and
the
that
one
is
dangerous
because
you
can
destroy
things
so
peace
did.
That
answer
your
question.
A
A
good
question,
and
just
so
so
you
understand
the
real
life
I've
done
serious
damage
by
using
force
pushes
to
repositories,
so
so
be
very
careful,
especially
if
you
put
the
force
option
in
a
script.
A
That
that
this
may
be
a
perfect
place
for
us
to
ask
for
your
help
on
sharing,
with
with
other
the
other
projects
in
the
chico
africa
contribution
for
jenkins,
to
ask
them
to
do
their
their
final
reports
to
community.jenkins.io
as
well.
Would
you
be
willing
to
do
that?
Maybe
we
have
you
actually
act
as
the
first
as
the
first
example
and
create
one
that
we
can
say:
hey
here's,
how
it's
done.
D
A
Yeah,
that's
what
I
was
thinking
is
if,
if
you
were
to
create
a
your,
create
the
first
beginnings
of
your
your
final
project
report-
and
it
could
be
pretty
simple,
saying
hey,
this
is
the
beginning
of
a
project
report
and
put
it
on
jenkins.io
community.jenkins.io
so
that
others
see
it
so
post
their
public
project
reports
to
community.jenkins.io.
B
A
B
Yes,
that's
what
I
was
asking
is
there
a
guide
that
someone
can
read,
because
we're
short
of
time
that
if
someone
wanted
to
try
out
an
alternative
to
see
how
it
works?
Oh.
A
A
A
Okay,
and
so
now
I
have
to
admit
for
the
jenkins
project
report,
to
submit
to
chico
to
africa
I'll
have
to
check
with
with
with
zenob,
to
see
if
she
expects
that
one
to
be
public
or
not.
I
assume
not
because
we've
got
at
least
one
participant
where
she
hasn't.
She
hasn't
actively
participated
for
at
least
three
weeks,
and
so
I'm
hesitant
to
say
that
publicly
in
a
you,
know
big,
but
I'm
going
to
tell
it
to
him
privately
saying:
hey
one
of
the
participants
didn't
participate.
A
A
Okay,
next
next
point
for
me
was
reviewing
progress
to
date
and
and
the
sheet
now
catherine
and
peace.
I
assume
you're
putting
your
pull
requests
into
the
sheet.
Are
there
any
that
aren't
in
the
sheet
that
we
should
be
reviewing?
So
are
there
any
that
are
missing
from
this
sheet,
because
we
could
also
look
at
your
github
history
and
try
to
grab
them
from
there.
Instead.