Git Inclusion Summit

Git Inclusion Summit

[Carmen Andoh]

Hello Git community,

There's been some conversation about holding a virtual contributor
summit focused on inclusion [1]. I've volunteered to work with
Jonathan Nieder’s team on organizing this event.

The purpose of this inclusion summit is to engage core Git
contributors as active participants in diversity and inclusion
initiatives for the Git project. As mentioned [2] "to align and
coordinate, to set out goals that we want to agree on." This is part
of a broader goal to make the Git version control system better
support inclusive open source projects. The summit will give
contributors the opportunity to learn about and share perspectives on
inclusive culture, product inclusion, and career development.

This can be run unconference style like previous contributor summits:
we'll use a spreadsheet to choose and vote on topics. This event will
be a success if we walk away with specific recommendations on where
and how Git will make changes to improve the experiences of
underrepresented users in the Git project, and how to make the Git
project better represent the needs of current and potential users.

It was mentioned in [1] that we should have conversations about equity
and inclusion with more diverse voices present.  But we also don’t
want to put a burden on individuals coming to educate us about things
that we should be researching for ourselves. To that end, we are
meeting with Diversity, Equity, Inclusion (DEI) experts for guidance
and will have recommendations to incorporate into the summit. Prior to
the summit, we will send out some resources to look through ahead of
time.

Who all are invited?

Git core contributors on https://lore.kernel.org/git/., anyone
interested in teaching OSS projects about DEI.

If your network includes any groups or individuals who focus on
educating others about DEI, you're welcome to invite them or contact
summit organizers to learn more.  We prefer groups and individuals who
are in the business of educating on inclusion, or if they are
volunteers, already explicitly expressed their interest in
volunteering rather than being asked, as we want to be very mindful of
free emotional labor. A bonus for knowledge of inclusion in open
source.  We can widen our understanding by asking non-Git contributors
to come share their perspectives for some or all of the summit.

When?
Anytime between mid August - mid September.  To get consensus on
preferred dates [3], including summit duration and times, please vote
at the whenisgood link below by Thursday, July 30th. Please specify in
comments if you prefer a .5 day, 1 day, 1.5 days or other for the
event duration.

Next Steps:
Once a reasonable consensus has been reached, we’ll set the date and
time, ask for RSVPs via email, and send a planning spreadsheet to
start proposing topics and crowdsourcing the agenda.

I have questions, who should I contact?

For questions or concerns, please reach out to git-inclusion@googlegroups.com

Interested in helping to plan this event?
Email git-inclusion@googlegroups.com to join


[1] https://lore.kernel.org/git/20200610222719.GE148632@google.com
[2]https://lore.kernel.org/git/nycvar.QRO.7.76.6.2006121525140.56@tvgsbejvaqbjf.bet/
[3] http://whenisgood.net/9z2diyy

Thanks,
Carmen Andoh
Open Source Programs Office, Google

Re: Git Inclusion Summit

[Jonathan Nieder]

(cc-ing some people from the previous discussion[1])
Hi,

Carmen Andoh wrote:

> There's been some conversation about holding a virtual contributor
> summit focused on inclusion [1]. I've volunteered to work with
> Jonathan Nieder’s team on organizing this event.

Welcome!

[...]
> This can be run unconference style like previous contributor summits:
> we'll use a spreadsheet to choose and vote on topics.

That worked well in [4], so sounds good to me.

[...]
> Who all are invited?
>
> Git core contributors on https://lore.kernel.org/git/., anyone
> interested in teaching OSS projects about DEI.
[...]
> When?
> Anytime between mid August - mid September.  To get consensus on
> preferred dates [3], including summit duration and times, please vote
> at the whenisgood link below by Thursday, July 30th. Please specify in
> comments if you prefer a .5 day, 1 day, 1.5 days or other for the
> event duration.

The 2019 Git contributors summit was two half-days, which seemed to work
well.  That made it easier to get some time zone overlap between Europe
and the United States.  More time than that in a day on video and
people would start to get tired.

Thoughts about how to get reasonable coverage for people in different
time zones?  It's subtle, but the whenisgood link appears to assume
U.S. pacific time --- I'd be willing to start a little earlier or end
a little later if it makes participation from other time zones easier.

Thanks,
Jonathan

> [1] https://lore.kernel.org/git/20200610222719.GE148632@google.com
> [2] https://lore.kernel.org/git/nycvar.QRO.7.76.6.2006121525140.56@tvgsbejvaqbjf.bet/
> [3] http://whenisgood.net/9z2diyy
[4] https://lore.kernel.org/git/nycvar.QRO.7.76.6.1907031429420.44@tvgsbejvaqbjf.bet/

Re: Git Inclusion Summit

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Carmen Andoh wrote:
>
>> There's been some conversation about holding a virtual contributor
>> summit focused on inclusion [1]. I've volunteered to work with
>> Jonathan Nieder’s team on organizing this event.
>
> Welcome!

Yup, welcome and thanks for helping.

> Thoughts about how to get reasonable coverage for people in different
> time zones?  It's subtle, but the whenisgood link appears to assume
> U.S. pacific time --- I'd be willing to start a little earlier or end
> a little later if it makes participation from other time zones easier.

FWIW, we've timed coordinated security releases at late afternoon
European, which translates to early afternoon Eastern and late
morning Pacific time.  It was a bit inconvenient when I was in east
Asia where it is past midnight but it was OK as it was convenient
for everybody else.

The intended population may be somewhat different for this event,
but I suspect that the difference is not all that much.  Or am I
not being inclusive enough for our Asian friends by assuming so?

Re: Git Inclusion Summit

[Carmen Andoh]

Hello all,

First test of inclusion: be inclusive of time zones.
I've updated the whenisgood [1] to accept a broader time range.  From
6am to 9pm Pacific to be more doable for people in EMEA and APAC. To
those who have already responded with time preferences, can you submit
another response with the new times? Jonathan's suggestion of having
multiple half days at different times could be a good compromise (one
day you wake up early, another day you stay up late).

[1] https://whenisgood.net/9z2diyy

On Thu, Jul 23, 2020 at 6:26 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
> > Carmen Andoh wrote:
> >
> >> There's been some conversation about holding a virtual contributor
> >> summit focused on inclusion [1]. I've volunteered to work with
> >> Jonathan Nieder’s team on organizing this event.
> >
> > Welcome!
>
> Yup, welcome and thanks for helping.
>
> > Thoughts about how to get reasonable coverage for people in different
> > time zones?  It's subtle, but the whenisgood link appears to assume
> > U.S. pacific time --- I'd be willing to start a little earlier or end
> > a little later if it makes participation from other time zones easier.
>
> FWIW, we've timed coordinated security releases at late afternoon
> European, which translates to early afternoon Eastern and late
> morning Pacific time.  It was a bit inconvenient when I was in east
> Asia where it is past midnight but it was OK as it was convenient
> for everybody else.
>
> The intended population may be somewhat different for this event,
> but I suspect that the difference is not all that much.  Or am I
> not being inclusive enough for our Asian friends by assuming so?

Re: Git Inclusion Summit

[Eric Wong]

Carmen Andoh <candoh@google.com> wrote:
> Hello Git community,
> 
> There's been some conversation about holding a virtual contributor
> summit focused on inclusion [1]. I've volunteered to work with
> Jonathan Nieder’s team on organizing this event.
> 
> The purpose of this inclusion summit is to engage core Git
> contributors as active participants in diversity and inclusion
> initiatives for the Git project. As mentioned [2] "to align and
> coordinate, to set out goals that we want to agree on." This is part
> of a broader goal to make the Git version control system better
> support inclusive open source projects. The summit will give
> contributors the opportunity to learn about and share perspectives on
> inclusive culture, product inclusion, and career development.
> 
> This can be run unconference style like previous contributor summits:
> we'll use a spreadsheet to choose and vote on topics. This event will
> be a success if we walk away with specific recommendations on where
> and how Git will make changes to improve the experiences of
> underrepresented users in the Git project, and how to make the Git
> project better represent the needs of current and potential users.
> 
> It was mentioned in [1] that we should have conversations about equity
> and inclusion with more diverse voices present.  But we also don’t
> want to put a burden on individuals coming to educate us about things
> that we should be researching for ourselves. To that end, we are
> meeting with Diversity, Equity, Inclusion (DEI) experts for guidance
> and will have recommendations to incorporate into the summit. Prior to
> the summit, we will send out some resources to look through ahead of
> time.
> 
> Who all are invited?
> 
> Git core contributors on https://lore.kernel.org/git/., anyone
> interested in teaching OSS projects about DEI.
> 
> If your network includes any groups or individuals who focus on
> educating others about DEI, you're welcome to invite them or contact
> summit organizers to learn more.  We prefer groups and individuals who
> are in the business of educating on inclusion, or if they are
> volunteers, already explicitly expressed their interest in
> volunteering rather than being asked, as we want to be very mindful of
> free emotional labor. A bonus for knowledge of inclusion in open
> source.  We can widen our understanding by asking non-Git contributors
> to come share their perspectives for some or all of the summit.

