Trying to understand the motivations and implications underlying the RFC

[megele]

First off, let me emphasize that among all the conference-running organizations USENIX is by far my favorite. Their excellent staff runs conferences in a way that makes all others pale and the set of accepted papers at USENIX Security aligns the most closely with my (of course subjective) interests. I've attended many USENIX Security conferences in the past and was lucky enough that sometimes the program committee felt that I or my students should get the opportunity to present our work to the USENIX Security audience. For all of that I am deeply grateful.

As the RFC asks for community input, I am creating this "issue" to do just that. After reading the USENIX Annual Meeting Report and the RFC, I came away wondering what the motivation for the proposed change of format is. At this point in time, I hold a quite negative view of the proposal. However, I am looking for information that can either help me view the proposed format more positively, or motivate change to the format to something I can view positively.

To better relate to the proposal, I would like to understand the motivation that ``necessitate(s)'' this specific change. I turned to the RFC and found that it provides a single sentence on the motivation.

Rising conference costs and increasing numbers of submitted and accepted papers necessitate USENIX Security shifting to a format with fewer parallel talk session tracks (see the 2023 USENIX Annual Meeting Report).

To my reading there are three aspects comprising the motivation:

1. Rising conference costs
2. no. of submitted papers
3. no. of accepted papers

These three concerns are also reflected to some extent by the Annual Meeting Report.

Dissecting these three aspects individually illustrates why I struggle to draw the the same conclusion as the RFC regarding possible formats.

1. Rising conference costs

is undoubtedly a valid concern. Inflation etc. affected all aspects of life and it is thus natural that the costs to execute a conference rise. Combining this with the forecast of imminent budgetary shortfall prognosticated in the Annual Meeting Report suggests that USENIX Security cannot continue growing as it did in the past (e.g., by adding more parallel tracks). Thus, economics seem to dictate that growing the conference is not an option.

2. no. of submitted papers

is not necessarily a concern that affects the conference execution. That is, the USENIX Security program committee chairs grew the program committee over the years and the review load has remained manageable and might have even improved/lowered over recent years (based on my subjective experience).

3. no of accepted papers

this number is controlled by the program committee & chairs and the steering committee. To the best of my knowledge, there is no law of physics or law/rule/guideline of economics that says the number of accepted papers must increase.

Of course, in support of 3. the Annual Meeting Report says:

This growth is exciting, and both the security community and USENIX want to see the number of accepted papers continue to grow as the community expands.

I would like to learn about the data supporting this claim, specifically as it relates to the security community's want. As a frequent reviewer and occasional (co-)author of USENIX Security papers, recurring attendee of the conference and paying USENIX member ;-), I take the liberty to consider myself part of the USENIX (Security) community. As such a community member, I do not recall having been asked, as part of any of these roles, whether I would like to see more papers accepted, much less so if the implication of more accepted papers is that the majority of papers will get a 1-minute slot of presentation plus a poster. Of course, it is entirely possible (maybe even likely) that I missed the relevant correspondence. In that case, a pointer would be much appreciated.

In summary, disregarding 2. as a non-relevant concern (for the purpose of the RFC only!), recognizing that 1. is a fact of life (or at least economics), and realizing that 3. is malleable by the PC chairs/steering committee could suggest that by adapting 3. USENIX Security could continue to run as it did over the last few decades.

Of course, such adaptation would entail a slew of consequences many of which would require careful consideration (e.g., as part of a community discussion?). Thus, this post should not be seen as a call to making USENIX Security even more selective but should rather serve to illustrate that the solution space is larger than outlined in the RFC. At the end of the day, this post reflects my exercise in trying to understand the motivations and their alleged implications that underlie the RFC.

[rahmati]

I second this. I think there are many people in the community who prefer a smaller, higher-quality USENIX Security conference to a large carnival of posters. There are plenty of security conferences out there. Limiting the number of accepted papers will allow those conferences to similarly increase their average quality of publications and can motivate new, specialized conferences. The proposal, as it currently stands, is detrimental to both Usenix Security as a conference and the larger field in general.

[tgianko]

Thank you very much for sharing your feedback with us. We updated the FAQ section and added an item addressing the problem that we are trying to solve.