Hi Nino, *,
(ich habe zu diversen Punkten aus den vielen Mails noch Fragen, ich fange mal
bei deiner Mail an, sie zu stellen:)
> [1]
> http://wiki.documentfoundation.org/User:Nnino/Drafts/DownloadpageBetter
-1 auf der einen Seite (Bezeichnung der 3.5.0 als *TEST*version.)
Der Begriff kam mir aus dem Bauch 
Mir ist bekannt, dass es sich dabei eher nicht um einen gängigen Fachbegriff
aus der Software-Versionierung handelt.
Doch, ist schon ein gängiger Begriff, nur sind die Testversionen bei
LO die betas und die RCs, nicht die finalen Releases.
Nichtsdestotrotz: Welchen Begriff bzw. welche Bezeichnung für diese Version
schlägst du stattdessen vor?
die .0 er Versionen sind von mir aus "early adopter" Versionen.
Ich glaube, es geht hier darum, eine ganz konkrete Bezeichnung zu finden! Von
irgendwem wurden hier mal die Debian-Kategorien genannt, also "unstable,
testing, stable", die aus meiner Sicht sehr gut auf unseren Fall passen:
Nein. Denn ganz klar: Auch die .0er Versionen sind freigegeben worden.
Sie haben mitunter bekannte Bugs (die entsprechend gelistet werden),
aber keine prinzipiellen Showstopper.
.0 Release + known Bugs gefixed = "traditionelles OOo release"
nur daß eben .0 schon vorher rausgebracht wird, damit die neuen
Features und sonstige Verbesserungen schon unter die Leute kommen.
Klar hat das den Nebeneffekt, das die Masse der User dann noch
zusätzliche Fehler findet, die vorher nicht bekannt waren - aber was
von den rc-Testern nicht gefunden wird, wird von denselben Personen
auch nicht gefunden nur weil das Release erst einen Monat später
released würde.
* Unstable: Crash und Datenverlust möglich, bei uns also Beta- und RC-Stadien
_vor_ der .0
* Testing: Crash und Datenverlust soweit wie möglich eliminiert, aber noch
nicht wirklich auf Funktionsbugs getestet (bzw. falls bereits getestet, dann
zu 99% noch nicht gefixt), wäre bei uns .0 bis .X
Nein. Das wäre nur fair, wenn man jedes andere Softwarerelease (also
das von der Konkurrenz) auch als Testversion bezeichnen würde.
(Übrigens, nebenbei bemerkt, würde es mir persönlich auch sehr gefallen, wenn
wir "harte" Kriterien für den Übergang von Testing zu Stable einführen
könnten, also etwa "mindestens 95% Funktions- und Regressionstests bestanden",
aber so weit ist unsere QA noch lange nicht, fürchte ich.)
Gibt schlicht keine harte Kriterien. Denn alle stopper bugs bei OOo
als auch bei LO werden durch die bekannten Tests eben nicht abgedeckt.
Aber egal, eins nach dem anderen. Als erstes bitte deinen Gegenvorschlag zur
griffigen Bezeichnung der .0-Verison
Early adopter version (fällt mir kein deutscher Begriff ein) oder für
Power-User/Innovators.
Klar ist das Ziel ein real-life Feedback, aber eine Testversion ist es
deswegen noch lange nicht. Auch wenn man hier vielleicht die
Testversion entsprechend einordnet, für den Seitenbenutzer/Medien, etc
bedeutet Testversion eben was ganz anderes.
* Technik: gefällt mir eigentlich nicht schlecht, wirkt "leichter", wenn auch
durch die Mehr-Seiten-Klickerei auch verwirrender, vor allem, wenn man andere
Versionen aussuchen möchte. Trotzdem: +1, ich finde alles, was ich brauche.
das durchklicken durch mehrere Seiten stört mich auch noch, das wird
früher oder später noch überarbeitet.
* Optische Benutzerführung zur intuitiven Versionsauswahl -2:
Genau die gegenteilige Tendenz zu unseren Bestrebungen hier.
Eben. Wir (LO-Projekt) wollen, daß unsere Nutzer das aktuelle Release
nutzen. Die Nutzer sollen nicht durch mehrere Versionen oder gar
Warnungen von einem Download abgeschreckt werden.
ganz konkret: Privatanwender sind auch mit der .0 Version bestens
bedient. Die Bugs, die bekannt sind und noch enthalten sind betreffen
spezielle Abläufe, die der 0815-User nicht verwendet/nicht braucht.
Keine Basisfunktinalität ist betroffen, ansonsten wäre das Release
nicht freigegeben worden.
Kommerzielle Nutzer sollten vorsichtiger sein, aber sind sie ja eh
(never change a running system und so) - die sollten also bis zur .2
oder .3 warten oder eben die .0 im nicht-produktiven Umfeld auf
tauglichkeit für die speziellen Arbeitsabläufe testen.
Firmen sind sowieso angehalten, Migrationen mit eines entsprechenden
Partners durchzuziehen - die werden aber auch nicht selber downloaden.
Frage zum Vorgehen: Ist es machbar, dass wir unsere Vorstellungen "nur" in die
DE-Seite einbauen, und die internationale Seite erst mal parallel so stehen
lassen, wie sie ist?
Von mir aus kann de.libreoffice.org auch die alte Downloadseite weiterverwenden.
Was aber nicht im Alleingang gemacht werden sollte ist die Umbenennung
einer Finalen Version in einen "public Betatest" - und das macht Dein
"Testversion"-Vorschlag aber.
Oder wäre es zweckmäßiger (z.B. zwecks Pflege-
Vereinfachung),
Nee, beide Downloadseiten wurden ja erstellt, damit sie keiner Pflege
bedürfen. Bzw. nur minimale Anpassungen.
Die neue Downloadseite hat z.B. überhaupt keinen Inhalt im CMS - die
komplette Seite ist automatisch erstellt, klaubt sich die "handy
ressources" und die zusätzlichen Links unten selber zusammen. (und
wird via pootle übersetzt)
die Seiten komplett "identisch" zu bauen, also quasi DE als
Übersetzung der EN?
genau - new-style-download wäre Übersetzung.
Oder, dritte Alternative, könnten wir die Technik zwar
parallel übernehmen, jedoch die Seite mit unseren eigenen Texten und optischen
Bedienführungselementen ausstatten? (Letzters wäre mir so auf den ersten Blick
am liebsten, ohne das jetzt genauer durchdacht zu haben).
Nein. Aber was in den Links neben den Buttons erscheint kann man auf
der Seite selber bestimmen (die "handy ressources")
ciao
Christian
![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
