Follow

Last year, there were 80 events using pretalx (that I know of), and this year we are already up to 43. Waking up and noticing that people use software you have written is surreal. (That's why I keep a list at github.com/pretalx/pretalx/wik)

Thoughts: Apparently there will be more events using pretalx this year than last year.
When will this trend reverse? What will lead to it? How slow will the decline be, and how will it impact project management and the time I put into it?

It's weird to think about the life cycle of a project that impacts your own life so much.

Show thread

@rixx Even if people stop using your project because something better has come along (it looks far out at the moment), you'll already have benefitted an enormous number of people in their event planning.
Even if it stops now, I think you have accomplished a ton to be proud of.

@solarkraft Oh yeah, I'm not worried about impact or benefitting people. This is more me musing about how I'll go about shutting down this project eventually, just because it's hard to imagine right now. Not feeling sad about it, more curious.

@rixx Fun fact: I always have to adjus my mind when you talk about conferences (or events, here), because I'm acustomed to "academic" conferences, that work completely different in setup. It's fun, tho, and your stuff seems pretty good.

@krono Oh, interesting – one or two academic conferences do use pretalx, but it's not common yet. What would you point out as main differences?

@rixx That's a longer chat. If you want, ping me and we can chat about that, like, after the night :)

But first thing: the speakers pay.

@krono @rixx My "first thing" would have been that those ending up as speakers first have to write a lengthy piece of text that describes months of research preceding its having been written, and that has undergone at least one more or less random review cycles before eventually having been accepted for publication and presentation. Second thing, granted, they pay. 🤷‍♂️

@haupz @rixx Yea, that's right. I just remembered a twitter convo some years ago where _this_ difference was reason for some severe incommensurability…

@haupz @rixx Which might have colored my answerd. That said, I'm too tired atm for a proper writeup or so :D

Hm, two very different points.

Regarding the peer review and the lengthy piece of text: pretalx can set minimum limits on text supplied, and offers additional fields, e.g. to ask for proof of publication, so I don't quite see how this would be an issue, @haupz. Could you explain?

@krono, handling payments and check-ins is hard™, so this won't be part of pretalx, but it *is* what pretix is for, and I know plenty of events running them side-by-side.

@rixx @krono I was referring to the more fundamental difference between academic and industrial or community conferences; this was not related to pretalx. Apologies, that wasn't too clear.

@rixx Oh, apropos! *pretalx-Installationsgeräusch*

Frage, die du (wirklich!) gern auch nach dem Wochenende beantworten kannst:

Ich folge der Anleitung zur manuellen Installation, und bei dem rebuild-Schritt werden die statischen Dateien standardmäßig in /var/pretalx/.local/lib/python3.8/site-packages/static.dist geschmissen, was für mich komisch aussieht... ist das so gedacht?

@blinry Hm, jein – wir können nicht wirklich raten, was für ein System Leute fahren, deshalb ist es schwer zu sgen, wo die statischen Dateien hin sollen. Dieser Ort (wie auch der für die Medien-Dateien) muss über die config gesetzt werden. Eine Beispielconfig ist in der Installationsdoku (docs.pretalx.org/administrator), alle Optionen findest du hier: docs.pretalx.org/administrator

@rixx Danke! :) In der Beispielconfig ist static nicht gesetzt, das wär vllt gut, dort zu erwähnen, dass Leute sich einen Ort definieren sollten.

Auf docs.pretalx.org/administrator ist wahrscheinlich ein Tippfehler: "statics".

@blinry Hmm, aber `static` sollte von `base` abgeleitet sein, dh auch wenn static nicht gesetzt wird, sollte sich das im expliziten base-dir befinden.

@rixx Sowas hätte ich wahrscheinlich auch erwartet. Aber der rebuild-Befehl kopierte dann den Krempel in das Verzeichnis im ersten Toot. Mit explizitem Setzen geht's jetzt aber, wollte das nur für die nächsten Leute etwas smoother machen.

(Wollte mal probiereren, ob wir pretalx vllt für enthusiasticon.de verwenden könnten. \o/)

@blinry Oh, hm, die Doku gibt dir Recht, das wird normalerweise nicht von dem base-dir abgeleitet. Mutmaßlich, weil media-Dir und sonstiger Kram im base-dir alles ist, was man backuppen sollte, aber das static-dir nicht.

Ich vermute, die beste Lösung ist, den default zu lassen, aber `static` mit in die Beispielconfig zu setzen, als /var/www/pretalx oder so?

Und yay für pretalx für enthusiasticon! Einfach poken, wenn dir sonst noch was auffällt/fehlt/usw :)

