From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 19:18:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 382BA106566B; Thu, 2 Aug 2012 19:18:21 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 009438FC0A; Thu, 2 Aug 2012 19:18:20 +0000 (UTC) Received: from [192.168.0.2] (cpc2-cmbg15-2-0-cust445.5-4.cable.virginmedia.com [86.26.13.190]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q72JIFcV080280 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 2 Aug 2012 19:18:19 GMT (envelope-from theraven@freebsd.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: David Chisnall In-Reply-To: <501AC7EF.4070605@FreeBSD.org> Date: Thu, 2 Aug 2012 20:18:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0F923CD6-BCF1-4722-8E4A-9485A7D6E279@freebsd.org> References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <501AAEF2.8060202@FreeBSD.org> <501AB8C0.3020102@FreeBSD.org> <501ABD43.5090604@FreeBSD.org> <501AC7EF.4070605@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1278) Cc: FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 19:18:21 -0000 Thank you for your thoughtful reply, On 2 Aug 2012, at 19:33, Doug Barton wrote: > However, my point is that in spite of the fact that it's non-trivial, > the mindset on this topic needs to change if the dev summits are going > to continue to be significant focii of both work being done and > decisions being made (which of course, they are). I believe that, before that decision can be made, there needs to be some = consensus on what the purpose of the DevSummits is. In my view, = DevSummits do not exist to set project policy. They are places where: - People can talk face to face about their current and planned projects. - Developers can meet on a social basis, making remote working easier. The latter is very important - I've found in other projects that it's = far easier to work with someone on the other side of the world when = you've chatted with them over a few beverages-of-choice. =20 Any official conversations happen on the mailing lists. DevSummits are = for people working on similar things to meet and discuss their plans, = and for people to have a chance to get to know what everyone else is = doing, for a limited set of 'everyone else'. Slides and summaries so on = from the more structured parts of this are available afterwards, which = helps people who can't attend get the same benefit - they know what = other people are working on. The original complaint that spawned this long discussion was that = decisions about the project are made behind closed doors. This is = obviously true in the literal sense, as code always wins over chatter in = an open source project, and the person willing to sit down and write the = code gets the final say on how it should work, although ideally with = code review, design feedback and so on from others. Even if we = broadcast everything that happens in the official parts of the = DevSummits, that won't necessarily fix anything because a lot of the = most productive conversations happen over dinner or in the pub. =20 If there is a real problem to address, then it is people making policy = decisions at DevSummits, without adequate consultation. I have not = observed this happening, but I would regard it as no different to people = making policy decisions via private email, and something that should be = subject to the same response: revisit the decisions in public if there = are legitimate concerns raised about it, subject to the usual open = source rule that the person actually willing to do the work gets to make = the final call. > What I'm *not* doing is demanding that any one person, or even any one > group take responsibility for solving the whole problem on their own. > Unfortunately, due to my inability to actually attend these meetings, = I > won't be able to provide the kind of hands-on assistance that I'd like > to be able to. However it sounds like there may be financial resources > available through the foundation, which would go a long way towards > making a solution possible. Finance is not the only obstacle. In some venues, bandwidth is a = problem (not at Cambridge hopefully - people will have stopped using it = all to stream the olympics by then), but in other venues we only have = WiFi, which is shared with a room full of developers. If we buy some = equipment (decent microphones are not always available - we were unable = to find one at FOSDEM for remote attendees, for example), then it would = need to be transported between events, and someone would need to be = responsible for looking after it and ensuring that it is set up = correctly at each event. =20 > The next step would be for people to agree that this is a problem that > *needs* to be solved, followed by willingness on the part of dev = summit > organizers to support these efforts, which will hopefully lead to = people > who are willing and interested to step up and actually provide > solutions. It's already been true in the past that various companies > have volunteered to do this. There is no reason to believe that it > wouldn't happen again if organizers are willing to be supportive. There are two proposals: Remote viewing and remote participation. = Remote viewing, being non-interactive, does not have to be done via = streaming, it can be done by recording the event and making it available = online. Even this is not trivial: we've done it for the GNUstep devroom = at FOSDEM most years, and it typically takes a long time to get the = videos edited and uploaded. ARM sent a professional team to do it at = EuroLLVM, and yet they didn't have enough equipment to cover everything = (my tutorial, for example, was not recorded). I would say that this is = something that is very useful for presentation-style events, but = DevSummits are typically more round-table discussions and hacking = sessions than presentations. Remote participation is bidirectional, and I am a lot more wary about = that. The productivity of a meeting is usually inversely proportional = to the number of attendees, and allowing a lot more people in does not = necessarily improve anything for anyone. It's always tempting to speak = up and make A Contribution (I have certainly been guilty of this in the = past, and no doubt will be in the future) when really the meeting needs = everyone to shut up and move on to the next item. The main advantage of = the small group meetings is that they don't degenerate into bikesheds as = easily. Of course, the down side is that they also lack any kind of = mandate because they are not including everyone's opinions, which is why = summaries are posted on the wiki and linked to from the mailing list so = that longer discussions can take place online. Encouraging remote participation also has the unintended side effect of = discouraging real participation. I've seen in other projects that when = you try to make remote participation easy it means a lot of people think = 'well, I can just join in remotely, I don't need to make the effort to = turn up'. This is why I think we have about the right balance for the = Cambridge DevSummit. We have a few people (e.g. Dru, Warner) who would = benefit from being there (and whose presence the community would benefit = from), but who are unable to make it. We have set up something so that = they can (hopefully!) join in remotely, but this is very much a = second-choice option. Ideally, we'd see all of the remote attendees in = person. =20 If the majority are not present in person, then we may as well not have = a DevSummit at all, and just have a regular conference call that's open = to all. Or, to save bandwidth, a mailing list or IRC channel... =20 If anything, I suspect a large number of remote attendees would end up = having the opposite of the desired effect, and mean that the vast = majority of the actual decision making would take place in the pub after = the official meetings, where it won't even be reported on the mailing = lists until the commits start landing. David