►
From YouTube: How C# is Developed In The Open with Mads Torgersen
Description
Mads Torgersen shows the C# Language is designed in the open.
He shows how issues in the csharplang repository become proposals and shows a few language proposals. The proposals then go to language design meetings, and all the notes for those meetings are included in the repository as well. This open process allows for the community to proposed ideas and interact with the team all the way through release as an official language feature.
B
I
think
it's
worth
talking
a
little
about
how
we
arrived
at
these
language
features
that
come
out
every
once
in
a
while,
and
it's
been
a
c-sharp
a
you
know,
sort
of
classically.
It
was
designed
behind
closed
doors
I
like
stuff
people
in
a
room,
and
there
were
good
things
and
bad
things
about
that.
The
bad
things
were
that
we
didn't
design
features
in
communication
with
the
broader
secure
community.
No,
we
didn't
have
maybe
good
input
on
what's
actually
most
important.
B
What
are
some
scenarios
that'll
work
better
or
worse,
with
this
design
right
right,
okay,
so
going
open?
We
really
have
moved
to
a
situation
where
we
can
have
much
more
of
a
conversation
with
all
the
c-sharp
users
and
everyone
who
has
an
opinion
and
and
as
we
go
as
we
design
get
feedback,
and
so
what
we'll
look
at
a
little
bit
is
the
artifacts
for
that
great.
B
At
the
same
time,
a
good
thing
was
being
in
a
room
together
and
spending
a
lot
of
time,
face-to-face,
designing
a
language
and
that's
something
that
we've
held
on
to.
We
still
have
a
C,
sharp
language
design
team.
That's
about
eight
people
that
need
four
hours
a
week
and
actually
go
through
the
decisions
and
the
different
choices
and
try
to
get
creative
and
request
can
design
the
language
names.
So
we
try
to
strike
a
balance.
B
Okay,
but
the
main
way
that
we
interact
with
the
community
and
language
design
is
that
there's
simply
a
repo
for
c-sharp
language
design
on
github,
cool,
okay.
So
there's
the
plates
that
I
have
up
here.
That
is
just
the
CTR
blank
repo
under
the
dotnet
organization,
okay,
and
the
way
this
works
is
we
have
the
source
code
in
this.
Repo
is
documents
that
pertain
to
language
design,
no
actual
implementation
code
that
happens
into
Rosslyn
repo
elsewhere.
Okay,.
A
B
Design
document,
and
so,
if
you
think
about
what
happens
with
a
feature
idea
proposal,
typically,
it
starts
out
in
the
issue
section
where
there's
a
you
know
very
active
discussion.
You
can
see
here.
If
we
just
go
to
issues
there's
in
this
particular
day.
It's
been
a
few
days
since
one
of
us
went
through
and
tagged
everything
with
with
labels
consistently,
but
to
go
down
here
you
can
see
we
quickly
like
go
in
and
say.
Is
this
person
discussing
something
suggesting
a
feature,
or
is
this
an
issue
with
the
design
and
so
on
and.
B
Okay
and
anyone
can
comment
on
them,
and
so
if
we
start
well,
here's
one
by
by
Miguel
de
Icaza,
that's
great,
he
proposes
dictionary.
Literals
I
did
that'd
be
cool.
So
if
we
go
look
at
look
at
that
proposal,
you
see
he
has
an
idea
for
syntax
for
another
new
dictionary
literals.
He
proposes
it
and
people
have
opinions
about
it.
Most
people
like
it.
It
looks
like
this
discussion.
Could
we
do
this?
Instead,
what
are
some
of
the
edge
cases
whatever
and
based
on
these?
B
Anyone
can
just
like
put
a
suggestion
out
there
and
listen
issue
and
we
get
lots
and
lots
of
those
right
and
so
based
on
that
the
language
designers
will
go
through
and
then
in
case
you
see
something
like
now.
We
should
probably
do
that
like
I.
Think
I
would
do
that
with
this
one
here
and
then
we
decide
that
we
want
to
champion
it,
and
that
means
we
go
to
the
person
who
proposes
it
and
that
produce
emit
a
proposal
as
a
pull
request
into
the
actual
documentary.
B
And
then
what
happens
is
that
somebody
writes
up
a
more
formal
proposal.
We
haven't
gotten
Miguel
to
do
that
for
this
one
yet,
but
your
rights
are
more
formal
proposal.
It
goes
into
the
proposals
directory
here
and
here
you
can
see
sort
of
all
the
active
proposals,
all
the
things
that
have
been
proposed
that
we
say
this
is
worth
discussing
in
the
length
design
meeting
and
seeing
if
it
had
legs-
and
you
know
refining
over
time
and
then
eventually
it'll
either
get
adopted
and
move
on
to
another
state.
A
B
B
A
checklist
at
the
top
that
says
what'swhat's
data
sitting
yeah
okay,
and
on
top
of
that,
the
pro
ever
on
the
language
design
team
chose
to
champion
this
feature.
They
will
there'll
be
an
issue
that
tracks
that
that
championing,
if
you
will
so
here's
a
here's,
a
proposal
champion
label
here
we
can
see
all
the
things
that
are
currently
championed
by
by
design
team
members
and
and
again
they
have
a
checklist
that
that
moves
it
through
the
process
of
writing
a
proposal
in
the
first
place
discussing
it
in
the
design
meetings
and.
A
B
That's
one
of
that's
a
checkbox
and
then
this
will
be
discussed
in
ldm,
which
is
short
for
language
design
meeting,
and
so
we
meet
up
to
two
times
a
week.
Two
hours
of
the
time
and
triage
things
that
are
championed
move
forward.
The
design
of
the
features
that
are
active
and
so
on
and
the
outcome
of
those
meetings
is
a
bunch
of
meeting
notes
which
I
write
up
and
I
try
to
keep
up
with.
They
always
sit
there
in
the
meeting
and
I
type.
B
A
A
B
A
B
And
another
thing
that
is
really
useful
is
that
we
have
a
record
of
the
of
the
design
intent.
You
know
the
the
rationale
for
the
reasons
we
took.
One
happened,
not
another
right
so
when
later
someone
says
why
didn't
we
or
why
didn't
we
do
it
this
way?
Instead,
we
can
actually
often
go
back
and
see.
Well,
that's
why
yeah
well
now
I,
remember!
That's
because
it
allocates
too
much
Radhika's.
You
know
it's
a
biggest
intact
of
whatever
yeah,
so
it
helps
us
not
repeat
the
things
big
to
us
awesome.