Aktualnie do spejsowego wiki wykorzystujemy wiki na GitHubie. Problem z nim jest taki, że UX tego rozwiązania jest delikatnie ujmując średni. Czuć, że wiki na GitHubie to obywatel drugiej kategorii. Poniżej jeden z przykładów:
Jako, że ostatnio HSP przemigrowało swoje wiki na wiki.js, rzuciłem na nie okiem i wygląda całkiem spoko. Ma kilka atrakcyjnych dla nas cech:
Tworzenie stron w markdownie
Można trzymać strony w repo git
Jest SSO
Wygląda schludnie
Można mieć daną stronę w wersjach pl i en
Pierwsze dwa pozwalają na stosunkowo prostą migrację już istniejącego wiki, jako że nasze wiki pod spodem to git repo ze stronami w markdownie. Mimo tego nie importowałbym jednak wszystkiego “as is”, a wykorzystał to jako okazję do uporządkowania wiki. Dobrze byłoby przenieść tylko strony, które są aktualne i odzwierciedlają stan faktyczny, tak aby w szukajce nie pojawiały się starocie, które będą wprowadzać ludzi w błąd. Stare wiki można zostawić w celach historycznych, tylko trzeba by opatrzyć je stosowną informacją, że zebrane tam treści są archiwalne i nowe wiki znajduje się w innym miejscu.
Oczywiście to tylko “propozycja podania”, więc jak ktoś ma jakieś sugestie, uwagi i propozycje to śmiało. Punkt wyjścia to zmiana wiki na GitHubie na coś sensowniejszego.
To wiki githubowe ma chyba opcję archiwizacji całości w plikach json, które razem z historią edycji można zaimportować na wiki.js:
IMHO to są dwie opcje: albo importować to tak jak jest i robić porządek już na nowej wiki - import automatyczny pewnie nie przebiegnie 100% idealnie więc i tak po imporcie trzeba będzie wszystko poprzeglądać…
albo zrobić porządek na obecnym wiki i przerzucić to importem dopiero po uporządkowaniu.
Mamy 105 stron teraz na tym wiki - więc IMHO ręczne przenoszenie wszystkiego to będzie nudna i nużąca robota… Porządkowanie też - ale jednak porządkowanie to będzie gdzieś 1/3 tego co by trzeba zrobić przy zupełnie ręcznym przenoszeniu.
Nie jestem jakimś wielkim fanem trzymania wszystkiego na innym projekcie. Github jest dla mnie wygodny o tyle, że to jest w jednym miejscu, za jednym logowaniem (nawet jeśli weźmiemy pod uwagę SSO) ale prawdopodobnie nie jestem reprezantywny w tym względzie. No i kolejna rzecz do utrzymywania. Jak ma być ładnie to może renderować jakoś tego markdowna do github pages?
This. Z tym, że nawet bym to zmodyfikował do postaci, że obecne wiki oznaczamy jako ARCHIVE i robimy od nowa. Szukałem jakiegoś info o topologii sieci w spejsie i znalazłem stronę na wiki ostatnio edytowaną w 2021r. Chyba nie musze mówić, że średnio pomogło. Podejrzewam, że takiej zapuszczonej dokumentacji jest więcej - będzie okazja odświeżyć.
Ze swojej strony mogę podrzucić jeszcze propozycję używania wbudowanej w Discourse funkcjonalności wiki. U nas się to o tyle sprawdza, że dzięki temu ludzie nie muszą się logować do i uczyć kolejnego narzędzia - wyszło nam na to, że łatwość użycia i likwidowanie barier wygrały z “koszernością” rozwiązania… wiki było martwe, a na forum dokumentacja dużo bardziej żyje.
Dobrym pomysłem byłoby zachowanie wiki na Githubie, ale zamiast tego w klasycznym repozytorium. Edycja wiki wciąż odbywałaby się w Markdown lecz za to można byłoby klonować repo do dowolnego oprogramowania obsługującego format Markdown. To ułatwiłoby z pewnością aspekt automatyzacji, bo z mojego doświadczenia trudniej jest zautomatyzować przy pomocy gh-actions repozytorium ‘.wiki’ tworzone przez użycie funkcji wiki na githubie.
Nie, nie zachowujmy wiki na githubie z edycją przez pliki markdownowe tamże.
Tylko jako archiwum.
Wiki ma być łatwe w użyciu. Też dla ludzi, którzy nie wiedzą, co to kod źródłowy.
Przypominam ostatnią dyskusję z czata o blogu.
@kpc Rozumiem, że chodzi ci o to aby wiki było edytowalne przez GUI? Nie możemy zwyczajnie zostać przy Github wiki, ale problem czytelności rozwiązać poprzez napisanie skryptu na generowanie statycznej strony wiki z plików markdown?
Dzięki temu edycja mogłaby wciąż odbywać się przy pomocy Github Wiki, a osoby chcące to zautomatyzować mogłyby to zrobić dzięki temu, że pliki Markdown są trzymane również w osobnym repo.
Możemy, ale problem w tym, że Github Wiki nas ogranicza. Masz np. wspomniany przez @pmysl problem z wyszukiwaniem, i odnoszę wrażenie, że takich case’ów będzie coraz więcej.
Mnie wkurza np. brak wbudowanej hierarchiczności stron, trzeba stosować jakieś obejścia, rzeźbić ręcznie menu (okej, to pewnie dałoby się zautomatyzować).
Korzystanie z narzędzi Microsoftu też jakoś super nie wygląda, choć to akurat rzecz kompletnie drugorzędna.
Jestem zdecydowanie za wymigrowaniem się na zewnętrzne narzędzie.
W takim razie zamiast tego mogę zaproponować DokuWiki. Posiada wyszukiwarkę, defaultowy syntax wygląda na dość prosty oraz istnieją pluginy dodające wsparcie syntaxów Markdown oraz Mediawiki, co zadowoliłoby osób przyzwyczajonych do innych syntaxów niż Markdown (np. Polimerka). Aspekt logowania oczywiśnie można byłoby rozwiązać poprzez wymóg uniwersalnego konta Hakierspejs (istnieje nawet plugin do tego).
Postaram się w najbliższym czasie to przetestować na VM HSŁ i dam znać jak to działa oraz jak to można łatwo zmigrować z Github Wiki.
Ja kiedyś dokuwiki męczyłem i nie byłem zachwycony. Bo rozumiem, że instalacja MediaWiki jest przyciężka i nie potrzeba nam wiki wszystkomającego? Nstomiast jeśli chodzi o wikikod - to na mnie się nie oglądajcie. Wikikod w mediawiki od początku Wikipedii tak się zmienił, że dam radę edytować też inne wiki, choć w tym githubowym irytujące jest dla mnie, że linki się tworzy na odwrót niż w mediawiki.
MediaWiki wymaga działania dodatkowej bazy danych na serwerze, co na nasze potrzeby spejsowe jest overkillem + jest dodatkowym resourcem którego trzeba pilnować.
Można rozpatrzyć MediaWiki w sytuacji gdy DokuWiki czy wiki.js się nikomu nie spodoba, ale tak to nie potrzebujemy czegoś wszystkomającego.
Mamy Dokuwiki w HSWro właściwie od początku istnienia. Od strony utrzymania to nigdy nie był super soft - praktycznie zawsze po aktualizacji coś się wysypuje w nieoczywisty sposób. Co prawda przywrócenie poprzedniej wersji to po prostu rozpakowanie backupa w zipie - ale nadal, ten tool słabo się zestarzał. Pluginy to swoją drogą największe źrodło bólu przy aktualizacjach…
