[lsb-discuss] Resuming LSB F2F work sessions

[R P Herrold]

trimming mercilessly and adding [X] to get reference marks

On Tue, 2 Dec 2008, Wichmann, Mats D wrote:

> [A] The former... my experience from the past is we need to
> get together in a room in order to make certain leaps forward
> in closing out issues. ...

> [B] So I'm going to make the proposal that in 2009 we resume
> the LSB workgroup F2F sessions, that we've at various times
> called things like "working meeting", "sprint", "hackfest",
> etc. ...

> [C] I know times are tough financially, and it may be concluded
> that we can't afford to pull this off, or can't do as many
> as three in 2009 (which would be my proposal). ...

> [D] But let's first see if anyone agrees with me as to need.

D -- the bandwidth and lags of email and even IRC are 
undeniable; the weekly call seemed frozen last time however on 
issue resolution, for reasons that were not so clear to me.

B -- higher commo bandwidth, and the ability to get the 
additional feedback of voice, and common visuals are PART of 
the 'working in a bullpen' model.

That said, with a good and free PBX (this pre Asterisk, with 
Inter-Tel ipphones through the VPN) and fast data links with 
Axis webcams over a VPN, I have run teams spread across 
Chicago, Cleveland, Columbus, and Naples -- also in leading 
the team, I pushed for and got a strong commitment to using 
and clearing a bug tracker with email notifications as to 
tasked items

(I know -- Mats has the issue of the Satellite ISP; dunno how 
to solve that one)

Having an 'open channel' "Squawk Box" party line is doable 
fairly minimally -- we are in process deploying one with 
global coverage for one project I participate in, for similar 
reasons of co-ordination and core developer 'higher bandwidth' 
feedback.

C -- better common infrastructure may avoid the need for 
(expensive in $$ and time) physical travel

A -- there is also the Zeno's Paradox rule:  the first 80 % of 
a project takes the first 80 % of the time allotted, and then 
the next 80 % of the remaining 20 % takes another 80 %, and ...

The balloting (in part to to cull the release features) 
trimmed the length of the piece of string to be shipped in 
4.0; perhaps a prioritizing and second (and repeated every X 
interval) round of cuts to get the 'distance to goal' against 
Release Plan Featureset under control is needed.

I guess this is another way of saying that to some degree an 
EOY ship is a calendar driven, rather than a Functionalities 
driven approach;  it may be sensible to scale resources 
available to feature attained at a cut-point date, rather than 
trying to ship all the string initially envisioned.

My $0.02

-- Russ herrold