SourceForge beendet Unterstützung für Hosted Apps => kein Wiki mehr

[makki]

Also, ich hab die Sitenotice nun entfernt - CometVisu ist die neue Heimat der CV-Doku.

Das mit dem Spam ist nicht so dramatisch, die Accounts müssen ja eh manuell per eMail bestätigt werden, alle Pages werden gewatched. Momentan überwiegt für mich die offenheit für jeden ohne manuellen Admin-Eingriff, wenn das überhand nimmt muss man sich natürlich was überlegen..
Wenn sich die gute Handvoll editoren einfach "ihre" Seiten auf Watch setzen gibt ein eMail und zwei Klicks zum rollback, dann verlieren die Spammer auch den Spass glaub ich

Makki

[makki]

Nun, auf dem WG läuft nur OSS/GPL, das ist kein Unfall sondern ein Grundprinzip.
Confluence ist damit wohl mal raus.

Ich hatte das neue Wiki ganz bewusst völlig offen gelassen, ist ja auch nichts schlimmes passiert..
Wenn es nicht überhand nimmt würde ich das auch so lassen, das bisserl kann man aufpassen (bei o.g. habe ich 48h deswegen nichts gemacht, weil ich wissen wollte, was das Ziel ist.. hier wohl einfach: garkeins)

Makki

[fanta2k]

@fanta2k:

Da bin ich anderer Meinung. Das Wiki hat zwar gewisse Einschränkungen aber es ist leicht zu bedienen und bietet im Grunde alles was es braucht. Dazu kommt, dass es absolut kostenlos ist. Egal wie viele daran mitarbeiten wollen.

Das von dir genannte Produkt:

1. Kostet es Geld
2. Ist die anzahl der Editoren durch die Lizenz beschränkt
3. Sieht es eher aus wie Facebook. Ähnelt also eher einer SocialNetwork Seite als einem Handbuch

Da es sich um eine Community Entwiklung handelt in die viele Leute unentgeltlich ihre Freizeit investieren war auch ein wichtiger Punkt den Aufwand beim Umzug des Handbuches möglichst gering zu halten. Sonnst müsste wieder jemand Tage damit verbringen die Datensätze in ein neues System einzupflegen. Dies erfordert auch wieder Einarbeitungszeit.

Also ich bin nach wie vor zufrieden mit dieser Lösung Und dass man bei einem anderen System besser geschützt ist vor Hackern und Spamern mag ich auch zu bezweifeln.

War nur eine Empfehlung

Wir arbeiten bei uns mit Confluence+Jira mit über 100 Devs, jedoch auch bei kleinen Projekten ist ne brauchbare Doku wichtig.

Habe auch alles durchgekaut von Mediawiki bis Dokuwiki, Help&Manual etc.

Was mit pers. bei den Wiki lösungen fehlt ist eine vernünftige Navigation für den Endbenutzer (Das Handbuch muss ja auch jemand lesen) d.h. ein immer sichtbarer Baum.

Bzlg mediawiki spam, confirmEdit plugin einsetzen und auf MatchCaptcha oder reRaptcha stellen.

[Chris M.]

Zum SPAM (pauschal, kenne die konkreten Möglichkeiten des Mediawiki nicht...):

Man kann versuchen den Captcha o.ä. so zu erweitern dann die ganz simplen Skripte nicht mehr durchkommen. Das wird das Auftreten verringern, aber nicht beenden.

Bleibt also nur noch die Philosophie-Frage: pro aktiv oder reaktiv?
D.h. entweder wir erlauben Schreibrechte nur nach manueller Freischaltung des Accounts oder wir scannen regelmäßig die Änderungen und machen die ggf. rückgängig.

Für User ist reaktiv natürlich die geringere Einstiegshürde. Würde aber ein paar Leute aus der Community erfordern, die diesen Job machen wollen und auch zuverlässig machen (a la Stefan-setzDenHaken!-Werner ), das würde ich auf Dauer nicht dem Admin zumuten wollen.
Bis dahin finde ich ein pro aktives Vorgehen absolut geeignet (war unter SF auch nicht anders)

[Chris M.]

Also ich pers. finde mediawiki für Software Dokumentationen absolut unbrauchbar [...]

Warum nehmt ihr nicht [...] ?

Mir ist die Software bzw. das System für die Dokumentation völlig egal. Ich habe lediglich zwei Anforderungen (neben dem, dass ich dafür kein Geld ausgeben werde):

1. Möglichst wenig Aufwand für mich
2. Design der Seiten muss vernünftig sein, d.h. einem gewissen minimalen Anspruch genügen

Dabei ist Punkt 1. besonders wichtig - und der impliziert, dass die Einstiegshürde für andere gering sein muss. Denn Doku die andere schreiben ist kein Aufwand mehr für mich.


Mediawiki erfüllt beide Punkte. Trac finde ich bei 2. mehr als grenzwertig (habe aber noch nicht geschaut, ob's nur an der Konfig liegt). Und viele der [...] werden vermutlich an 1. scheitern, wäre aber natürlich im Detail zu prüfen (was aber wieder in Konflikt mit 1. stehen kann...)

[swiss]

@fanta2k:

Da bin ich anderer Meinung. Das Wiki hat zwar gewisse Einschränkungen aber es ist leicht zu bedienen und bietet im Grunde alles was es braucht. Dazu kommt, dass es absolut kostenlos ist. Egal wie viele daran mitarbeiten wollen.

Das von dir genannte Produkt:

1. Kostet es Geld
2. Ist die anzahl der Editoren durch die Lizenz beschränkt
3. Sieht es eher aus wie Facebook. Ähnelt also eher einer SocialNetwork Seite als einem Handbuch

Da es sich um eine Community Entwiklung handelt in die viele Leute unentgeltlich ihre Freizeit investieren war auch ein wichtiger Punkt den Aufwand beim Umzug des Handbuches möglichst gering zu halten. Sonnst müsste wieder jemand Tage damit verbringen die Datensätze in ein neues System einzupflegen. Dies erfordert auch wieder Einarbeitungszeit.

Also ich bin nach wie vor zufrieden mit dieser Lösung Und dass man bei einem anderen System besser geschützt ist vor Hackern und Spamern mag ich auch zu bezweifeln.

[tht]

Im professionellen Umfeld freue ich mich auch immer, wenn meine Kunden die Produkte von Atlassian einsetzen, sich also die Lizenz geleistet haben. Und hier wird genau die Knackpunkt liegen: mediawiki ist frei, confluence kostet für 10 User 10$, danach sind wir aber schon bei 800$! Damit ist es für ein OSS-/Community-Projekt zu teuer bzw unflexibel.

Wobei das nur meine Meinung ist und nicht die der Verantwortlichen...

[fanta2k]

Also ich pers. finde mediawiki für Software Dokumentationen absolut unbrauchbar (Fehlende Navigationsmöglichkeiten etc).

Warum nehmt ihr nicht Confluence ?

https://www.atlassian.com/software/confluence/overview

[swiss]

Hmmm...

Ich dachte das man bei uns nur als Editor "Schreibrechte" erhält. Wie ist es denn möglich dass jemand mit einem Useraccount bei uns spamen kann?

[makki]

Wir (ich) haben da noch ein kleines "Spam"-Problem, habs ja absichtlich offengelassen aber Euwetoo542 hat uns vorgestern einen Aufsatz über irgendeine Englische Kleinstadt hinterlassen

Makki

(Was auch immer der Sinn ist - wenns wenigstens ein paar gescheite Porno-Links wären )

[makki]

Ich tendiere zu der technisch besten Lösung (was auch immer diese ist?!)
Wie die URI aussieht, ob "../manual/de" oder "../de/Handbuch" merkt der normale Anwender im optimalfall ja garnicht (und das kümmert ihn auch nicht was da oben steht)

Makki

P.S.: MediaWiki kann das schon auch nachm Language-Header im Browser irgendwie, das ist zwar machnmal lästig (für mich, ich will eher EN) aber fürn AW "smart" weil einfach richtig..

[swiss]

Ja das denke ich auch. Danke auch dir für die Hilfe

Die Frage stellt sich nun nochmal wegen der Multilingualität.

Ich verstehe Chris gut. Die seitennamen sind nun relativ gewöhnungsbedürftig. Die Frage ist, wie man das am besten umsetzen könnte...

Was ich für eine Automatisierung brauche ist die eindeutige angabe der Sprache (am liebsten am ende) und einheitliche Seitennamen in allen Sprachen.

Wenn die beiden Punkte erfüllt sind, sind der Fantasie keine Grenzen gesetzt.

Möglich wären z.B.:

CometVisu/Switch/de
CometVisu/Switch_(deutsch)
Cometvisu/de/Switch
...

Da frage ich mich aber, ob der ursprüngliche Ansatz nicht doch der beste war? Würde auch mit einem hohen Automatisierungsgrad funktionieren. Gleich wie der jetztige Stand, übernommen vom MediaWiki

[makki]

Danke Patrik!
Wenn das (möglichst automatische) Konzept steht, ist das übersetzen DE->EN IMHO eher eine Entspannungsübung für laue Spät-Sommernächte

Makki

[swiss]

Danke

[Bodo]

Ich hoffe jemand mit guten englischkentnissen könnte sich mal der einen oder anderen Seite annehmen

Hoi

Ja ich hab's gehört