[FOSDEM] requirement to start a devroom

[Daniel Pocock]

On 06/07/17 20:47, Martin Braun wrote:
> On 07/01/2017 12:10 PM, Kristoff wrote:
>> Correct. In fact, the ham-radio infobooth we have had started out as an
>> idea of some people who participated in the SDR devroom in 2014.
>>
>> But, as also replied by Daniel, amateur radio is more then
>> signal-processing (SDR). There also is (e.g.)  digital voice, digital
>> keyboard-to-keyboard communication modes, weak-signal communication,
>> satellite-trackers, mesh-networking, repeater-linking-networks, and many
>> other things.
>> But I do agree that the ham-radio topics do overlap quite a bit with
>> existing devroom: the SDR devroom, the EDA (electronic-design
>> automation) and the "embedded" devroom.
>> Another element in this is that the SDR devroom is already quite loaded.
>> Adding ham-radio-but-not-related-to-sdr topics to that devroom is
>> probably not a good idea.
>>
>>
>> So I am still a bit puzzled on how to see this and how to do this the
>> best. (hence my question here).
> 
> As the guy who's organized the SDR track for the last few years, I would
> have appreciated if you had pinged me on this too.
> 

You've been doing a great job - my talk in your dev-room had more
attendance than the talk I gave in our RTC dev-room this year :)

> Note that not only have we had multiple ham-related talks in the past
> (including Daniel's), but also have I made sure to invite select members
> of the ham community directly whenever I sent out the CfP. I don't know
> that many European hams, but I've also asked people to forward CfPs to
> their respective communities.
> Now, of course you're right that ham software includes more than just
> SDR, but if you've followed the SDR track in the last couple of years,
> you'll have noticed that we have all kinds of talks, including
> FPGA-specific ones, embedded Linux, and other non-DSP talks. Besides,
> our mission was always to get people from various communities together,
> such as telecomms, DSP, academia, and also hams.
> An excellent talk about satellite tracking software wouldn't stand out
> our program. A non-excellent talk about satellite tracking software
> probably wouldn't be accepted, though, because we also have plenty of
> submissions and have had to turn down talks. Our devroom has always been
> packed, both in terms of attendees as well as schedule.


How would you feel about a slight name change, maybe "SDR and Ham
software dev-room"?  Would you want to have people like Kristoff join
the admin team for the room?  The RTC room had 4 admins this year, this
makes it easier for people to take breaks.


> To be clear: I realise you weren't criticizing the SDR devroom or
> FOSDEM, but rather making a suggestion. Creating a ham-specific devroom
> would mean, though, cancelling something else. So what should it be?
> Python devroom? Or the embedded devroom?
> I'm being facetious, here, of course, to emphasize my point. Also, do
> you really think that there will be 15-ish good speakers ready to speak
> about non-SDR-related-but-ham-related stuff with an excellent
> presentation? Even with broad subjects, it's some work to get a good
> lineup of speakers.
> 

Actually, as the FOSDEM team already commented, they do chop and change
dev-rooms every year.  So either RTC dev-room or the SDR dev-room could
be skipped in 2018.

In fact, we used to have separate Telecoms and XMPP dev-rooms (1 day
each) and they were combined into a single day (RTC dev-room).
Distributions used to have their own dev-rooms but now they get squeezed
into one room.

> For next year, I fully intend to propose another SDR devroom, and will
> also, as usual, invite hams. We can broaden the CfP to make that clear,
> too. Let's just increase the competition for slots, and make sure we get
> the best speakers. And if a talk about satellite tracking lands in the
> SDR track, oh well, what's the big deal. We'll put it after the talk on
> satellite ground stations if we have another one of those.
> 

One thing we tried with RTC the last two years is reducing talk slots to
20 minutes, like TED talks.  Then we don't have to turn away so many
speakers.  I understand some demos need more than that, up to a full
hour, but we felt good about this in the RTC dev-room.

Regards,

Daniel