Hello, I'm only an occasional contributor to git since 2005;
but I have many concerns which don't seem be brought up.

I have several concerns about the increasing use of video
conferencing in Open Source development in general.

1. The data can potentially be used to feed facial and
   voice recognition (either by the host or some participant).

   I haven't allowed myself to be photographed in over a decade
   and never video conferenced.  I've also turned down countless
   professional and personal opportunities because of this, along
   with never flying due to invasive screenings at airports.

2. Even without the privacy perspective, I have some hearing loss
   and conversations can be difficult.  There's plenty of folks
   with more severe hearing loss than mine who'd be left out.

3. It seems much of the software used for video conferencing
   proprietary, even though Free (as in speech) alternatives exist.
   I don't know enough about this area but maybe others can chime
   in.

4. Finally, the hardware and bandwidth requirements for video
   streaming is high.  Poorer folks on slow computers or in areas
   with expensive bandwidth would also be left out.

   And one of the reasons I don't code as much as I used to is
   both gcc and clang are taking longer to compile with every
   release and our test suite isn't exactly fast.

So yes, I'd like these concerns addressed even though I'm not
willing to be on video or deal with JavaScript.  Thanks.


/me goes back to making public-inbox (and thus lore) faster on
 rusty old hardware...

Re: Git Inclusion Summit

[Taylor Blau]

On Sun, Jul 26, 2020 at 04:02:26AM +0000, Eric Wong wrote:
> Carmen Andoh <candoh@google.com> wrote:
> > Hello Git community,
> >
> > There's been some conversation about holding a virtual contributor
> > summit focused on inclusion [1]. I've volunteered to work with
> > Jonathan Nieder’s team on organizing this event.
> >
> > The purpose of this inclusion summit is to engage core Git
> > contributors as active participants in diversity and inclusion
> > initiatives for the Git project. As mentioned [2] "to align and
> > coordinate, to set out goals that we want to agree on." This is part
> > of a broader goal to make the Git version control system better
> > support inclusive open source projects. The summit will give
> > contributors the opportunity to learn about and share perspectives on
> > inclusive culture, product inclusion, and career development.
> >
> > This can be run unconference style like previous contributor summits:
> > we'll use a spreadsheet to choose and vote on topics. This event will
> > be a success if we walk away with specific recommendations on where
> > and how Git will make changes to improve the experiences of
> > underrepresented users in the Git project, and how to make the Git
> > project better represent the needs of current and potential users.
> >
> > It was mentioned in [1] that we should have conversations about equity
> > and inclusion with more diverse voices present.  But we also don’t
> > want to put a burden on individuals coming to educate us about things
> > that we should be researching for ourselves. To that end, we are
> > meeting with Diversity, Equity, Inclusion (DEI) experts for guidance
> > and will have recommendations to incorporate into the summit. Prior to
> > the summit, we will send out some resources to look through ahead of
> > time.
> >
> > Who all are invited?
> >
> > Git core contributors on https://lore.kernel.org/git/., anyone
> > interested in teaching OSS projects about DEI.
> >
> > If your network includes any groups or individuals who focus on
> > educating others about DEI, you're welcome to invite them or contact
> > summit organizers to learn more.  We prefer groups and individuals who
> > are in the business of educating on inclusion, or if they are
> > volunteers, already explicitly expressed their interest in
> > volunteering rather than being asked, as we want to be very mindful of
> > free emotional labor. A bonus for knowledge of inclusion in open
> > source.  We can widen our understanding by asking non-Git contributors
> > to come share their perspectives for some or all of the summit.
>
> Hello, I'm only an occasional contributor to git since 2005;
> but I have many concerns which don't seem be brought up.
>
> I have several concerns about the increasing use of video
> conferencing in Open Source development in general.
>
> 1. The data can potentially be used to feed facial and
>    voice recognition (either by the host or some participant).
>
>    I haven't allowed myself to be photographed in over a decade
>    and never video conferenced.  I've also turned down countless
>    professional and personal opportunities because of this, along
>    with never flying due to invasive screenings at airports.
>
> 2. Even without the privacy perspective, I have some hearing loss
>    and conversations can be difficult.  There's plenty of folks
>    with more severe hearing loss than mine who'd be left out.
>
> 3. It seems much of the software used for video conferencing
>    proprietary, even though Free (as in speech) alternatives exist.
>    I don't know enough about this area but maybe others can chime
>    in.
>
> 4. Finally, the hardware and bandwidth requirements for video
>    streaming is high.  Poorer folks on slow computers or in areas
>    with expensive bandwidth would also be left out.
>
>    And one of the reasons I don't code as much as I used to is
>    both gcc and clang are taking longer to compile with every
>    release and our test suite isn't exactly fast.
>
> So yes, I'd like these concerns addressed even though I'm not
> willing to be on video or deal with JavaScript.  Thanks.

I think that it's tough to make individuals on both sides of this feel
comfortable. On the one hand, folks such as yourself may feel
uncomfortable with this format for the reasons that you posted above. On
the other hand, some folks may prefer audio or video instead of text
because they find it easier to express themselves with their body
language, intonation, etc.

A bare minimum seems to be using a free service (I know that Jitsi Meet
is an often-recommended alternative) with support for joining without
video (either using audio only, or participating over chat).

Hopefully everybody should have a good-enough internet connection to
stream a low-quality audio-only feed so that they can listen in and
participate via the chat feature. This is what we did at the
Contributor's Summit in March (I know we had a number of text-only
participants in time-zones where it was late, etc.).

What are your thoughts?

> /me goes back to making public-inbox (and thus lore) faster on
>  rusty old hardware...

;-)

Thanks,
Taylor

Re: Git Inclusion Summit

[Eric Wong]

Taylor Blau <me@ttaylorr.com> wrote:

<snip>

> I think that it's tough to make individuals on both sides of this feel
> comfortable. On the one hand, folks such as yourself may feel
> uncomfortable with this format for the reasons that you posted above. On
> the other hand, some folks may prefer audio or video instead of text
> because they find it easier to express themselves with their body
> language, intonation, etc.

I can understand that.  However most coding nowadays (especially
for this project) is text, so that's already the lowest common
denominator.

> A bare minimum seems to be using a free service (I know that Jitsi Meet
> is an often-recommended alternative) with support for joining without
> video (either using audio only, or participating over chat).
> 
> Hopefully everybody should have a good-enough internet connection to
> stream a low-quality audio-only feed so that they can listen in and
> participate via the chat feature. This is what we did at the
> Contributor's Summit in March (I know we had a number of text-only
> participants in time-zones where it was late, etc.).
> 
> What are your thoughts?

Jitsi w/ audio-only certainly seems to be a step in the right
direction and would be more inclusive.

Is there any speech-to-text transcription done for the hearing
(or extremely bandwidth) impaired?

It'd ideally go to #git on IRC (or something that doesn't
require a browser to trigger swap storms on old systems).

Even for people with good hearing, acceptable audio quality for
speech seems tricky to get right, being dependent on mics,
bandwidth, codecs, background noise, speaker/earphone quality,
etc.

Re: Git Inclusion Summit

[Taylor Blau]

On Tue, Jul 28, 2020 at 10:07:26AM +0000, Eric Wong wrote:
> Taylor Blau <me@ttaylorr.com> wrote:
>
> <snip>
>
> > I think that it's tough to make individuals on both sides of this feel
> > comfortable. On the one hand, folks such as yourself may feel
> > uncomfortable with this format for the reasons that you posted above. On
> > the other hand, some folks may prefer audio or video instead of text
> > because they find it easier to express themselves with their body
> > language, intonation, etc.
>
> I can understand that.  However most coding nowadays (especially
> for this project) is text, so that's already the lowest common
> denominator.
>
> > A bare minimum seems to be using a free service (I know that Jitsi Meet
> > is an often-recommended alternative) with support for joining without
> > video (either using audio only, or participating over chat).
> >
> > Hopefully everybody should have a good-enough internet connection to
> > stream a low-quality audio-only feed so that they can listen in and
> > participate via the chat feature. This is what we did at the
> > Contributor's Summit in March (I know we had a number of text-only
> > participants in time-zones where it was late, etc.).
> >
> > What are your thoughts?
>
> Jitsi w/ audio-only certainly seems to be a step in the right
> direction and would be more inclusive.
>
> Is there any speech-to-text transcription done for the hearing
> (or extremely bandwidth) impaired?

