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)