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

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"