Re: [LSFMMBPF TOPIC] Killing LSFMMBPF

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Mar 06, 2020 at 09:35:41AM -0500, Josef Bacik wrote:
> [a lot of stuff I agree with]

> 4) Presentations.  90% of the conference is 1-2 people standing at the front
> of the room, talking to a room of 20-100 people, with only a few people in
> the audience who cares.  We do our best to curate the presentations so we're
> not wasting peoples time, but in the end I don't care what David Howells is
> doing with mount, I trust him to do the right thing and he really just needs
> to trap Viro in a room to work it out, he doesn't need all of us.

... and allow the other 3-5 people who're interested or affected the
opportunity to sit in.  Like a mailing list, but higher bandwidth.

> So what do I propose?  I propose we kill LSFMMBPF.

I come not to bury LSFMMBPF but to reform it.

As Jason noted, Plumbers is already oversubscribed.  I think having two
Plumbers conferences per year (one spring, one autumn), preferably on
two different continents, would make a lot of sense.

Here's my proposal, and obviously I'm not seeking _permission_ to do
this, but constructive feedback would be useful.

1. Engage an event organiser to manage the whole thing.  I have a friend
who recently took up event organising as her full-time job, and I've
started talking to her about this.  It's a rather different skill-set
from writing kernel patches.

2. Charge attendees $300 for a 3-day conference.  This seems to be the
going rate (eg BSDCan, PGCon).  This allows the conference to be self-
funding without sponsors, and any sponsorship can go towards evening
events, food, travel bursaries, etc.

3. Delegate organising the sessions to the track chairs.  Maybe get rid
of shared sessions altogether -- while there are plenty of times where
"I need fs and mm people in the room", it's rarely "I need everybody in
the room", and scheduling BOFs opposite such a general session would be
a good use of peoples time.




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux