From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, "Derrick Stolee" <stolee@gmail.com>,
"Junio C Hamano" <gitster@pobox.com>,
"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Subject: Re: Contributor Summit planning
Date: Mon, 13 Aug 2018 20:49:33 +0200 [thread overview]
Message-ID: <87h8jyrtj6.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <20180813163108.GA6731@sigill.intra.peff.net>
On Mon, Aug 13 2018, Jeff King wrote:
> For the past several years, we've held a Git Contributor Summit as part
> of the Git Merge conference. I'd like to get opinions from the community
> to help plan future installments. Any feedback or opinion is welcome,
> but some obvious things to think about:
>
> - where, when, and how often?
>
> Plans are shaping up to have Git Merge 2019 in Brussels right after
> FOSDEM in February (like it was two years ago), with a contributor
> summit attached.
>
> Are there people who would be more likely to attend a contributor
> summit if it were held elsewhere (e.g., in North America, probably
> in the Bay Area)? Are people interested in attending a separate
> contributor summit not attached to the larger Git Merge (and if so,
> is there any other event it might be worth connecting it with,
> time-wise)? Are people interested in going to two summits in a year
> (e.g., Brussels in February, and then maybe some in North America
> later in the year), or is that diminishing returns?
>
> - format
>
> For those who haven't attended before, it's basically 25-ish Git
> (and associated project) developers sitting in a room for a day
> chatting about the project. Topics go on a whiteboard in the
> morning, and then we discuss each for 30-60 minutes.
>
> We could do multiple days (which might give more room for actually
> working collaboratively instead of just discussing). We could do
> something more formal (like actual talks). We could do something
> less formal (like an all-day spaghetti buffet, where conversation
> happens only between mouthfuls). The sky is the limit. Some of those
> ideas may be better than others.
>
> I hope this can stimulate a discussion on the list, but of course if
> anybody has private feedback about past events or future planning, feel
> free to email me off-list.
A few things, in no particular order (also in-reply-to the thread at
large):
* Yeah these are really useful. Let's keep doing them!
* In terms of how many per year & location, I think it's most
interesting to listen to take feedback from top contributors[1] and
check why the people who consistently don't come don't. Whether
moving it to any other location would be useful for them, or whether
they're generally just not interested.
I.e. there's some Venn diagram to be drawn here of people who'd come
no matter where it's held, people who'd only come if it's held at XYZ
location etc., and likely time is going to be just as important for
some as location.
It would certainly be interesting to hear what would make Junio turn
up again, or Nguyễn etc.
* I think we should tread carefully when it comes to say some form of
remote A/V participation open to the Internet.
It was fine to have Dscho on a chair, but it would be quite different
if this were say streamed on YouTube and everyone felt like they were
on stage the whole time, and if offhand comments / jokes etc. were
recorded.
I'm not categorically against that, it's just something to think
carefully about. Maybe if there's demand for it we could dedicate
some time slot to that.
* Re the second half of "Not everyone can travel or can afford to do
so" from Derrick, there's been travel sponsorships in past years.
* In terms of timing, we've had cases in past years where some topic
(say large binary issues or large repo performance) was discussed at
some length in the contributor summit, only to be followed by an
announcement in the general conference (in this case LFS & GVFS)
which was clearly under embargo before the talk given at the
conference.
I've said something to this effect before, but it would be nice if we
could think about some solution to this. I.e. should we always be
holding one contributor summit right after (not before) git merge, so
that we're not pointlessly discussing some area while representatives
from some company or other have to not comment and say "we have
patches for that"?
Or would those companies be OK with trusting that some 20-ish of us
can hold our tongues for one day and not ruin the surprise?
There's also overlap with the remote A/V concerns there. I.e. an
acceptable compromise for those companies might be to talk about
those features freely in the contributor summit trusting that it's a
closed forum, but that wouldn't work if it's going to be broadcasted.
1. git.git$ git log --pretty=format:%aN --since=2018-01-01|sort|uniq -c|sort -nr|head -n 20
[...]
(Yeah this is just git.git, we'd want to do some union of
"contributes to git ecosystem at large" for a proper list, also
number of patches is only a fuzzy metric for contributions blah blah
blah)
next prev parent reply other threads:[~2018-08-13 18:49 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-13 16:31 Contributor Summit planning Jeff King
2018-08-13 16:58 ` Derrick Stolee
2018-08-13 17:15 ` Jeff King
2018-08-27 13:22 ` Johannes Schindelin
2018-08-27 13:30 ` Derrick Stolee
2018-08-28 12:22 ` Johannes Schindelin
2018-08-28 19:06 ` Jonathan Nieder
2018-08-28 19:11 ` Jonathan Nieder
2018-08-29 14:38 ` Johannes Schindelin
2018-08-29 4:52 ` Jeff King
2018-08-29 14:44 ` Johannes Schindelin
2018-08-13 17:46 ` Stefan Beller
2018-08-14 4:31 ` Christian Couder
2018-08-14 14:35 ` Jeff King
2018-08-13 18:49 ` Ævar Arnfjörð Bjarmason [this message]
2018-08-13 19:44 ` Jeff King
2018-08-13 20:36 ` Junio C Hamano
2018-08-13 20:41 ` Stefan Beller
2018-08-13 21:06 ` Jeff King
2018-08-13 21:19 ` Stefan Beller
2018-08-13 21:54 ` Jeff King
2018-08-14 17:43 ` Measuring Community Involvement (was Re: Contributor Summit planning) Derrick Stolee
2018-08-14 19:36 ` Jeff King
2018-08-14 19:47 ` Stefan Beller
2018-08-14 20:06 ` Jeff King
2018-08-15 7:12 ` Eric Wong
2018-08-14 20:42 ` Junio C Hamano
2018-08-27 15:54 ` Johannes Schindelin
2018-08-15 16:28 ` Duy Nguyen
2018-08-27 15:55 ` Johannes Schindelin
2018-08-14 14:30 ` Contributor Summit planning Duy Nguyen
2018-08-14 14:47 ` Jeff King
2018-08-14 16:57 ` Stefan Beller
2018-08-14 20:59 ` Junio C Hamano
2018-08-17 15:18 ` Duy Nguyen
2018-08-27 22:49 ` Johannes Schindelin
2018-08-29 5:02 ` Jeff King
2018-08-14 6:52 ` Elijah Newren
2018-08-14 13:25 ` Randall S. Becker
2018-08-14 14:06 ` Ævar Arnfjörð Bjarmason
2018-08-14 14:30 ` Jeff King
2018-08-14 14:28 ` Jeff King
2018-08-27 13:34 ` Johannes Schindelin
2018-08-29 4:55 ` Jeff King
2018-08-29 14:46 ` Johannes Schindelin
2018-08-30 3:20 ` Jeff King
2018-08-30 11:36 ` Johannes Schindelin
-- strict thread matches above, loose matches on Subject: below --
2018-03-03 10:30 Jeff King
2018-03-03 10:39 ` Jeff King
2018-03-05 14:29 ` Derrick Stolee
2018-03-05 17:01 ` Brandon Williams
2018-03-05 18:29 ` Lars Schneider
2018-03-05 18:53 ` Jonathan Nieder
2018-03-05 22:13 ` Ævar Arnfjörð Bjarmason
2018-03-05 21:57 ` Ævar Arnfjörð Bjarmason
2018-03-05 14:34 ` Ævar Arnfjörð Bjarmason
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
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 \
--in-reply-to=87h8jyrtj6.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
--cc=stolee@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://80x24.org/mirrors/git.git
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).