@rixx Hab mich jetzt durch alles durchgeklickt, alles mal ausprobiert – und das benutzt sich sehr, sehr smooth! <3 Glaube, das wird viel weniger Arbeit als die letzten Jahre, wo Dinge via Google Forms abgefragt, in Exceltabellen geschrieben, im CSV-Format herumkopiert und mit einem custom tool aus dem !!Con-Umfeld gereviewt wurden, wo man immer aufpassen musste, nicht mit der ID zu verrutschen... :P

@rixx Der Anonymisierungsprozess war dafür dort sehr ausgefeilt – eine Person ist alles Eingereichte nochmal durchgegangen und hat alles anonymisiert, was versehentlich nicht anonym war. Das können wir glaube ich mit den Reviewphasen gut nachbauen, und pretalx' "Event-Organizer" ist dann halt der Anonymisierer.

@rixx Außerdem erfuhren bei dem alten Prozess die Reviewer nur die Namen der Vortragenden der tatsächlich angenommenen submissions (um zB re-submissions im nächsten Jahr weiterhin anonym zu halten). Da muss ich mir mal was ausdenken, wie wir das lösen könnten. In keiner Phase die Namen auflösen, und dann stehen die public erst im Schedule drin?

Den Prozess hat Erty mal hier aufgeschrieben: organicdonut.com/2018/03/the-c

@blinry Woop, da Feedback freut mich sehr!

Zum Review-Prozess: Ja, dann würde ich die für die Reviewer einfach nie die Namen anzeigen lassen, wenn nicht kritisch ist, dass sie sie schon vor Publikation erfahren. Dafür dann vllt einfach ein "Anonymizer"-Team anlegen, das muss ja dann nur die Rechte haben, Einreichungen zu sehen und zu ändern.

Das Problem, das ich am Horizont sehe, ist das manuelle Anonymisieren: Super sinnvoll, aber muss man dann halt fürs Release wieder rückgängig machen :\

@blinry Dafür bräuchte es einen eingebauten Anonymisierungsschritt … der sicher sehr sinnvoll wäre, aber uff ;)

@blinry Du hast vielleicht noch ne Meinung zu einem anderen Anonymisierungsfeature, das ich überlege:

Gerade werden die Einreichenden ja einfach ausgeblendet, wenn anonymisiert wird. Ich hatte überlegt, sie durch Pseudonyme zu ersetzen (Tiere wie in gdocs, oder so?), damit immer noch ersichtlich ist, wenn jemand mehrere Einreichungen drin hat.

@rixx Ich stell's mir so vor, dass das beim Reviewen selbst vllt erstmal unerheblich ist.

Aber gegen Ende kommt dann wahrscheinlich eine Phase, in der wir mit allen Reviewern in nem Videocall hängen, und (vermtl. ich) sowas sagen werde wie "Okay, die drei Vorträge X, Y, Z sind von der selben Person, da müssen wir mal fragen, welche sie halten mag". Wenn ich da sagen könnte "Die drei Vorträge von Fiberglass Lemonade" (mein RC-Anonymisierungsname :D), wär das praktisch! Aber Prio scheint niedrig.

@blinry

Hmmm.

Hmmmm!

Sag mir doch mal ein Zeitfenster zur Enthusiasticon, so CfP und Review.

@rixx Grob sowas wie: CfP Anfang März bis Mitte April, Review Mitte bis Ende April. :D

@rixx Was mir – auch als speaker – nie klar war: gibt es Stellen, an denen abstract oder description getrennt/alleine angezeigt werden? Soll die description nochmal alles wiederholen, oder den abstract ergänzen?

Ich hab es meist so benutzt, dass der abstract halt die Ein-Satz-Zusammenfassung ist, und die description darauf aufbauend mehr ins Detail geht, aber eigentlich würde mir immer auch eins von beiden Feldern reichen, irgendwie. Beim Testen hatte ich "abstract" jetzt deaktiviert.

@blinry Die werden immer zusammen gezeigt, das abstract auf der Talk-Seite in fett gesetzt. Der primäre Nutzen ist, denke ich, dass manche Events das als "tweetbare" Zusammenfassung nutzen, oder um die Einreichenden zu zwingen, auf den Punkt zu kommen. Grad bei akademischen Veranstaltungen ist so eine Beschreibung dohc schnell seitenfüllend. Aber dir geht one Abstract nichts kaputt oder verloren.

Sign in to participate in the conversation
chaos.social

chaos.social – a Fediverse instance for & by the Chaos community