On Sat, Jul 1, 2017 at 1:57 PM, Daniel Pocock <daniel@pocock.pro> wrote:

There are also SDR topics that don't involve ham radio.

Indeed, however for a FOSDEM conference (software) Ham without software is just Ham and has no place at FOSDEM. With software it's SDR. All the non-digital radios that most hams use are all proprietary, so unless there's suddenly a huge scene for that, I don't think this belongs at FOSDEM. Just my opinion anyways. Good luck!

James, As Daniel already pointed out, there is quite some open-source development in the ham-radio community. Anycase, my goal is not to make FOSDEM a ham-radio event. There already exist quite a few of hamventions so there is shortage of that. The big difference is that FOSDEM is a DEVELOPER conference, which is -I think- something that the ham-radio community does not have. My idea is to try to get people together who are involved in actual development of open-source ham-radio related software and hardware projects and focus the talks on subjects of actual software and hardware development. As far as I know, this is something that does not yet exist and would fit in the idea of FOSDEM. Hence my qyestion, what are the requirements to start a devroom? Who should be contact for this? Kristoff On 01-07-17 20:43, James wrote:

On Sat, Jul 1, 2017 at 1:57 PM, Daniel Pocock <daniel@pocock.pro> wrote:

...

There are also SDR topics that don't involve ham radio. Indeed, however for a FOSDEM conference (software) Ham without software is just Ham and has no place at FOSDEM. With software it's SDR.

All the non-digital radios that most hams use are all proprietary, so unless there's suddenly a huge scene for that, I don't think this belongs at FOSDEM.

Just my opinion anyways.

Good luck! _______________________________________________ FOSDEM mailing list FOSDEM@lists.fosdem.org https://lists.fosdem.org/listinfo/fosdem

James, 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). Cheerio! Kr. Bonne. On 01-07-17 15:55, James wrote:

On Sat, Jul 1, 2017 at 9:39 AM, Kristoff <kristoff@skypro.be> wrote:

...

Dyring fosdem 2017, the amateur-radio society of Belgium has an infobooth to promote amateur-radio at fosdem. (thanks again to the people at fosdem to allow us to do this).

I have had an idea in the back of my mind for some time to go a little bit further in this and look at the possiblity to set up a (small) devroom for amateur-radio related topics and open-source/free software and hardware.

There's already a `software defined radio` room. I think this subject belongs there. Please see:

https://fosdem.org/2017/schedule/track/software_defined_radio/

Thanks, James

On 01/07/17 21:44, Mark Van den Borre wrote:

Hello Kristoff,

2017-07-01 21:10 GMT+02:00 Kristoff <kristoff@skypro.be>:

...

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. [...] So I am still a bit puzzled on how to see this and how to do this the best. (hence my question here). In general, keep an eye on the call for proposals to appear to submit a devroom request.

You can always try to ask for a separate devroom and explicitly mention this is coordinated with SDR and for one year only. That might have a non-zero chance of getting accepted.

But the hard truth is that we're always receiving several times the number of applications, and we often have to disappoint people...

One thing I raised on the devroom-managers list last year[1] was the idea of grouping talks by tags/themes that span multiple dev-rooms, that may help in a situation like this and also the general question of congestion at FOSDEM. Given the level of competition that exists for dev-rooms, why not consider abolishing them completely and having talks grouped by tags? So, a talk about the gqrx software might have tags "sdr", "ham", "python" A talk about WebRTC might have tags like "voip", "sip", "javascript" and "mozilla" Pages could be created on fosdem.org for each tag. A page for the "javascript" tag would include the WebRTC talk, but it would also include any talks in the PostgreSQL dev-room that involve embedding JavaScript in the database (PL/v8). Another thing to bear in mind is that there are hams in just about every significant community at FOSDEM, even if they don't come to FOSDEM for ham purposes. Regards, Daniel 1. 540a1880-5747-eaf8-688c-d62bc9626781@pocock.pro

On 02/07/17 00:48, Wouter Verhelst wrote:

On Sat, Jul 01, 2017 at 10:01:29PM +0200, Daniel Pocock wrote:

...

Given the level of competition that exists for dev-rooms, why not consider abolishing them completely and having talks grouped by tags?

