vp:Freies Vortragsprogramm

From LinuxTag Public Wiki

(Difference between revisions)
Jump to: navigation, search
(Übersicht vorgeschlagener Tracks)
(Übersicht vorgeschlagener Tracks)
Line 115: Line 115:
| 27 || [[vp:Track Embedded Appliances & M/R/A 2008|Embedded Appliances & M/R/A]] || tec, dev, bus || via OSADL?
| 27 || [[vp:Track Embedded Appliances & M/R/A 2008|Embedded Appliances & M/R/A]] || tec, dev, bus || via OSADL?
|-
|-
-
| 28 || [[vp:Track ZOPE 2008|ZOPE|Zope]]            || dev, bus || DZUG?
+
| 28 || [[vp:Track ZOPE 2008|Zope]]            || dev, bus || DZUG?
|-
|-
| 29 || [[vp:Track GIS 2008|GIS]]            || ??? || Silke Reimer bzw. Georg Lösel angefragt
| 29 || [[vp:Track GIS 2008|GIS]]            || ??? || Silke Reimer bzw. Georg Lösel angefragt

Revision as of 00:59, 30 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:

  1. inhaltliche Aspekte: Wir wollen das bestmögliche Programm für unsere Besucher bieten.
  2. 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:

  1. Identifizieren, ob der eigene Track schon in der Tabelle steht.
  2. ggf. Anpassungen von Namen oder Wunsch-Terminen machen
  3. Wenn der Session-Name noch nicht angelegt ist (d. h. der Link ist noch rot), einmal draufklicken und einen kurzen Dummy-Text einfügen.
  4. Den Link zu diesem Track-Template folgen.
  5. Im Template einmal auf "editieren" klicken.
  6. Im Textfeld einmal alles markieren und kopieren (Ctrl-A, Ctrl-C).
  7. Zurück ohne Speichern auf die Übersichtsseite.
  8. Den eigenen Track wieder auswählen.
  9. Ebenfalls "editieren" angeben.
  10. Im Textfeld das Template reinpasten (Ctrl-V).
  11. Das Template anpassen und/oder geeignet ergänzen.
  12. 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.
  13. 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).
  14. 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.

Vorschläge
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 FUDCon/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
Personal tools
Navigation
Crew