Date: Thu, 2 Aug 2012 20:18:10 +0100 From: David Chisnall <theraven@freebsd.org> To: Doug Barton <dougb@freebsd.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] Message-ID: <0F923CD6-BCF1-4722-8E4A-9485A7D6E279@freebsd.org> In-Reply-To: <501AC7EF.4070605@FreeBSD.org> References: <CACqU3MUh1XPScRHNc-ivOYLmbG0_UqpwBNWeoPA84uSOESH_bg@mail.gmail.com> <CAJ-FndCHxpTfc%2Bb5zgiX2NheaQN1LcJXBRubef4_GAYCy_pb2g@mail.gmail.com> <CACqU3MWo=ieaduuwZDF6SfzUUS5y1qzP5e2Ddg6Aphnz_O2PJw@mail.gmail.com> <CAJ-FndCDpD3rnQFwiOSGofP9cPCxC5Zo%2BPLfxALY8pnE=2HQMA@mail.gmail.com> <CACqU3MW2JEtDK0Ngdf_Br6D%2BVvdU1B9LmN0fm0F9=bG0f2iW4Q@mail.gmail.com> <CAJ-VmomhHxG8t9Sw7de%2BzUnbz0O5GSY4ifpHFtCb9JS_zS0rBA@mail.gmail.com> <CACqU3MUKGcy8rNz0FcZLVat49BmRLD3hVKX%2BOXxkzwRDugKtAw@mail.gmail.com> <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <CACqU3MU-WyNFf5UZGx15m_HWBx_6W272qkfqHHJ8G7v%2BJCK2Sw@mail.gmail.com> <FAE07410-CA99-4061-856F-799DB9D225BE@bsdimp.com> <501A0258.4010101@FreeBSD.org> <CA622462-DB69-40E4-9E1D-A4D83AEB12F8@theravensnest.org> <501AAEF2.8060202@FreeBSD.org> <DB8DF40B-BEFE-4BA3-A79B-27E2ECA31DC3@FreeBSD.org> <501AB8C0.3020102@FreeBSD.org> <AD003A7C-E122-4C8E-8EC6-E83AA1163610@freebsd.org> <501ABD43.5090604@FreeBSD.org> <C84BFA15-9FEA-49E8-919A-F4A810EAAF09@free! bsd.org> <501AC7EF.4070605@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0F923CD6-BCF1-4722-8E4A-9485A7D6E279>