vp:Freies Vortragsprogramm
From LinuxTag Public Wiki
(OpenOffice.org Wunschtag) |
(Auswahlkriterien hinzugefügt) |
||
Line 1: | Line 1: | ||
Das '''freie Vortragsprogramm''' macht den Hauptteil des Vortragsprogrammes auf dem LinuxTag aus. Die Rahmenbedingungen sind im [http://www.linuxtag.org/2008/de/conf/ Call for Papers] definiert. Organisatorisch ist es in einzelne ''Tracks'' aufgeteilt. Jeder Track wird von einem dafür verantwortlichen ''Session Chair'', ggf. zusammen mit einem von ihm zusammengestellten Session-Team organisiert. Das ''vp-Team'' koordiniert die Arbeit der einzelnen Sessions und ist Schnittstelle zur Messe. Der Vorsitz im vp-Team hat der ''Program-Chair''. | Das '''freie Vortragsprogramm''' macht den Hauptteil des Vortragsprogrammes auf dem LinuxTag aus. Die Rahmenbedingungen sind im [http://www.linuxtag.org/2008/de/conf/ Call for Papers] definiert. Organisatorisch ist es in einzelne ''Tracks'' aufgeteilt. Jeder Track wird von einem dafür verantwortlichen ''Session Chair'', ggf. zusammen mit einem von ihm zusammengestellten Session-Team organisiert. Das ''vp-Team'' koordiniert die Arbeit der einzelnen Sessions und ist Schnittstelle zur Messe. Der Vorsitz im vp-Team hat der ''Program-Chair''. | ||
+ | |||
+ | == Auswahlkriterien == | ||
+ | |||
+ | Wer legt eigentlich fest, welche Tracks und welche Talks tatsächlich im Programm aufgenommen werden? Dazu ist festzustellen, dass dies unter zwei wesentlichen Prämissen passiert: | ||
+ | |||
+ | # inhaltliche Aspekte: Wir wollen das bestmögliche Programm für unsere Besucher bieten. | ||
+ | # organisatorische Aspekte: Wir müssen gewisse äußere Bedingungen berücksichtigen. Dazu gehört beispielsweise ein gewisses Budget für Ausgaben (Reisekosten, Übernachtungen), zeitliche oder räumliche Constraints. Beispielsweise ist es wichtig, dass alle Talks zur gleichen Zeit anfangen und das gleiche Zeitschema verwenden, da uns Besucher gesagt haben, dass alles andere sie verwirrt. | ||
+ | |||
+ | Diese diversen Aspekte haben zu einer Anzahl von impliziten Regeln, eher Heuristiken zur Auswahl von Talks geführt. Der Begriff "Regel" ist insofern unglücklich, als dass nicht alle davon unbedingt einzuhalten sind, wenn es einen guten Grund gibt. Vielleicht sollten wir sie ''Empfehlungen'' nennen: | ||
+ | |||
+ | * Ein Speaker aus dem Vorjahr sollte nicht unbedingt im folgenden Jahr erneut einen Talk machen. | ||
+ | * Die Inhalte der Tracks sollten jeweils neu zusammengestellt sein und nicht zwangsläufig nur eine Kopie des Vorjahres oder anderer Konferenzen sein. | ||
+ | * Es soll vermieden werden, dass nur bestimmte Teil-Communitys in einem Track vertreten sind. | ||
+ | * Talks müssen nicht auf dem LinuxTag das erste Mal präsentiert werden, das gibt jedoch einen Bonus bei der Auswahl. Umgekehrt ergeben vorgefertigte Talks, die auf zig anderen LUGs, Konferenzen und Meetings schon gehalten wurden, einen leichten Malus. | ||
+ | * Talks aus dem CfP sollten eine gewisse Berücksichtigung finden, immerhin haben sich die Speaker dort besonders bemüht, ihre Unterlagen einzureichen. | ||
+ | * Alle Session-Chairs und ihre Team-Mitglieder können und sollen jedoch auch eigene Vorschläge einbringen. In der internen Diskussionsphase kann dies auch ohne vCC passieren, selbst wenn wir es nicht empfehlen. Spätestens jedoch, wenn ein Track beim PC eingereicht wird, müssen alle Angaben im vCC erfasst sein (und seien sie vorläufig). Das Nachfassen von unvollständigen Angaben macht ungefähr 80% der Arbeit des PCs aus. | ||
+ | * Talks sind immer auch Eigenwerbung für den Speaker und/oder sein Unternehmen. Das ist allen bewusst, sollte aber in einem vernünftigen Verhältnis stehen. In Zweifelsfällen steht der Nutzen der Teilnehmer über dem Nutzen des Speakers. | ||
+ | * Ein Track sollte/kann/darf durchaus auch kontroverse Standpunkte beeinhalten, es ist nicht notwendig, nur eine positive Einheitsmeinung zu allen Themen zu haben (schließlich wollen wir keine Jubelperser). Umgekehrt ist aber auch kein Proporzdenken in allen Teilfragen notwendig. | ||
+ | * Für ein gutes Programm ist eine gute Kombination aus ''face'' und ''substance'' notwendig. Einige Speaker erzeugen alleine mit ihrem Namen ein großes Interesse bei den Besuchern, andere durch ihre Inhalte. Optimal ist, wenn beides zutrifft. | ||
+ | * Das zeitliche Schema ist wichtig, da dann alle Talks zum gleichen Zeitpunkt anfangen und Besucher so leichter Räume wechseln können. | ||
+ | * Nützlich ist innerhalb eines Tracks zunächst einführende, danach spezialisierende Talks zu positionieren. | ||
+ | * Die Talks in der Mitte des Tages (sagen wir 11h, 12h, 13:30h, 15h) sind sicherlich die populärsten Timeslots. Allerdings sollte sich jedes Team überlegen, dass auch die anderen Tracks potentiell zu diesen Zeiten populäre Talks planen. | ||
+ | * Dass mitunter interessante Talks parallel liegen, sollte vermieden werden, wenn es sich vermeiden lässt. Leider hat dieses Problem eine nicht zu unterschätzende Komplexität. | ||
+ | |||
+ | |||
+ | Das Programmkomitee vertraut darauf, dass die Session-Chairs ein ähnliches Verständnis von der Programmgestaltung haben wie das PC. Das sollte auch in der Vergangenheit immer so gewesen sein. Dieses Wiki soll in erster Linie dazu dienen, um die Programmgestaltung innerhalb der einzelnen Teams und mit dem PC zu koordinieren. Wenn das PC doch einmal Bedenken gegen einen Talk oder eine Zusammenstellung haben sollte (was nur selten vorkommt), dann wird sich das PC mit dem Session-Team in Verbindung setzen und versuchen, eine einvernehmliche Lösung zu finden. | ||
+ | |||
+ | Es ist nicht unser primärer Ansatz, komplexe formale oder gar hierarchische Entscheidungsstrukturen aufzubauen. Als Veranstalter müssen der LinuxTag e. V. und die von ihm eingesetzten Referenten natürlich einer gewissen Verantwortung nachkommen insofern haben sie rein formal natürlich das letzte Wort in Entscheidungen. Wir versuchen jedoch, diese Mittel nicht zum Einsatz kommen zu lassen und streben einen Konsens mit allen Beteiligten an. Umgekehrt hoffen wir jedoch auch auf Verständnis und Kompromissbereitschaft seitens der Session-Teams. Keine Beteiligter sollte die anderen Beteiligten zu "erpressen" zu versuchen (beispielsweise "entweder dieser Talk kommt so oder wir ziehen das ganze Programm zurück"). | ||
+ | |||
+ | Diese Überlegungen werden kontinuierlich fortgeschrieben. | ||
== Anleitung für Session-Chairs == | == Anleitung für Session-Chairs == |
Revision as of 10:29, 28 January 2008
Das freie Vortragsprogramm macht den Hauptteil des Vortragsprogrammes auf dem LinuxTag aus. Die Rahmenbedingungen sind im Call for Papers definiert. Organisatorisch ist es in einzelne Tracks aufgeteilt. Jeder Track wird von einem dafür verantwortlichen Session Chair, ggf. zusammen mit einem von ihm zusammengestellten Session-Team organisiert. Das vp-Team koordiniert die Arbeit der einzelnen Sessions und ist Schnittstelle zur Messe. Der Vorsitz im vp-Team hat der Program-Chair.
Contents |
Auswahlkriterien
Wer legt eigentlich fest, welche Tracks und welche Talks tatsächlich im Programm aufgenommen werden? Dazu ist festzustellen, dass dies unter zwei wesentlichen Prämissen passiert:
- inhaltliche Aspekte: Wir wollen das bestmögliche Programm für unsere Besucher bieten.
- organisatorische Aspekte: Wir müssen gewisse äußere Bedingungen berücksichtigen. Dazu gehört beispielsweise ein gewisses Budget für Ausgaben (Reisekosten, Übernachtungen), zeitliche oder räumliche Constraints. Beispielsweise ist es wichtig, dass alle Talks zur gleichen Zeit anfangen und das gleiche Zeitschema verwenden, da uns Besucher gesagt haben, dass alles andere sie verwirrt.
Diese diversen Aspekte haben zu einer Anzahl von impliziten Regeln, eher Heuristiken zur Auswahl von Talks geführt. Der Begriff "Regel" ist insofern unglücklich, als dass nicht alle davon unbedingt einzuhalten sind, wenn es einen guten Grund gibt. Vielleicht sollten wir sie Empfehlungen nennen:
- Ein Speaker aus dem Vorjahr sollte nicht unbedingt im folgenden Jahr erneut einen Talk machen.
- Die Inhalte der Tracks sollten jeweils neu zusammengestellt sein und nicht zwangsläufig nur eine Kopie des Vorjahres oder anderer Konferenzen sein.
- Es soll vermieden werden, dass nur bestimmte Teil-Communitys in einem Track vertreten sind.
- Talks müssen nicht auf dem LinuxTag das erste Mal präsentiert werden, das gibt jedoch einen Bonus bei der Auswahl. Umgekehrt ergeben vorgefertigte Talks, die auf zig anderen LUGs, Konferenzen und Meetings schon gehalten wurden, einen leichten Malus.
- Talks aus dem CfP sollten eine gewisse Berücksichtigung finden, immerhin haben sich die Speaker dort besonders bemüht, ihre Unterlagen einzureichen.
- Alle Session-Chairs und ihre Team-Mitglieder können und sollen jedoch auch eigene Vorschläge einbringen. In der internen Diskussionsphase kann dies auch ohne vCC passieren, selbst wenn wir es nicht empfehlen. Spätestens jedoch, wenn ein Track beim PC eingereicht wird, müssen alle Angaben im vCC erfasst sein (und seien sie vorläufig). Das Nachfassen von unvollständigen Angaben macht ungefähr 80% der Arbeit des PCs aus.
- Talks sind immer auch Eigenwerbung für den Speaker und/oder sein Unternehmen. Das ist allen bewusst, sollte aber in einem vernünftigen Verhältnis stehen. In Zweifelsfällen steht der Nutzen der Teilnehmer über dem Nutzen des Speakers.
- Ein Track sollte/kann/darf durchaus auch kontroverse Standpunkte beeinhalten, es ist nicht notwendig, nur eine positive Einheitsmeinung zu allen Themen zu haben (schließlich wollen wir keine Jubelperser). Umgekehrt ist aber auch kein Proporzdenken in allen Teilfragen notwendig.
- Für ein gutes Programm ist eine gute Kombination aus face und substance notwendig. Einige Speaker erzeugen alleine mit ihrem Namen ein großes Interesse bei den Besuchern, andere durch ihre Inhalte. Optimal ist, wenn beides zutrifft.
- Das zeitliche Schema ist wichtig, da dann alle Talks zum gleichen Zeitpunkt anfangen und Besucher so leichter Räume wechseln können.
- Nützlich ist innerhalb eines Tracks zunächst einführende, danach spezialisierende Talks zu positionieren.
- Die Talks in der Mitte des Tages (sagen wir 11h, 12h, 13:30h, 15h) sind sicherlich die populärsten Timeslots. Allerdings sollte sich jedes Team überlegen, dass auch die anderen Tracks potentiell zu diesen Zeiten populäre Talks planen.
- Dass mitunter interessante Talks parallel liegen, sollte vermieden werden, wenn es sich vermeiden lässt. Leider hat dieses Problem eine nicht zu unterschätzende Komplexität.
Das Programmkomitee vertraut darauf, dass die Session-Chairs ein ähnliches Verständnis von der Programmgestaltung haben wie das PC. Das sollte auch in der Vergangenheit immer so gewesen sein. Dieses Wiki soll in erster Linie dazu dienen, um die Programmgestaltung innerhalb der einzelnen Teams und mit dem PC zu koordinieren. Wenn das PC doch einmal Bedenken gegen einen Talk oder eine Zusammenstellung haben sollte (was nur selten vorkommt), dann wird sich das PC mit dem Session-Team in Verbindung setzen und versuchen, eine einvernehmliche Lösung zu finden.
Es ist nicht unser primärer Ansatz, komplexe formale oder gar hierarchische Entscheidungsstrukturen aufzubauen. Als Veranstalter müssen der LinuxTag e. V. und die von ihm eingesetzten Referenten natürlich einer gewissen Verantwortung nachkommen insofern haben sie rein formal natürlich das letzte Wort in Entscheidungen. Wir versuchen jedoch, diese Mittel nicht zum Einsatz kommen zu lassen und streben einen Konsens mit allen Beteiligten an. Umgekehrt hoffen wir jedoch auch auf Verständnis und Kompromissbereitschaft seitens der Session-Teams. Keine Beteiligter sollte die anderen Beteiligten zu "erpressen" zu versuchen (beispielsweise "entweder dieser Talk kommt so oder wir ziehen das ganze Programm zurück").
Diese Überlegungen werden kontinuierlich fortgeschrieben.
Anleitung für Session-Chairs
Dies ist der aktuelle Planungsstand. Wenn irgendwo Namen, Daten, Kategorien o. ä. eingetragen sind, hat das nicht zwangsläufig bindende Wirkung. Es ist ein Wiki, ein Planungsstand.
Vorgehen für mögliche Session-Chairs:
- Identifizieren, ob der eigene Track schon in der Tabelle steht.
- ggf. Anpassungen von Namen oder Wunsch-Terminen machen
- Wenn der Session-Name noch nicht angelegt ist (d. h. der Link ist noch rot), einmal draufklicken und einen kurzen Dummy-Text einfügen.
- Den Link zu diesem Track-Template folgen.
- Im Template einmal auf "editieren" klicken.
- Im Textfeld einmal alles markieren und kopieren (Ctrl-A, Ctrl-C).
- Zurück ohne Speichern auf die Übersichtsseite.
- Den eigenen Track wieder auswählen.
- Ebenfalls "editieren" angeben.
- Im Textfeld das Template reinpasten (Ctrl-V).
- Das Template anpassen und/oder geeignet ergänzen.
- Die Wiki-Seiten werden nicht automatisiert ausgewertet, aber die dort gemachten Angaben müssen schließlich in das vCC und in andere Informationssysteme übernommen werden. Aus diesem Grunde kann zwar frei formuliert werden, aber es sollten die wichtigen Angaben gemacht sein.
- In der Liste der vorschlagenen Talks sollten optimalerweise Talks aufgeführt werden, die im vCC eingetragen sind. Hilfreich ist es, die fünfstellige Paper-ID mit anzugeben (z. B. #14001).
- Damit ein Track tatsächlich auf dem LinuxTag stattfindet, muss bis spätestens zum 8. Februar 2008 beim vp-Team der Eindruck erweckt werden, dass dazu substantielle Angaben vorhanden sind. Dies ist am besten dadurch zu erreichen, dass alle Felder des Templates ausgefüllt sind und möglichst viele korrespondierenden Talks im vCC erfasst sind.
Übersicht vorgeschlagener Tracks
Folgende Tracks wurden vorgeschlagen. Die Liste ist nicht besonders sortiert. Zusätzliche Vorschläge bitte hinten fortlaufend anfügen. Jeder darf prinzipiell alles editieren, sollte dies aber sinnvollerweise nur bei seinen eigenen Tracks oder nach Absprache machen. Es lebe das Wiki-Prinzip.
Ref | Session | Zielgruppe | Chair | Tag | Komitee |
---|---|---|---|---|---|
01 | Trusted Computing | tec, adm | Florian | Do | |
02 | Systemadministration | adm | Peer | ||
03 | GNOME | usr, dev | |||
04 | KDE | usr, dev | Sebastian, Jörg Hoh | ||
05 | Security | adm | Christoph | Do | Dolle, Holtmann, Spenneberg |
06 | Kernel | tec, dev | Nils | ||
07 | Enterprise Devel | dev, bus | Kleini | ||
08 | OW2 | dev, bus | Franzosen | ||
09 | BSD | adm | Wilhelm | Fr | |
10 | openSUSE | usr, adm | Martin | ||
11 | Debian | adm | |||
12 | Ubuntu | usr, adm | Torsten | ||
13 | Fedora | usr, adm | |||
14 | OpenSolaris | adm, tec | Dirk | ||
15 | OS für Beginner | usr | Ben | ||
16 | Digital Lifestyle | usr, tec | Elke, Marko | ||
17 | Social | soc | Markus Beckedahl - nicht angefragt, ggf. Zusammenlegung mit WOS | ||
18 | Office Anwendungen, Dokumentenmanagement | bus, adm, usr | Elke | ||
19 | Data Center | adm, bus, tec | ggf. Merge mit SysAdm | ||
20 | Storage | adm, tec | Wolfgang Stief, Alasdair | ||
21 | PHP/Ruby | dev | Anfrage: Björn Schotte/Georg Richter (via Oli) | ||
22 | Migrationen und Success Stories | bus, usr | |||
23 | Medizin/Gesundheitswesen | usr, bus | Elke | ||
24 | OpenOffice.org | usr, bus, adm | Jacqueline | Fr | |
25 | Freie Software in Bildung | edu, usr | Kurt Gramlich | Sa | Kurt, Wolfgang et. al. |
26 | Phones and Gadgets | usr | |||
27 | Embedded Appliances & M/R/A | tec, dev, bus | via OSADL? | ||
28 | Zope | dev, bus | DZUG? | ||
29 | GIS | ??? | Silke Reimer bzw. Georg Lösel angefragt | ||
30 | WOS | edu, soc | Volker Grassmuck - angefragt, ggf. Zusammenlegung mit Social | ||
31 | Businesskongress I | bus | Lisog | Mi | |
32 | Businesskongress II | bus | Lisog | Do | |
33 | Behördenkongress I | bus | BMI | Mi | |
34 | Behördenkongress II | bus | EC | Do |
Personen
die sich gemeldet haben, um bei verschiedenen Dingen zu helfen:
- Dirk Wetter
- Ulrich Wolf
- Kris Buytaert