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

On 08/02/2012 12:18, David Chisnall wrote:
> Thank you for your thoughtful reply,

You too ... I let some time go by to see what others had to say. I think
it's disappointing that more people aren't concerned about this issue.

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

And yet, that's exactly what happens. It's easy to understand why ...
you have a bunch of people together in the same place, they all agree on
a topic, and after all, since they are the ones who are there, they
should be the ones to make the decision, right?

It's not necessarily that they are trying to do something malicious,
it's just human nature. I know, I used to travel to conferences for a
living.

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

I agree with these points as well. (Again, been there, done that.) In
fact I'm quite confident that a lot of the "issues" people have with me
are related to this deficiency. :)

> Any official conversations happen on the mailing lists. 

This should be true, but it isn't. This is my point.

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

... so far, so good ..

> for a limited set of 'everyone else'. 

... and this is where I call shenanigans. This is an open project.
Anything that is going to be done is going to be seen. If there are
problems with a proposal it's better to see them early. If it's a good
proposal, there is no reason not to share it.

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

In the IETF context proposals often benefit from the real-time focus of
attention, from both local and remote participants, that the meetings
provide. There is no reason to believe that this would not be true in
FreeBSD as well.

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

That's an oft-repeated maxim, especially around here. But we've already
demonstrated that it isn't true. The only time that this is true is if
the work being done is in line with what the PTB want. I've demonstrated
this time after time by volunteering to do various projects "my way" and
being told that my efforts weren't welcome. Not to mention having my
finished, working code reverted by a core team member for an inferior,
broken result.

So can we please stop repeating that BS and focus on the real issues?

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

The community needs to not be accepting of the status quo, and demand
that things be publicized on the lists first before decisions are made.

Once again, if they are good decisions, they won't be harmed by sharing
them in advance. If they are less-good, we could be saving someone
efforts that would be otherwise wasted.

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

Exactly.

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

It's already been explained that this is a soluble problem, and Julian
has already solved it.

The only obstacle at this point is desire of the organizers.

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

That's up to the leader of the session to draw a line. Allowing remote
participation doesn't change this dynamic, as it's actually *easier* for
someone in the room to be a mic-hog; especially if remote input is via
jabber.

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

I think you've covered the tradeoffs. But again, see above on how
allowing remote participation doesn't change anything.

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

In all of the many organizations I participate in, both in person and
remotely, I've never seen this dynamic; primarily because of the
"fringe" benefits you describe so well above. I doubt it would happen in
FreeBSD.

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

I think you're failing to understand the scale of the problem. We have
over 300 unique committers alone, never mind the community of
non-committer developers. Expecting that even a significant percentage
of them will be able to attend any given summit, never mind the one(s)
where the things they care about are going to be discussed, is not
realistic.

Doug

-- 

    I am only one, but I am one.  I cannot do everything, but I can do
    something.  And I will not let what I cannot do interfere with what
    I can do.
			-- Edward Everett Hale, (1822 - 1909)