That misses the reason for the existence of devrooms in the first place.

It's not "to group talks of the same subject in the same room", although that's an interesting side effect of them.

Instead, devrooms are organized by people who are not part of the FOSDEM team. This means we can delegate things like hunting down speakers, getting them to confirm they'll be at the event, building schedules based on the constraints of those speakers (some of whom will have to leave early or have more than one talk, etc etc) and on things like "these two talks are about generally the same subject", and a whole slew of other things.

If the devrooms were organized by the FOSDEM team rather than by the devroom organizers, the amount of work that would have been done by the core team would quickly be more than we have time for. And besides organizing the schedule, we also have to deal with a large number of other matters involved in the schedule.

If you can come up with a way to improve coordination across devrooms so that talks can more easily be moved from one devroom to another, then by all means do suggest, and we'll see what we can do; but any such scheme that would involve "more work from the core team" is doomed before it will even get started, because that's just not an option.

This suggestion didn't make any comment about how the work would be done, there was no part of my email that suggested the work would be shifted to the core team. To completely put the idea into practice, it would be important to consider how to engage existing dev-room managers to manage the tags and/or rooms. Even without abolishing dev-rooms, it would still be possible to create tags for the talks in each room (e.g. some talks in the SDR room may have both an "sdr" and "ham" tag and some talks in other dev-rooms may have a "ham" tag too) and produce index pages on fosdem.org for every tag. Then if the Ham topic didn't get a dedicated dev-room, people interested in that topic could still see a list of all talks tagged "ham" in other rooms. Regards, Daniel

On 07/04/2017 02:58 AM, cluker@plus.net wrote:

'Even without abolishing dev-rooms, it would still be possible to create tags for the talks in each room (e.g. some talks in the SDR room may have both an "sdr" and "ham" tag and some talks in other dev-rooms may have a "ham" tag too) and produce index pages on fosdem.org for every tag. Then if the Ham topic didn't get a dedicated dev-room, people interested in that topic could still see a list of all talks tagged "ham" in other rooms.

Regards,

Daniel'

This idea would absolutely get my backing, especially as due to the nature of the rooms ULB has available, some tracks must be in small rooms despite being popular. A tagging system that would let people assess talks by the content rather than the location seems to have a lot of potential.

Running a devroom also involves a lot of logistics, such as kicking people out when there's too many, reminding people to pick up trash, making sure all the talks are on time, etc. All of this is much easier when there's a devroom team running the devroom that's also familiar with all the topics and some of the speakers. Basically, I would recommend not doing anything that adds any amount of friction to the process. I'm assuming all devrooms are pretty much full all the time anyway; plus, they get recorded. And on top of that, FOSDEM orgs have been pretty good about accepting interesting talks into the main tracks. Your idea sounds good, but I doubt it adds more value than it adds overhead. Cheers, Martin

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

Hallo Martin, (inline reply) 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.

To be clear, it wasn't me who linked the "ham-radio" with the SDR devroom. I understand the confusion by certain people (after all, both have the name "radio" in it), but -as mentioned- my idea is about the ham-radio related software that is not SDR related: digital-voice, digital-modes, pskmail, mesh-network, radio-over-ip, remote station-control, ... The ham-radio info booth we have had at fosdem started out as a small "get together" by a number of hams who visited the SDR devroom in 2014 (or was it 2013?). The last think I want to do is "compete" with the SDR devroom. That is surely not my goal. (...)

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.

Well, to be honest, the last two years, I had a fulltime job maning the infobooth (sometimes you need to make choices in life :-( ) so must admit that I have completely missed outmost all talks. But, as mentioned, one of the main reasons I queried about the possibility for a ham-radio devroom was simply not to "highjack" the sdr-devroom. There is quite some ham radio-related application that do not fit in the "SDR box".

To be clear: I realise you weren't criticizing the SDR devroom or FOSDEM, ... Thank you. That was indeed not my intention at all :-)

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? The reason I queried about this was -as my original mail mentioned- simply to get an idea what would be the requirements to do this, this to determine if it would make sence to talk about this wil certain developers I know.

Let's start there.

Cheers, Martin Cheerio! Kristoff