It looks like such a thing exists:
https://jitsi.org/blog/a-speech-to-text-prototype/.

> It'd ideally go to #git on IRC (or something that doesn't
> require a browser to trigger swap storms on old systems).
>
> Even for people with good hearing, acceptable audio quality for
> speech seems tricky to get right, being dependent on mics,
> bandwidth, codecs, background noise, speaker/earphone quality,
> etc.

I haven't look hard enough to see if it supports redirecting its output
to an IRC channel, but my guess is that it probably doesn't. In either
case, hopefully disabling audio and video is possible within Jitsi's web
UI, and you should be able to read or write in the chat as well as read
the transcription.

Thanks,
Taylor

Re: Git Inclusion Summit

[Jeff King]

On Tue, Jul 28, 2020 at 10:07:26AM +0000, Eric Wong wrote:

> > Hopefully everybody should have a good-enough internet connection to
> > stream a low-quality audio-only feed so that they can listen in and
> > participate via the chat feature. This is what we did at the
> > Contributor's Summit in March (I know we had a number of text-only
> > participants in time-zones where it was late, etc.).
> > 
> > What are your thoughts?
> 
> Jitsi w/ audio-only certainly seems to be a step in the right
> direction and would be more inclusive.
> 
> Is there any speech-to-text transcription done for the hearing
> (or extremely bandwidth) impaired?
> 
> It'd ideally go to #git on IRC (or something that doesn't
> require a browser to trigger swap storms on old systems).

Whether we have automatic speech-to-text conversion or not, I think it
would be good for people involved to take and publish notes summarizing
the conversation. One of the important things about our usual async
written communication is that it gives people time to organize their
thoughts and say what they want succinctly. Live conversations are often
full of false starts and rambling. That's OK, and a necessary part of
the process. But if you want a wider audience to follow along, it helps
to turn that into something more time efficient for readers.

-Peff

Re: Git Inclusion Summit

[Kaartic Sivaraam]

On 28-07-2020 21:55, Taylor Blau wrote:
> On Tue, Jul 28, 2020 at 10:07:26AM +0000, Eric Wong wrote:
>>
>> Jitsi w/ audio-only certainly seems to be a step in the right
>> direction and would be more inclusive.
>>
>> Is there any speech-to-text transcription done for the hearing
>> (or extremely bandwidth) impaired?
> 
> It looks like such a thing exists:
> https://jitsi.org/blog/a-speech-to-text-prototype/.
> 

Yeah. A link with current information appears to be:

https://github.com/jitsi/jigasi#using-jigasi-to-transcribe-a-jitsi-meet-conference

>> It'd ideally go to #git on IRC (or something that doesn't
>> require a browser to trigger swap storms on old systems).
>>
>> Even for people with good hearing, acceptable audio quality for
>> speech seems tricky to get right, being dependent on mics,
>> bandwidth, codecs, background noise, speaker/earphone quality,
>> etc.
> 
> I haven't look hard enough to see if it supports redirecting its output
> to an IRC channel, but my guess is that it probably doesn't.

I believe you're right. From the link above:

> Currently Jigasi can send speech-to-text results to the chat of a
> Jitsi Meet room as either plain text or JSON. If it's send in JSON,
> Jitsi Meet will provide subtitles in the left corner of the video,
> while plain text will just be posted in the chat.

> In either
> case, hopefully disabling audio and video is possible within Jitsi's web
> UI, and you should be able to read or write in the chat as well as read
> the transcription.
> 

I think there's just one catch. The transcription as of now appears to
use Google Cloud speech-to-text API. Well, its Google. I'll let you make
your own inferences. In any case, it hopefully wouldn't be a concern for
people who _read_ the transcription.

-- 
Sivaraam

24 hours to respond with date/duration preferences for inclusion summit

[Carmen Andoh]

