From: Taylor Blau <email@example.com>
To: Eric Wong <firstname.lastname@example.org>
Cc: Carmen Andoh <email@example.com>,
firstname.lastname@example.org, Jonathan Nieder <email@example.com>
Subject: Re: Git Inclusion Summit
Date: Mon, 27 Jul 2020 11:10:23 -0400 [thread overview]
Message-ID: <20200727151023.GB62919@syl.lan> (raw)
On Sun, Jul 26, 2020 at 04:02:26AM +0000, Eric Wong wrote:
> Carmen Andoh <firstname.lastname@example.org> wrote:
> > Hello Git community,
> > There's been some conversation about holding a virtual contributor
> > summit focused on inclusion . 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  "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  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
> 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
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...
next prev parent reply other threads:[~2020-07-27 15:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-23 19:30 Git Inclusion Summit Carmen Andoh
2020-07-23 20:59 ` Jonathan Nieder
2020-07-23 22:26 ` Junio C Hamano
2020-07-24 12:55 ` Carmen Andoh
2020-07-26 4:02 ` Eric Wong
2020-07-27 15:10 ` Taylor Blau [this message]
2020-07-28 10:07 ` Eric Wong
2020-07-28 16:25 ` Taylor Blau
2020-07-28 17:15 ` Kaartic Sivaraam
2020-07-29 17:00 ` 24 hours to respond with date/duration preferences for inclusion summit Carmen Andoh
2020-07-29 18:25 ` Junio C Hamano
2020-07-29 19:29 ` Carmen Andoh
2020-07-28 16:44 ` Git Inclusion Summit Jeff King
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).