Druckversion|
Home
Was ist ot ?
Regeln
Mitglieder
Maintainer
Impressum
FAQ/Hilfe
Browser Wunsch- und Fehlerliste |
|
| Maintainer: Stefan Meretz, Version 1, 05.05.2000 |
Druckversion |
| Projekt-Typ: | |
| Status: Archiv |
![[Alle Kommentare ausblenden]](/images/blueminus.png "[Alle Kommentare ausblenden]"){kind=small}
(1) Hier werden die Wünsche an die nächste neue Version dokumentiert. Ob und wann diese Wünsche realisiert werden, hängt vom Entwicklungsteam ab (mitmachen!). Wenn Du eine bestimmte Funktion in ot vermisst, trage doch einfach Deinen Wunsch als Kommentar unten ein!
(2) Neue Wünsche hier eintragen:
(2.1) Re: To-do-Liste (ohne Priorität):, 10.05.2000, 16:32, Thomas Kalka: Eine Publisher-Funktion. Einen Knopf drücken, und das Projekt wird zu einem PDF-Dokument umgesetzt und gesendet.
(2.1.1) Re: Das leidige Thema: Formate, 10.05.2000, 17:45, Stefan Meretz: Finde ich prinzipiell gut, nur das PDF-Format passt mir nicht, denn es ist ein proprietäres Format und die Dokumente sind nicht bearbeitbar. Klar wird der Reader verschenkt - so wie MS den Browser verschenkt. Adobe versucht, via PDF-Marktanteil ihr Format für eBooks durchzusetzen, wo das große Geld erwartet wird. Mir wäre ein freies Format, das alle nutzen können, lieber, aber das ist noch nicht so weit... (wird wohl XML mal sein...). Ich nutze - auch nur Kompromiss - als übergreifendes Format RTF. Klar, ist von MS, aber MS hat keine Amibitionen mehr, es ist dokumentiert und ist von wohl fast allen Textprogrammen auf so ziemlich jedem System lesbar (und meist auch schreibbar).
(2.1.1.1) Re: Das leidige Thema: Formate, 10.05.2000, 23:13, Thomas Kalka: Ich verstehe das Argument nicht. Projekte sollen doch nicht editierbar sein ? Diesbezüglich hätte PDF keine Nachteile. PDF sehe ich als de facto freien Standard an, um gesetzt Texte in einer geräteunabhängigen Form zu repräsentieren, was RTF meines Erachtens nicht leistet. Da es freie Software gibt, die PDF-Dateien erzeugen kann (z.B. pdf-tex, pdf-latex), sehe ich dem Einsatz von PDF nichts im Wege stehen. Es geht ja wohl auch nicht darum, sich für ein spezielles Ausgabeformat zu entscheiden. Wenn es darum geht, den Text in einer in Textverarbeitungen zu importierenden Form zu exportieren, würde ich auch ganz klar RTF vorziehen. Um mal eben aber einen Ausdruck eines Projekts zu machen ist eine bereits gesetzte Form (als PDF-Datei) meiner Meinung nach wesentlich angenehmer.
(2.1.1.1.1.1) Re: Das leidige Thema: Formate, 19.08.2000, 00:05, Stefan Meretz: ASCII-Upload funktioniert jetzt (mit Version 0.41) - easy, easy! Die Regeln sind simple: Einzelzeile=Überschrift, Mehrfachzeilen=Absatztext. Folgt Einzelzeile auf Einzelzeile, ist die zwei Einzelzeile=Absatztext (denn Nur-Überschrift ist nicht erlaubt). ASCII-Download folgt...
(2.1.1.2) XML, 17.10.2000, 19:33, Torsten Wöllert: Ich glaube auch, dass es wohl auf eine Form von XML herauslaufen wird. Das gängigste offene XML scheint zur Zeit DocBook zu sein, das auch in der OpenSource-Szene gerne benutzt wird. Deswegen gibt es dafür auch (zumindest ansatzweise) kostenlose Werkzeuge und eine "community". Ein Export nach DocBook auf Knopfdruck wäre wirklich stark. Dann könnte man auf der OT-Plattform z.B. auch Dokumentation für Freie Software zusammen schreiben.
(2.1.2) Re: Export in verschiedenen Formaten, 15.05.2000, 17:19, Stefan Meretz: Pragmatischerdings bin ich dafür, jegliche Exportformate zu realisieren, die wir brauchen: ASCII, PDF, PS, RTF und mehr. Irgendwer muss dass nur realisieren. Also: Wer sucht welchen Filter? Es sollte eigentlich alles schon geben, nur ich kenne mich da nicht gut aus. Hinweise mit Links und Beschreibung bitte an diesen Kommentar hängen.
(2.2) Re: To-do-Liste (ohne Priorität):, 10.05.2000, 23:21, Thomas Kalka: Derjenige, der einen Kommentar gesendet hat, sollte diesen ändern dürfen, d.h. eine neue Version des Kommentars erstellen können. Damit wäre es z. B. möglich Rechtschreibfehler zu korrigieren. Die alten Versionen sollten über einen Link einsehbar sein.
(2.2.1) Re: To-do-Liste (ohne Priorität):, 09.06.2000, 15:23, Stefan Meretz: Das Ändern (Löschen) eigener Kommentare ist jetzt möglich - bis jeweils 6 Uhr morgens. Um 6 Uhr werden alle gesammelten und noch nicht verschickten Mails versendet (siehe Abs. (4)), dann ist auch Schicht fürs Ändern der eigenen Kommentare.
(2.3) Re: To-do-Liste (ohne Priorität):, 10.05.2000, 23:35, Thomas Kalka: Verschiedene Prioritätslevel für Kommentare: Gewünscht ist doch die Konvergenz eines Projektes zu einem gut fundierten neuen Text ? Momentan repräsentieren sich Projekte als ein vollständig aufgeklappter Baum ( oder Graph) von Kommentaren, Unterkommentaren usw. . Es wäre schön, einige Kommentare auch in "zugeklappter" Form, d.h. nur in Form eines Pfeils oder ähnlichem zu repräsentieren. Der gesamte Text würde so einfacher zu erfassen. Gerade bei der Einarbeitung in neue Projekte wäre eine "Grobsicht" des Projektes meiner Meinung nach wünschenswert.
(2.4) Re: To-do-Liste (ohne Priorität):, 10.05.2000, 23:44, Thomas Kalka: Querverweise, Hinweise, Links, Verstichwortung, Glossar
(2.5) Re: To-do-Liste (ohne Priorität):, 20.05.2000, 02:09, Thomas Uwe Grüttmüller: Man müßte auf die selbstverfaßten Kommentare noch im Nachhinein Schreibrecht behalten, um Ergänzungen und Korrekturen vornehmen zu können. (Es ist schwachsinnig, daß man seine eigenen Kommentare kommentieren muß). Ferner sollte es möglich sein, Kommentare auch ganz wieder zu entfernen (wenn man sie nur aus Versehen abgeschickt hat)
(2.6) Copyright- Vermerk (Teil 1), 28.05.2000, 03:19, Thomas Uwe Grüttmüller: Das Anwendungsbeispiel der GFDL am Ende der GFDL ist, wörtlich übernommen, leicht ungeeignet, da die Bemerkung "Copyright (c) 2000 Ano Nym" suggeriert, Ano Nym habe das Copyright auf den gesamten angezeigten Text inclusive Kommentare. Dies ist aber gefährlich, zumal der Copyrightinhaber meines Wissens nach seinen Text unter verschiedenen, wiedersprüchlichen Lizenzen herausgeben darf. Es sollte daher eher klargestellt werden, daß Ano Nym lediglich Copyright- Inhaber des Basistextes ist, daß aber sämtliche Kommentare abgeleitete Werke sind, die ebenso unter der GFDL stehen müssen, wobei allerdings das Copyright beim Kommentator bleibt.
(2.7) Copyright- Vermerk (Teil 2), 28.05.2000, 03:33, Thomas Uwe Grüttmüller: ...Ferner sollte mal die "no invariant sections" - Geschichte diskutiert werden. Grundsätzlich finde ich die Idee, opentheory- Texte invariant sections- frei zu machen, nicht verkehrt. Wie sieht es in diesem Zusammenhang aber mit Zitaten aus? M.E. wäre hier noch ein Zusatz fällig, daß in Bereichen, daß Bereiche, die als Zitat erkennbar gemacht wurden, nur nach den üblichen Regeln für Zitatveränderungen verändert werden dürfen. -- Diese Dinge fallen mir gerade im Zusammenhang mit dem GFDL- Übersetzungsprojekt auf.
(2.7.1) Re: Copyright- Vermerk (Teil 2), 28.05.2000, 17:16, Stefan Meretz: Die Copyleft-GFDL hat imho mit Zitaten nichts zu tun - genauso wenig wie andere Copyright-privatisierende Lizenzen. Nur weil jmd. ein Zitat in einer Copyright-Lizenz verwendet, ist es damit doch nicht "geschützt"´, sprich, Du darfst es verwenden. Dito bei Copyleft sowieso. Ob du es korrekt verwendest, kürzt oder fälschst, das ist eine Frage der Common-sense Zitationspraxis und damit überhaupt nicht regelbar. Fälscher sind Fälscher, was willst Du da machen?
(2.8) Benachrichtigung bei neuen Projekten, 28.05.2000, 03:57, Thomas Uwe Grüttmüller: Noch was für den Wunschzettel: Es müßte eine Mailingliste geben, in der neue Projekte auf diesem Server angekündigt (und|oder) besprochen werden.
(2.8.1) Re: Benachrichtigung bei neuen Projekten, 28.05.2000, 17:20, Stefan Meretz: Dafür ist das open_theory-Projekt da. Ok, man könnte auch dazu ein extra Projekt einrichten, aber irgendwann wird es redundant. Eine Mail an das open_theory-Projekt erreicht die meisten Leute (hast Du ja auch genutzt, wie ich sehe).
(2.8.1.1) Re: Benachrichtigung bei neuen Projekten, 02.07.2000, 10:47, Melanie Siemers: Ich wuensche mir, dass diese Mail automatisch bei der Eintragung eines neuen Projekts erzeugt wird, damit ich auch, wenn ich _webfaul_ bin, alle neuen Projekte beim Start zu sehen bekomme. Diese Mail sollte einfach den Text enthalten, der auch auf der Projektseite steht.
(2.9) Re: To-do-Liste (ohne Priorität):, 24.08.2000, 12:07, Stefan Meretz: Von Heiko bekam ich folgenden Vorschlag, den ich sehr gut finde: "die Textlaenge ist auf einigen (aber nur auf einigen) Webseiten von ot unkomfortabel lang. IMHO waere es fuer Neuzugaenge guenstiger, die Textlaenge entweder zu begrenzen - oder - noch besser: mit "unischtabern" Tabellen zu arbeiten - wie GNU ;-)." Ich werde wohl die "unsichtbaren Tabellen" nehmen.
(2.10) Bequemer kommentieren, 18.09.2000, 10:01, Thomas Uwe Grüttmüller: DaV zur Eingabe eines einzigen Kommentares zweimal der gesamte Text gesaugt werden muV, ist bei langen Texten ziemlich nervig. Wie w%6 re es daher mit einer alternativen Eingabemethode zu der bew%6 hrten, bei der man auf einer Webpage nur die Eingabefelder ohne Text erhh%6 lt, mit einem zus%6 tzlichen Feld zur Angabe der Nummer des zu kommentierenden Absatzes. Nach dem Abschicken erhh%6 lt man dann ein neues Formular. Eine solche Page k%0-nnte sich der Benutzer in einem zus%6 tzlichen Fenster anzeigen und den eigentlichen Text nur dann aktualisieren lassen (per Reload), wenn ihn die %4 nderungen wirklich interessieren.
(2.10.1) Re: Bequemer kommentieren, 19.09.2000, 07:16, Stefan Meretz: Das mit dem zusätzlichen Fenster ginge nur mit Java-Skript. Ich hatte mich aber entschieden, OT auf dem niedrigst möglichen Level zu realisieren, d.h. HTML 3.2, no ActiveX, no Java, no Java-Skript, no Cookies - dabei will ich bleiben. Schon die Nutzung der HTTP-Authentifizierung stiess auf Probleme bei einigen Browsern (siehe (21)). Aber folgender Vorschlag: Nach Klick auf Kommentar kommt nur der kommentierte Absatz und das Formularfenster. Dann beim Abschicken wieder die ganze Seite. Einmal Laden gespart. (Warum kommen bei Dir diese schrottigen Zeichen?)
(2.10.1.1) Re: Bequemer kommentieren, 18.10.2000, 17:23, Torsten Wöllert: Die Stärke von OT liegt doch genau darin, dass es einfach und praktikabel ist und dadurch kaum jemanden von der Nutzung ausschließt, im Gegensatz zu anderen, "schöneren" Projekten. Deswegen bin ich von ActiveX, Cookies usw. prinzipiell nicht begeistert und von Java zum gegenwärtigen Zeitpunkt auch nicht.
(2.11) Patches, 18.09.2000, 10:14, Thomas Uwe Grüttmüller: Um zum Korrekturlesen zu ermuntern, w%6 re es sicher sinnvoll, eine standardisierte M%0-glichkeit zum Patchen vorzusehen. Dies stelle ich mir so vor: Entdeckt jemand einen Rechtschreipfehler, so fgt er eine Korrekturanweisung als Kommentar ein. Ist der Verfasser des bem%6 ngelten Absatzes/Kommentares zu berzeugen, so drckt dieser einfach nur irgendwo auf eine Taste, und -- schwupps -- hat es den Fehler, sowie die Beschwerde nie gegeben. Lediglich in alten Snapshots und im Listenarchiv k%0-nnen Historiker sp%6 ter jene noch nachweisen.
(2.11.2) Re: Patches, 19.09.2000, 07:23, Stefan Meretz: Das ist nicht so einfach, denn du musst eine Grammatik erfinden, die sich vom Text abhebt. So reicht "/s/xxx/yyy" nicht aus, denn das kann normaler Text sein. So eine Grammatik steht aber wohl an, denn ich will weitere Steuerbefehle implementieren: Logische Textauszeichnungen und Links in Kommentaren (z.Zt. werden alle Versuche per HTML ausgefiltert). Any proposals?
(2.12) "Unterabsatz einfuegen", 18.09.2000, 10:27, Thomas Uwe Grüttmüller: Kommentare sollten "Unterabsaetze" heissen, um den Verfasser eines Unterabsatzes dazu anzuhalten, nicht den Verfasser des kommentierten Absatzes zu adressieren, sondern den Leser des Gesamttextes. Dies halte ich zum einen fuer stilistisch besser, zum anderen erleichtert es die Aufnahme der neuen Ideen in einen neuen Basistext (Copy&Paste lassen gruessen).
(2.13) Kommentarbaeume uebernehmen, 18.09.2000, 10:36, Thomas Uwe Grüttmüller: Bei langen Texten, bei denen der Bedarf besteht, vorerst nur einen Teil des Basistextes zu erneuern, sowie bei Texten, die ueberhaupt nicht fortlaufend, sondern hierarchisch gegliedert sind (zum Beispiel dieser hier), stelle ich mir die Moeglichkeit sinnvoll vor, gewachsene Kommentarstrukturen ganz oder teilweise zu uebernehmen.
(2.13.1) Re: Kommentarbaeume uebernehmen, 19.09.2000, 07:29, Stefan Meretz: Das führt aber u.U. dazu, Müll permanent zu reproduzieren. Der Sinn einer neuen Version soll aber gerade sein, die Kommentare der Vorversion zu integrieren. Wenn ich also eine neue Version dieses Textes mache, dann lasse ich die erledigten Sachen raus, liste die konsensfähigen offenen Punkte auf und stelle Kontroversen dar. Bin ich also dagegen.
(2.14) Projekte killen, 18.09.2000, 23:41, Thomas Uwe Grüttmüller: Der Maintainer eines Projektes sollte ein Projekt killen koennen, wenn dies jemand von ihm verlangt.
(2.14.1) Re: Projekte killen, 19.09.2000, 07:37, Stefan Meretz: Mir fallen nur gravierende rechtliche Gründe ein, die so etwas notwendig machen. Warum reicht dir ein Abschluss eines verkorksten Projektes und Aufsetzen eines neuen nicht aus? Ausserdem: Weg ist weg. Was ist, wenn der Maintainer sagt: Ach ich will jetzt doch weitermachen? (Das gab es schon...) Dazu müsste ich ein Archiv gekillter Projekte führen - das ist mir zu blöd, das mache ich nicht.
(2.14.1.1) Re: Projekte killen, 27.10.2000, 12:54, Oliver Bandel: *Gibt man den Projekten mehr als nur zwei (In Arbeit und abgeschlossen) Stati, also z.B. auch "Archiv", "abgelöst durch Projekt " usw., dann könnte man besser eine Projektauswahl treffen (wenn`s denn wirklich mal richtig voll hier wird). *Ein anderer grund, der mir noch einfällt, warum man Projekte vollkommen canceln köännen sollte, ist der: Vergessen sollte möglich sein. Die Unmöglichjkeit des vergessens im netz und durch Rechner/EDV ist eine nicht zu unterschätzende Gefahr. Was man im normalen Alltag mal so daher sagt, kann einem - wenn es nie mehr gelöscht wird - in dieser Form vielleicht mal später auf die Füsse fallen. Dagegen ist ein "tja, leider alle Daten gelöscht" harmlos.
(2.15) Datenbank für externen Zugriff öffnen, 25.09.2000, 14:46, Thomas Kalka: Die Datenbank könnte für nur lesenden Zugriff für alle geöffnet werden. Somit wäre es möglich, einen Offlinereader zu schreiben. Falls dieses schon möglich sein sollte, wäre es schön die Zugangsdaten erfahren zu können.
(2.16) Absaetze in Kommentaren, 29.09.2000, 23:30, Stefan Merten: Ich fände es mega-wünschenswert, wenn Absätze respektive Leerzeilen in Kommentaren erhalten blieben. Daß sie momentan gekillt werden, beweist diese Zeile, vor der wohl keine Leerzeile erscheint.
(2.17) Mitglied bei einem Projekt sein, 02.10.2000, 20:28, Stefan Merten: Ich habe den Verdacht, daß viele Leute, die "Ano Nym" kommentieren, aber ihren Namen eintragen, sich nicht darüber im Klaren sind, daß sie damit nicht als Projektmitglieder gelten. Vielleicht könnte ihnen in einem solchen Fall nach dem Absenden eine Aufnahme angeboten werden. Zur Erläuterung könnte erwähnt werden, daß sie nur so die Antworten auf ihre Bemerkungen als Mail kriegen.
(2.18) Cookies, 03.10.2000, 07:47, Thomas Kalka: Warum sollte die Benutzung von Cookies nicht wahlweise freigestellt sein ? (Dies könnte in den Mitgliedsdaten gespeichert sein). So würde das immer neue Einloggen nicht mehr nötig sein.
(2.18.1) Re: Cookies, 05.10.2000, 21:35, Stefan Meretz: Was meinen denn die anderen dazu? Ich bin eigentlich dagegen, die User an Cookies zu gewöhnen, da darüber ein Haufen Probleme eingeschleppt werden (Tracing, Security etc.). Ausserdem sollen Textbrowser wie Lyx Probleme damit haben (weiss ich aber nicht genau).
(2.18.1.1) Re: Cookies, 18.10.2000, 17:30, Torsten Wöllert: NO COOKIES PLEASE !!! Bei jedem Cookie muss man sonst dazu schreiben, was es macht, dass es nicht ewig auf der Festplatte bleibt und eventuell herum schnüffelt usw. Warum sollte es außerdem keine Leute geben, die sich gerne mit mehreren virtuellen Identitäten an OT beteiligen wollen. Wollen wir denen unbedingt auf die Schliche kommen?
(2.19) Konvergenz, 03.10.2000, 07:50, Thomas Kalka: Da zur Zeit nur Kommentare möglich sind, werden Texte immer unübersichtlicher und komplizierter. Irgendwie muß es doch auch möglich werden, daß der Text zu einem Kompakteren wächst, ohne daß der Maintainer all die Arbeit hat.
(2.19.1) Re: Konvergenz, 05.10.2000, 21:38, Stefan Meretz: Nur wie? Was diesen Text hier angeht, ist es in der Tat extrem. Ich kann mir nur vornehmen, bald eine neue Version zu erstellen. Nur meine persönliche To-Do-Liste ist kilometerlang. Will jemand vielleicht dieses Projekt (ToDo_and_Bugs) als Maintainer übernehmen und den Text pflegen?
(2.19.1.1) Re: Konvergenz, 27.10.2000, 12:57, Oliver Bandel: 2.19.1: Auch hier könnte die DML ggf. helfen http://www.NetzService.de/Home/maro/mr_dml.html je nachdm, welchrart der neue Eintrag ist, könnte er entsprechend eingefügt werden (z.B. sind Kommentare immer zugeklappt, so wie Fußnoten immer unten auf einer seite stehen), während beiträge zum Haupttext, die in bestimmter Weise bezug nehmen, direkt eingebaut werden lkönnten... naja, wie genau, müsste man halt noch ausarbeiten. Irgendwo wurde doch hier auch Dublin Core genannt. Vielleicht wäre das auch was; habe das aber nur noch vage in Erinnerung, was das leistet und wie weit die mit dem Projekt sind...
(2.19.1.2) Re: Konvergenz, 27.10.2000, 12:59, Oliver Bandel: Vielleicht sollten man Möglichkeiten nutzen, die das Umsetzen der Programmierung und die Dokumentation vereinen. Literate Programming wäre da ein Stichwort. Ich denke, anders (Entwickler und Dokumentator getrennt) wäre es vielleicht mehr Kommunikations-Overhead?! Mit geeigneter Markup-Sprache könnte man die Sachen hier auch besser sortieren. Das würde deutlich weiterhelfen. Wenn man zum Beispiel ein Stichwort vergeben kann, das dann als einzelnes Stichwort gesucht wird, während man den rest der Erklärungen dazu ausblenden kann, dann würde der Text vermutlich stark schrumpfbar sein und man könnte alle anbgehandelten Themen anzhand der Stichworte ausfindig machen und bei Erledigung den kompletten Krams, der erledigt wurde, für die Neue Version raus nehmen. Das wäre dann in der Tat eine to-do-Liste: Erledigtes kann raus. Was das Literate programming angeht, habe ich schon ein paar Ideen für ein neues Progrämmchen. Das wird aber irgendwie auch mit Metadaten und Markup-Sprachen funktionieren müssen; man braucht halt irgend eine Syntax dafür. Vielleicht läßt sich das ganze dann ja mit ot Verknüpfen. Weiß noch nicht genau. Exkurs-ENDE! (Ist das Kacke, ohne Markup...) Exkurs:
(2.20) Namen der Kommentierenden, 18.10.2000, 17:45, Torsten Wöllert: Zur Zeit werden die Namen der Kommentierenden auf der Projektseite aufgeführt, was ich sehr gut finde. Bei einer neuen Version sollte der Maintainer jedoch die Möglichkeit haben, nur die Namen der Leute aufzuführen, deren Kommentare auch wirklich in diese Version eingeflossen sind. Das ergäbe dann zwei Namenslisten, eine für "Bereits eingearbeitete Kommentare von: ..." und eine für "Aktuelle Kommentare von: ...".
(2.21) Autoreninfo, 18.10.2000, 17:55, Torsten Wöllert: Vielleicht sollte man den Autoren und/oder Maintainern die Möglichkeit geben, außerhalb des eigentlichen Textes aber in Verbindung mit ihm einige Informationen über sich im OT zu hinterlegen. Das könnte sowohl einer kurzen Selbstdarstellung als auch dem Bekanntmachen von Kontaktmöglichkeiten jenseits der e-mail-Adresse dienen. Ggf. könnte man die Länge dafür begrenzen, um es nicht zu unübersichtlich werden zu lassen.
(2.22) Suchmaschine, 18.10.2000, 17:59, Torsten Wöllert: Weil OT glücklicherweise mit beachtlicher Geschwindigkeit wächst, wäre es bestimmt sinnvoll, sich über einen geeigneten Suchmechanismus nach bestimmten Stichworten, Autoren, Daten usw. Gedanken zu machen. Ansonsten läuft man Gefahr, sich bei nur gelegentlicher Benutzung von OT in der Fülle der Projekte und Texte zu verlieren.
(2.22.1) Re: Suchmaschine, 27.10.2000, 13:03, Oliver Bandel: Geeigenet markup-Sprache entwickeln/ausarbeiten und einsetzen Auch, wenn ich mich erneut wiederhole: Einen Vorschlag findet man hier: http://www.NetzService.de/Home/maro/mr_dml.html Ggf. wäre - langfristig und evtl. parallel zum eigentlichen ot-Server sinnvoll, eine freie Software zu entwickeln, die weitere Möglichkeiten eröffnet. Ggf. einen freien browser, der XML unterstützt und auf *diversen* Betriebssystemen verfügbar ist. Ansonsten: ich finde den Ansatz gut, daß hier auf möglichst geringem technischem Anforderungs-Niveau gearbeitet wird, um Kompatibilität zu gewährleisten! P.S.: Sind die Sourcen dieses Projektes auch frei zugänglich? Das wäre doch eigentlich der angemessene Weg.
(2.23) Metadaten, 18.10.2000, 18:05, Torsten Wöllert: Um die OT-Texte möglichst einfach find- und verfügbar zu machen, sollte man bestimmte Metadaten (z.B. Dublin Core) zur Charakterisierung eines Projektes/Textes verwenden können. Verbunden mit einer geeigneten Suchmaschine inner- oder auch außerhalb OT wäre das sicher sehr effektiv. Schließlich sollen die OT-Projekte ja möglichst "open", also auch erreichbar sein.
(2.24) Komplettes Runterladen, 26.10.2000, 17:11, Torsten Wöllert: Der Maintainer sollte nicht nur jedes einzelne von ihm betreute (Unter-)Projekt als Text runterladen können, sondern auch auf einen Schlag das komplette Projekt einschließlich aller Unterprojekte unter Beibehaltung der Dateinamen. Bei größeren OT-Projekten mit vielen Unterprojekten wäre das eine beträchtliche Hilfe.
(2.25) Feature-Liste/Doku, 27.10.2000, 13:09, Oliver bandel: Eine feature-Liste sollte es geben, wo alle vorhandene Funktionalität übersichtlich (Baumstruktur, Tabellen,...) zu finden ist und ggf. mal später genutzte Syntax übersichtlich erklärt wird. Das ganze am besten auf der Leiste mit "Home" "Was ist ot?" Vorbild" usw. unterbringen.
(3) Ein Logo für ot. Ausserdem Symbole, die anzeigen, dass ein Projekt Unterprojekte besitzt.
(3.1) Logo, 18.09.2000, 10:37, Stefan Meretz: Symbole, die anzeigen, dass es ein Projekt Unterprojekte hat, gibt es mit - und sie sind auch klickbar (Version 0.41b)! Ein tolles OpenTheory-Logo fehlt allerdings noch immer...
(4) Digest-Funktion (Versenden der Kommentare zu einem Projekt nur einmal am Tag) oder Sammelkommentare: Der User kommentiert und entscheidet dann selbst über das komplette Senden.
(4.1) Digest-Funktion, 09.06.2000, 15:41, Stefan Meretz: Geht jetzt: Wenn man sich anmeldet per Login (und nur dann), dann erscheint oben ein Button "Kommentare". Klickt man drauf, bekommt man alle bisherigen, eigenen Kommentare zum Projekt angezeigt. Schickt man diese nicht (wieder per Button) ab, dann werden sie automatisch am Morgen um 6.00 versendet. Die gesammelten Kommentare werden in einer Mail verschickt (je User und Projekt).
(5) Online-Archiv für Mails der Projekt-Mailinglisten
(5.1) 10.05.2000, 23:46, Thomas Kalka: Warum ist dies notwendig ? Da in einem Projekt nichts gelöscht werden kann, ist doch das Projekt selbst gleichzeitig das Archiv des Projekts ?
(5.1.1) Mailinglisten-Archiv, 15.05.2000, 17:35, Stefan Meretz: Witzigerweise, das muss ich jetzt mal für die nur-Web-User schreiben, hat es genau zu dem Punkt eine intensivere Mail-Debatte gegeben - die nicht mehr sichtbar ist. Grundsätzlich stimme ich dir zu, Thomas. Mittelfristig will ich jedoch von dem ausschliesslichen Web-Zugang weg und eine Eingabe und Kommentierung per Mail möglich machen. Dann wird es für den User aber noch schwieriger sein, allgemeine Debatten von Textkommentaren zu unterscheiden. Also ist eine Rubrik mit Meta-Kommentaren notwendig. Ich habe schon überlegt, auf der Textseite oben nochmal die Zusammenfassung (quasi als Absatz 0) einzublenden, an den dann die Metakommentare gehängt werden (Struktur wie bei einem Mailinglistenarchiv). Dann aber alles mit Ein- und Ausblenden.
(6) Übersetzen der GNU Free Documentation License ins Deutsche
(6.1) Link kaputt, 26.05.2000, 16:41, Thomas Uwe Grüttmüller: Macht aber nichts, denn das Original ist zu finden auf http://www.gnu.org/copyleft/fdl.html
(6.1.1) Re: Link kaputt, 27.05.2000, 19:18, Stefan Meretz: Ahaem..., der Link lautet korrekt http://www.opentheory.org/gfdl.phtml. Aber richtig, ist eh nur ein Duplikat der originalen GNU Free Documentation License.
(6.2) Übersetzungsprojekt, 26.05.2000, 18:35, Thomas Uwe Grüttmüller: http://www.opentheory.org/proj/gfdl_ger/v0001.phtml -- Besser wäre allerdings, solche Texte von vornherein in einer Sprache zu formulieren, von der aus verlustfrei maschinelle Übersetzungen in andere Sprachen möglich sind... Hmmm, gibts sowas schon? :o)
(6.3) Übersetzen der GNU Free Documentation License ins Deutsche, 04.06.2000, 05:06, Thomas Uwe Grüttmüller: Huhu! Wie ich gerade eben feststelle, hat irgendsoein anonymer Kaputter oder etwa sogar mehrere dieser Sorte das Mehrpersonen- Übersetzprojekt durch Mißachtung der nur-vier-Absätze-pro-Peron-Beschränkung hinterhältig sabotiert und einfach alle Absätze übersetzt. Daher liegt jetzt eine erste vollständige Version der Übersetzung vor. Hmmm, soll ich jetzt einen neuen Basistext machen? Werden sich an der Korrektur und Verschönerung mehr Leute beteiligen? Wer wollte überhaupt die Übersetzung haben? ;o) Alles sehr spannende Fragen...
(6.3.1) Re: Übersetzen der GNU Free Documentation License ins Deutsche, 04.06.2000, 17:54, Stefan Meretz: Cool, ej! Eine konstruktive Sabotage eines Experiments. Jetzt komm' ich gar nich mehr zu meinen drei Absätzen... Ich würde empfehlen, eine neue Version herauszugeben mit einer entsprechenden Zusammenfassung, die kurz die "Geschichte" der ersten Version beschreibt - unter Würdigung der anonymen Übersetzer. Der neue Text dient der Korrektur. Hm, allerdings ist der originale englische Text dann nicht mehr direkt dabei... Aber trotzdem bin ich für eine neue Version.
(6.3.1.1) Und jetzt? (was: Re: Übersetzen der GNU Free Documentation License ins Deutsche), 07.06.2000, 01:32, Thomas Uwe Grüttmüller: Nun ja, du kannst ja an der Verschönerung mitwirken. Ich habe es noch immer nicht geschafft, mir mal den Text als Gazes durchzulesen -- übrigens könnten jetzt die Absätze 6.1, 6.1.1, 6.2, 6.3, 6.3.1und 6.3.1.1 auf ein einfaches "Erledigt" zusammenschrupeln oder zusammen mit 6. ganz verschwinden (und nur noch im Listenarchiv zu finden sein) -- aber das muß ja bei der derzeitigen Lage alles der Webmaster von Hand machen...
(7) Doppelte Eingabe des Passwortes bei Neuanmeldung zur Sicherheit gegen Vertipper
(8) Ein-/Ausblenden der Kommentare auf der Seite des Projekttextes
(8.1) Kommentare ausblenden..., 18.09.2000, 10:33, Stefan Meretz: ... ist erledigt mit Version 0.41b.
(9) Maintainerschaft von mehreren Personen
(10) allgemeiner Meta-Kommentar zum gesamten Text
(11) verschiedene Kommentarvarianten, Punktesystem, Umfragen etc.
(11.1) Punktesystem, 18.10.2000, 17:38, Torsten Wöllert: Wenn man bspw. ein OT-Projekt "OT-Logo" einrichten will, wäre ein Punktesystem für die Bewertung der einzelnen Vorschläge, wenn möglich in mehreren Kategorien (Originalität, künstlerische Ausführung, Les-, Merk-, Druck-, Faxbarkeit usw.), sehr nützlich. Das würde ellenlange Kommentare ersparen.
(12) Optimierung der Seiten für die Einbindung auf fremde Web-Sites
(13) Eingabe der Texte und der Kommentare per Mail im Offline-Modus
(15) Hierarchisierung der Projekte (Bildung von Unterprojekten)
(16) Gemeinsame Verwendung von Mailinglisten von mehreren Unterprojekten
(17) Abgeben von Projekten an andere Maintainer (siehe FAQ)
(17.1) 05.05.2000, 00:00, Stefan Meretz: Erledigt. Der neue Maintainer muss bereits Mitglied des Projektes sein.
(18) Ersteingabe des Basistextes: Möglichkeit, Anzahl der neuen Absätze anzugeben
(19) Bei per Mail automatisch versendeten Kommentaren auch den Absatz mitschicken, auf den sich der Kommentar bezieht
(20) Hier werden die bekannten Fehler der aktuellen Version dokumentiert. Wenn Dir ein hier nicht aufgelisteter Fehler begegnet, trage ihn bitte als Kommentar hier ein - so erreicht er die Entwickler/innen.
(20.1) Re: Re kann nicht entfernt werden, 20.05.2000, 02:05, Thomas Uwe Grüttmüller: Verpaßt man seinem Kommentar einen neuen Titel, so wird "Re:" hinzugefügt, was unsinnig ist.
(20.2) Re: Bekannte Fehler in Version 0.4-beta, 20.05.2000, 02:16, Stefan Meretz: Ich befürchte, daß es das derzeitige Interface zuläßt, Kommentare unter dem Namen eines anderen Mitglieds zu senden :o)))
(20.2.1) Re: Bekannte Fehler in Version 0.4-beta, 20.05.2000, 11:18, Stefan Meretz: Well, das ist eine Grundsatzfrage: Kommentare offen für alle, was anonyme und gefakte Kommentare einschliesst, oder Kommentare nur von angemeldeten ot-Usern. Das zweite hatten wir anfangs, und viele empfanden die Hürde als zu hoch (kein Bock, sich als ot-User anzumelden und dann jedesmal einzuloggen nur für einen Kommentar mal eben). Schaun wir mal... (P.S. Thomas Uwe Grüttmüller hat mit (20.2) demonstriert, dass das Faking funktioniert).
(20.2.1.1) Re: Bekannte Fehler in Version 0.4-beta, 20.05.2000, 18:41, Thomas Uwe Grüttmüller: Mist, ertappt :o) ... Also, es geht darum: Ich denke, daß es wichtig ist, den Kommentatoren auch die Möglichkeit zu bieten, ihre Kommentare zu ändern oder wieder zu entfernen, da sich bei der jetzigen Situation der Text immer weiter aufbläht. Dafür muß aber ein funktionierendes Login vorhanden sein. (Ich dachte übrigen erst, daß es wirklich ein Fehler sei)
(20.2.1.2) Kommentare - für jeden oder nur für Projektmitglieder? Membership-Moderation?, 15.09.2000, 20:45, Stefan Riesner: Wie wäre es mit verschiedenen Arten von Projekten - offene, in denen jeder einen Kommentar schreiben kann, halboffene, in denen nur Projektmitglieder kommentieren dürfen und geschlossene, in denen eine Projektmitgliedschaft von den Maintainern akzeptiert werden muß (z.B. für Sabotage-gefährdete Projekte oder interne OT-Projekte irgendeiner Organisation)? (Ist die Frage, in wie weit letzteres noch OT wäre, aber da Maintainer ja sowieso letztendlich die Kontrolle über den entstehenden Text haben, ist es vielleicht auch vertretbar, ihnen bei der letzten Variante die Kontrolle über die Projektmitgliedschaften zu geben.)
(20.2.1.2.1) Re: Kommentare - für jeden oder nur für Projektmitglieder? Membership-Moderation?, 16.09.2000, 20:47, Stefan Meretz: Ja, das gefällt mir. Dann liegt die Entscheidung bei den Menschen (den Maintainern) - da, wo sie auch hingehört (und eben nicht bei der Technik). Wenn sich kein vehementer Protest erhebt, will ich das in eine nächste Version mit aufnehmen.
(20.3) Re: Bekannte Fehler in Version 0.4-beta, 03.10.2000, 07:43, Thomas Kalka: Das Projekt-Login klappt nicht. Bei der Projektmitgliedsverwaltung klappt es hingegen. Vielleicht könnten wir das zusammen durchspielen ?
(20.3.1) Re: Bekannte Fehler in Version 0.4-beta, 05.10.2000, 21:26, Stefan Meretz: Check mal zwei Dinge: Das häufigste Problem: Im Namensfeld muss die E-Mail-Adresse eingetragen werden. Ist das ok? Das zweithäufigste Problem: Bist Du in dem konkreten Projekt - und nicht etwa nur im übergeordneten Projekt - als Mitglied eingetragen? Bei letzterem habe ich mich selbst schon vertan...
(20.4) Repost-From-Data -- mehrfacher Eintrag, 27.10.2000, 13:04, Oliver Bandel: Wenn man reload-button des Browsers drückt und bei repost from data ok klickert, wird der eingetragene Kommentar ein zweites mal eingetragen!
(21) Der Login-Vorgang auf der Textseite der Projekte funktioniert nicht mit den Browsern von Opera und Naviscope.
(22) Sonderzeichen und Umlaute in Kurztiteln der Projekte sind unzulässigerweise möglich, was beim Anlegen der Projekt-Homeverzeichnisse zu Problemen führt
(23) Der Browser Opera stellt die Einrückungen beim Projekttext nicht dar.
(24) Mails können nur per "To:" ("An:") versendet werden, nicht per "Cc:" oder "Bcc:"