On Tue, Jul 28, 2020 at 1:15 PM Kaartic Sivaraam
<kaartic.sivaraam@gmail.com> wrote:
>
> On 28-07-2020 21:55, Taylor Blau wrote:
> > On Tue, Jul 28, 2020 at 10:07:26AM +0000, Eric Wong wrote:
> >>
> >> Jitsi w/ audio-only certainly seems to be a step in the right
> >> direction and would be more inclusive.
> >>
> >> Is there any speech-to-text transcription done for the hearing
> >> (or extremely bandwidth) impaired?
> >
> > It looks like such a thing exists:
> > https://jitsi.org/blog/a-speech-to-text-prototype/.
> >
>
> Yeah. A link with current information appears to be:
>
> https://github.com/jitsi/jigasi#using-jigasi-to-transcribe-a-jitsi-meet-conference
>
> >> It'd ideally go to #git on IRC (or something that doesn't
> >> require a browser to trigger swap storms on old systems).
> >>
> >> Even for people with good hearing, acceptable audio quality for
> >> speech seems tricky to get right, being dependent on mics,
> >> bandwidth, codecs, background noise, speaker/earphone quality,
> >> etc.
> >
> > I haven't look hard enough to see if it supports redirecting its output
> > to an IRC channel, but my guess is that it probably doesn't.
>
> I believe you're right. From the link above:
>
> > Currently Jigasi can send speech-to-text results to the chat of a
> > Jitsi Meet room as either plain text or JSON. If it's send in JSON,
> > Jitsi Meet will provide subtitles in the left corner of the video,
> > while plain text will just be posted in the chat.
>
> > In either
> > case, hopefully disabling audio and video is possible within Jitsi's web
> > UI, and you should be able to read or write in the chat as well as read
> > the transcription.
> >
>
> I think there's just one catch. The transcription as of now appears to
> use Google Cloud speech-to-text API. Well, its Google. I'll let you make
> your own inferences. In any case, it hopefully wouldn't be a concern for
> people who _read_ the transcription.
>
> --
> Sivaraam

Hello All,

Just a reminder that you have another day to respond to whenisgood
[1].  Note that times are listed as 6AM-9PM (21:00) Pacific.  Please
specify duration preferences ( half days, full days, etc)  in
comments.  Hopefully we'll respond soon after that with date/s that
works for most.

[1] http://whenisgood.net/9z2diyy

-Carmen

Re: 24 hours to respond with date/duration preferences for inclusion summit

[Junio C Hamano]

Carmen Andoh <candoh@google.com> writes:

> Hello All,
>
> Just a reminder that you have another day to respond to whenisgood
> [1].  Note that times are listed as 6AM-9PM (21:00) Pacific.  Please
> specify duration preferences ( half days, full days, etc)  in
> comments.  Hopefully we'll respond soon after that with date/s that
> works for most.

Sorry for sending this on the last day. 

After re-reading the original announcement and the above part, I am
wondering if responding to the "when is the good time for you?" poll
is a requirement to be invited.  My tentative understanding is that
this is merely to help resolove scheduling conflicts, and those who
want to attend but have no particular time/date preference can just
stay silent and wait for the invitation to come, to which they are
required to respond via e-mail in order to attend.

I suspect many people are wondering about the same thing and
a bit of clarification may help.

Thanks.

Re: 24 hours to respond with date/duration preferences for inclusion summit

[Carmen Andoh]

On Wed, Jul 29, 2020 at 2:25 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Carmen Andoh <candoh@google.com> writes:
>
> > Hello All,
> >
> > Just a reminder that you have another day to respond to whenisgood
> > [1].  Note that times are listed as 6AM-9PM (21:00) Pacific.  Please
> > specify duration preferences ( half days, full days, etc)  in
> > comments.  Hopefully we'll respond soon after that with date/s that
> > works for most.
>
> Sorry for sending this on the last day.
>
> After re-reading the original announcement and the above part, I am
> wondering if responding to the "when is the good time for you?" poll
> is a requirement to be invited.  My tentative understanding is that
> this is merely to help resolove scheduling conflicts, and those who
> want to attend but have no particular time/date preference can just
> stay silent and wait for the invitation to come, to which they are
> required to respond via e-mail in order to attend.
>
> I suspect many people are wondering about the same thing and
> a bit of clarification may help.
>

Thanks for the question Junio.  Yes, this initial solicitation is
merely to get a feeling for what the best times and durations would
be.  It does not mean indication of attendance, registration, or
functioning as an RSVP.  This will come in a subsequent communication,
with a date/s and times chosen based on the survey.  ~C

> Thanks.