Re: On cooperative work [Was: Re: newbus' ivar's limitation..]

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.  

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.  

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.  

> 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.  

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...  

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