Użytkownik:.azhag/Brudnopis

Szkic konwencji

Konwencja ogólna

Prawa autorskie

Większość wpisów na portalu udostępnionych jest na licencji Creative Commons 2.5 by-nc, o czym informuje stopka.

Jeżeli tekst objęty jest inną licencją to załączona jest stosowna informacja.

Język

Poprawne pisanie

Portal ma w nazwie symbol "PL", a w tytule przymiotnik "polski", więc wszelkie treści musza być napisane w tym właśnie języku.

Pisanie bez polskich znaków diakrytycznych (tzw. "ogonków") jest akceptowalne, jednak niemile widziane; wymagane jest poprawianie wszelkich zauważonych braków.

Język polski jest wystarczająco bogaty, by gros z wyrazów pochodzenia obcego zastąpić polskimi odpowiednikami.
Pomocne mogą być:

• Słownik tłumaczeń GNOME
• Informatyczny słownik angielsko-polski

Pisownia wyrazów "Fluxbox" i "Linux"

Na temat odmiany rzeczowników zakończonych na literę X trwa spór językoznawców, my na potrzeby portalu i forum przyjęliśmy za formalnie obowiązującą wymianę końcówki -x na -ks w przypadkach innych niż mianownik liczby pojedynczej

M.   Linux      Fluxbox
D.   Linuksa    Fluxboksa
C.   Linuksowi  Fluxboksowi
B.   Linuksa    Fluxboksa
N.   Linuksem   Fluxboksem
Msc. Linuksie   Fluxboksie

Pisownia nazwy naszego menedżera okien jest niejasna, na stronie fluxbox.org znaleźć można pisownię fluxbox, Fluxbox, FluxBox. Za obowiązującą przyjęliśmy pisownię

Fluxbox

Emotikony

Uśmieszki w żaden sposób nie wzbogacają oficjalnego tekstu, dlatego zdecydowanie odradzamy używania we wpisach emotikon.

W komentarzu wyraźnie wydzielonym z właściwego tekstu możemy sobie ostatecznie pozwolić na emotkę, ale to też w umiarkowanych ilościach.

do przedyskutowania

• propozycja Minia - brak emotikon
• propozycja azhaga - nakaz bardzo oszczędnego używania tychże, raczej unikać, ale w luźniejszych momentach można sobie pozwolić

raczej brak emotikon - chyba ze w komentarzach wydzielonych z tekstu. Jakos mało poważnie wygląda tekst - technologiczny w końcu (choć innych to tez dotyczy), okraszony ";)" i ":)" --Endel 10:21, 9 mar 2007 (CET)

Wydaje mi się, że właśnie artykuły mozna potraktowac ulogowo. W końcu tekst tam znajdujący się może być lżejszy, co mógłby ujawniać również swoją formą (czyli obecnością emotek właśnie). Dlatego zamieniłbym "artykułach" na "tekstach" w pierwszym akapicie (zdaję sobie sprawe, że rodzi to powtórzenie, ale w tym wypadku słowa te nie powinny być traktowane jako synonimy). --Minio 17:15, 13 mar 2007 (CET)

ok, nawet udało się nie uzyć słowa "tekst", słownik synonimów rulez ;]

oczywiście chodziło o "artykuł" w znaczeniu "tekst", nie "tekst z Artykułów" ;]

--.azhag 17:58, 13 mar 2007 (CET)

Inne uwagi

Fluxbox może działać nie tylko na systemach z jądrem Linux, część czytelników (a nawet jeden z administratorów) nie używa w ogóle GNU/Linuksa. Dlatego sugerujemy używanie słowa "system" zamiast "dystrybucja", które nie jest właściwym określeniem systemów opartych o inne jądra (chyba że masz na myśli konkretną dystrybucję GNU/Linuksa).

Tagi

Aby tekst był czytelniejszy używamy odpowiednich tagów.

• ścieżki i nazwy plików otaczamy tagiem <tt></tt>, przykład: ~/.fluxbox/init
• nazwy programów piszemy czcionką pogrubioną, przykład: gimp
• listingi piszemy tekstem preformatowanym, przykład:

Mod1 F1 :Workspace 1
Mod1 F2 :Workspace 2
Mod1 F3 :Workspace 3
Mod1 F4 :Workspace 4

• polecenia piszemy tekstem preformatowanym lub otaczamy tagiem <code></code>, przykłady: echo $USER

dpkg -l | grep fluxbox | awk '{print $2}'

Czy <code></code> nie można by zostawić dla wyróżnienia fragmentów z tekstu, a kursywę dla scieżek i nazw plików - tak jak to bylo poprzednio?

Dawało by to wieksze możliwości - bo w jaki sposób wyróżnić z tekstu krótką cześć kodu? np "*font: sans-10" - z <pre></pre> nie będzie to wyglądać dobrze.

endel

• powiem szczerze, że mi osobiście kursywa niezbyt odpowiada do tego celu, <code></code> jest stosowane do ścieżek i plików na wikipedii i wydawało mi się to lepszym rozwiązaniem. a może <tt></tt> dla ścieżek (/przykładowy/plik)? pismo maszynowe wg mnie dużo lepiej się nadaje niż kursywa --.azhag 16:36, 1 mar 2007 (CET)

• <tt></tt> to dobry pomysł, taka właśnie pisownia jest również stosowana w Wikipedii przykład i łatwo będzie zmodyfikować istniejące już teksty do takiego schematu. --Endel 20:17, 1 mar 2007 (CET)
• ok, zmieniłem --.azhag 22:09, 1 mar 2007 (CET)

Komunikaty

Czasami zachodzi potrzeba zakomunikowania czytelnikowi pewnej sprawy. Aby zachować spójność w podobnych komunikatach można skorzystać z szablonów.

Uwaga

Szablon Uwaga służy do ostrzeżenie czytelnika przed potencjalnym zagrożeniem związanym z poradą lub zwrócenie uwagi na inną ogólną sprawę związaną z tekstem.

Przykład użycia: {{Uwaga|Zastosowanie się do porad zawartych w tekście powoduje kernel panic}} daje w efekcie

Uwaga! Zastosowanie się do porad zawartych w tekście powoduje kernel panic

Różne systemy

Użyj tego szablonu, jeżeli chcesz powiadomić czytelnika, że podane w tekście ścieżki i nazwy plików konfiguracyjnych mogą się różnić w zależności od używanego systemu operacyjnego. (TODO)

Licencja

Ten szablon służy do powiadomienia czytelnika, że tekst z jakichś powodów objęty jest inną niż CC-by-nc licencją. (TODO)

Niepoprawna nazwa

Nazwy niektórych programów zaczynają się od małej litery, np. gentoo. Z powodu ograniczeń technicznych MediaWiki, pierwsza litera artykułu zawsze zostaje zamieniona na wielką. Możesz posłużyć się szablonem {{lowercase}} aby poinformować o tym czytelnika.

Można też podawać czytelnikowi zupełni inną nazwę, posługując się {{lowercase|jEdNa MaŁa, DrUgA DuŻa}}, co da:

Nowe teksty

Nowe teksty powinny w pierwszej kolejności trafić do kategorii Tekstów do akceptacji, aby był czas na ewentualne przedyskutowanie artykułu, wyłapanie błędów i nieścisłości przed oficjalnym umieszczeniem ich we właściwej kategorii.
Tekst zostanie przeniesiony po około 3-4 dniach od ostatniej uwagi w Dyskusji danego tekstu. W przypadku Artykułów o subiektywnym charakterze czas ten może być krótszy.

Aby prawidłowo oznaczyć nowy, nie zaakceptowany jeszcze tekst należy w pierwszej linijce umieścić kod

{{do akceptacji}}

W pewnych przypadkach (np. przerzucenie rozwiązania wypracowanego na forum, przeniesienie tekstu z innej strony) można umieścić tekst od razu we właściwym miejscu. W takim wypadku zostaniesz o tym powiadomiony - nie rób tego na własną rękę.

Przykładowe tematy nowych tekstów możesz znaleźć na stronie FluxboxPL.org:Propozycje tekstów.

Brudnopis

Wszelkie eksperymenty możesz śmiało przeprowadzać w publicznym brudnopise. Należy jednak pamiętać, że tekst w publicznym brudnopisie może każdy edytować i nie zostanie on w nim na zawsze.

Jeżeli chcesz napisać jakiś tekst "na brudno" i mieć pewność, że nikt go przypadkiem nie skasuje lepiej użyj osobistego brudnopisu. Możesz w nim tworzyć podstrony, np. Użytkownik:Twój_login/Brudnopis/Artykuł_testowy.

Edycje i Dyskusje

Większość tekstów zamieszczonych na stronach FluxboxPL.org objętych jest licencją Creative Commons 2.5 by-nc, a sam portal wykorzystuje silnik MediaWiki. W związku z tym każda zalogowana osoba może je edytować. Jednak niektóre osoby mogą sobie nie życzyć cudzej ingerencji w ich tekst. Dlatego bardzo prosimy, aby nie dokonywać samodzielnie większych zmian w cudzych tekstach (zwłaszcza w Artykułach, w których często autorzy zamieszczają osobiste, subiektywne zdanie), tylko przekazywać uwagi ich autorom.

Służy do tego strona Dyskusji danego artykuły - jeżeli chcesz zwrócić uwagę na błąd, niedomówienie, zamieścić jakiś komentarz - możesz to śmiało zrobić właśnie w tym miejscu. Nie trzeba być zalogowanym aby edytować strony Dyskusji.

Jeżeli zauważysz w tekście drobny błąd - literówkę, błąd ortograficzny, brak kropki czy przecinka - nie krępuj się i popraw go od razu.

Wszelkie objawy wandalizmu będą piętnowane, a ich autory karani (w skrajnych przypadkach przez odcięcie możliwości edycji stron).

Podpis

Teksty z kategorii Artykuły (jako osobistą wypowiedź) autorzy powinni zawsze podpisać, aby oddzielić podpis od tekstu dobrze jest zastosować poziomą linię (----).

Autorzy howto lub prezentacji programu mają prawo podpisać swoją pracę. Osobom modyfikującym gotowe prace to prawo nie przysługuje.

Jeżeli tekst na FluxboxPL.org przeniesiony jest z innego serwisu to można (a w pewnych przypadkach wręcz trzeba) w podpisie zawrzeć informację gdzie tekst pierwotnie był opublikowany.

Niesie to ze sobą pewne problemy.

Weźmy chociażby mój tekst o mpd. Gdy go obejrzałem, sam się zdziwiłem - tak dalece został zmieniony (i chwała za to).

Powiedzmy, że byłby on podpisany przeze mnie na dole. Jak w takiej sytuacji miałby się zachować Mazdac?

Gdyby nic nie zrobił, a ktos inny skopiowałby tekst, oznaczyłby go moim nickiem. Są 2 problemy takiego rozwiązania:

• Mazdac nie zostaje uwzględniony w "contribs", chociaż dokonał zaawansowanych zmian i w pełni na to zasługuje
• jestem podpisany pod praca, która nie jest w całości moim dziełem. Osobiście nie chcę być kojarzony ze słowami, których nie wypowiedziałem

Mógłby również usunąc moje autorstwo i podac swoje. Ktos kopiuje tekst i podpisuje go jego nickiem - wtedy jednak ja jestem pokrzywdzony, gdyż praca końcowa została stworzona na podstawie mojej, jednak nie zostało o tym wspomniane na stronie. Jest to również złamania zasad licencji CC by.

Wreszcie trzecia opcja - Mazdac po dokonaniu zmian dopisuje się pod moim podpisem. Wtedy autorów jest dwóch i jest to słuszne (zgodne z zasadami CC by).
Takie rozwiązanie ma jednak kolejne dwie wady:

• po dokonaniu wielu zmian (co wydaje mi się rzecza w pełni normalną na MediaWiki) lista autorów na dole strasznie by się rozrosła
• tworzenie listy autorów na dole artykułu uważam za bezsensowną, gdyż każda strona ma zakładkę "historia", która zawiera informacje o autorach, dokonanym wkładzie (można porównywać wcześniejsze wersje ze sobą) oraz dacie modyfikacji

Najprostszym rozwiązaniem problemów przedstawionych powyżej jest zwykłe usunięcie przyczyny. Dlatego aktualnie uważam podpisywanie się pod tekstem za niepotrzebne - "historia" dostarczana przez MediaWiki wydaje mi się spełniać nasze wymagania w tej kwestii.
--Minio 16:02, 1 mar 2007 (CET)

wg mnie sprawa powinna być rozwiązana w ten sposób - cudze teksty edytujemy wyłącznie jeśli sa to poprawki kosmetyczne i w takim wypadku nie zasłużyliśmy się na tyle aby nasz nick był pod tekstem. jeżeli są jakieś większe zmiany w tekście - piszemy o tym w Dyskusji #Edycje i Dyskusje i autor poprawia tekst, może przy tym (a wręcz powinien) w "contributions" dodać, że w tym a tym fragmencie wykorzystał uwagi tego a tego

owszem, w historii jest szczegółowy wykaz "co i kto" i my o tym wiemy. ale osoba z zewnątrz nieobcykana z MediaWiki może tego nie wiedzieć

dlatego mimo wszystko zostawiłbym podpisy, dodał może do tekstu "hierarchię": autor, współautor, uwagi do..., poprawki w..., etc.

--.azhag 16:57, 1 mar 2007 (CET)

Do przekazywania inormacji o tym, gdzie należy szukać "contribs" może służyć jedna z trzech stron, do których linki są zawze w stopce:

• General disclaimer
• Zasady ochrony prywatności
• O serwisie

wydaje mi się naturalnym, że ktoś, kto chce skopiowac jakiś tekst, zapoznaje się z treścią tego typu stron, więc prosze nie przytaczać argumentów o ich (stron) rzekomej niedostępności

Osobiście bedę bronił usunięcia podpisu z treści howto i programów. Artykuły, jako z natury subiektywne, nie powinny w ogóle być modyfikowane przez osoby inne niż autor (chyba że chodzi o poprawianie błędów, ale i to jedynie tych, których niepoprawność da się obiektywnie stwirdzić).

Te pierwsze jednak nie powinny być nachalnie podpisywane (owszem, uważam to za nachalne). Jako zwykły uzytkownik Internetu mogę powiedzieć, że podpis naprawdę nie jest aż tak ważny - jeżeli będe chciał się w jakiś sposób z autorem skontaktować lub dowiedzieć o nim więcej, poszukam odpowiednich działów.

Tutaj zahaczamy o temat zaufania dla treści zamieszczonych w Internecie. Nie mam zamiaru go drążyć, gdyż jest niesamowicie rozległy. Przejde tylko do konkluzji - w Internecie treści anonimowe są normą. My nie będziemy przecież własnych tożsamosci ukrywać. Jestem jedynie przeciwny zbytniemu ich uwypuklaniu. Wychodze z założenia, że kto bedzie chciał dowiedzieć sie czegoś o autorze tekstu, ten sobie poszuka (i znajdzie w ciągu sekund). Kto nie będzie chciał, nie chce pewnie rónież wiedzieć - dlaczego więc te informacje mu na siłe przekazywać?

Stworzyłem bardzo chaotyczny i krótki artykuł w moim brudnopisie, który być może pomoże w zrozumieniu mojego punktu widzenia na całość.

i może przerzucić akapit Podpis za Edycję i Dyskusję?

dopiero jak dojdziemy do kompromisu stwierdzającego, że podpis zostaje ;)

Przykry jest również fakt, że najwięcej kontrowersji wzbudził temat czyj nick znajdzie się pod tekstem (wg mnie nie powinien żaden). --Minio 18:55, 1 mar 2007 (CET)

*Co do artykułów jest widzę zgodność - nie powinny byc modyfikowane przez osoby inne niż autor (poza drobnymi poprawkami oczywiście - dzięki Minio ;) ). Co do podpisów pod Howto i opisami programów, najprościej by było gdyby nie były podpisywane. Ale coniektore teksty w howto, bedace oryginalnie na lamach innych portali muszą być podpisane i nie mogą podlegać jakiejkolwiek modyfikacji. Stad ponawiam swoja propozycje aby takie teksty (np o Sudo) przenieść do "artykułów", a w dziale "howto" i "programy" zrezygnować z podpisów i będzie po problemie. --Endel 23:32, 1 mar 2007 (CET)

"coniektore teksty w howto, bedace oryginalnie na lamach innych portali muszą być podpisane i nie mogą podlegać jakiejkolwiek modyfikacji."

Jeżeli nie mogą być poddawane modyfikacjom, gdyż określa to ich licencja, na górze strony stosuje się odpowiedni szablon (który kiedyś powstanie ;) ) - patrz #Licencja. Wtedy faktycznie podpis na dole jest uzasadniony, jednak nie grozi mu również zbytnie rozrośnięcie. --Minio 17:14, 2 mar 2007 (CET)

ok, więc tak: artykuły (jako wypowiedź osobistą) podpisujemy zawsze, howto i programy będące w public domain nie podpisujemy, teksty nie w public domain i/lub z innych źródeł podpisujemy. zgadza się? --.azhag 19:26, 2 mar 2007 (CET)

Ja byłbym za takim właśnie rozwiązaniem - "Howto" "Programy" "Screenshoty" (bo pewnie powstanie taki dział) public domain (albo lepiej GNU FDL) i nie ma wymogu podpisu (dowolność) - z zaznaczeniem, że teksty tam zamieszczone mogą być modyfikowane przez każdego. Natomiast "Artykuły" "Style" (bo pewnie powstanie taki dział) CC i zgodnie z CC wymóg podpisu i informacje o warunkach licencji.

W takiej sytuacji będzie problem z tekstem o "Sudo" - który proponuję (ponownie :) ) przerzucić do artykułów.

Jedna uwaga: To co napisałem to mój sposób rozumowania (niekoniecznie właściwy), poparty dość powierzchowną wiedzą na temat licencji. --Endel 21:18, 2 mar 2007 (CET)

Właściwie tak. Artykuły podpisujemy i zabrania się ich modyfikowania (poza drobnymi poprawkami ortograficzno-stylistycznymi). Autorzy poprawek nie dopisują swoich danych do artykułów.

Howto i programy może podpisać twórca artykułu, jeżeli ma takie życzenie. Nie jest to jednak wymóg i nie wolno się dopisywać po dokonaniu zmian (niezależnie od tego, jak dalece by one szły).

Tekst o sudo jest na CC-by, więc trzeba tylko dać ramkę o takiej a nie innej jego licencji.

W Informacjach prawnych trzeba dopisac to, co tutaj uzgodniliśmy i dać informacje, że dane autorów tekstów znajdują się w zakładce "histora" tekstu i z niej właśnie trzeba czerpac wiedze, gdy chce sie tekst rozprowadzać (podania danych wymaga licencja CC-by).

Ciesze się, że doszliśmy do kompromisu :) --Minio 15:34, 3 mar 2007 (CET)

Teraz ok?

BTW. "Nie jest to jednak wymóg", nie pisałem że jest to wymóg, było to jako opcja ("sugerujemy", "może")

--.azhag 18:36, 3 mar 2007 (CET)

pozowliłem sobie dodać zdanie "Osobom modyfikującym gotowe prace to prawo nie przysługuje." w drugim akapicie. Wydawało mi się konieczne je dodać, aby uzyskać pełną jasność.

'nie jest to jednak wymóg" powiedziałem w kontekście poruszanego problemu - to nie była bezpośrednia odpowiedź na Twoje słowa. --Minio 15:00, 4 mar 2007 (CET)

Konwencja w Howto

Howto nie może jedynie pomagać w rozwiązywaniu problemów - on musi również uczyć. Jakkolwiek dla niektórych może to być banalne, w tym dziale powinny znajdować się dokładne tłumaczenia, co gdzie i dlaczego się robi.

Dzięki temu czytelnik zostanie wyposażony nie w sposób, ale w wiedzę. Przy pomocy poradnika będzie potrafił uzyskać efekt, jakiego oczekuje nawet, gdy nie zostanie to opisane w tym pierwszym.

Przykładowa konstrukcja tekstu

Sugerujemy, aby w tekście ujęte były następujące zagadnienia:

• krótkie przedstawienie problemu
• wyjaśnienie co może powodować ów problem
• przedstawienie rozwiązania (kilku sposobów, jeśli istnieją) wraz z wyjaśnieniem co właśnie zrobiliśmy
• linki do tekstów omawiających podobne zagadnienie

Pamiętaj, że nie jest to ścisły dogmat, a jedynie propozycja - jeżeli Twój tekst będzie zbudowany w inny sposób nie znaczy bynajmniej, że zostanie przez nas odrzucony.

Konwencja w Programach

Dział ma na celu przedstawienie programów dobrze działających w duecie z Fluxboksem. Jako takie będą to zazwyczaj programy minimalistyczne, niezależne od bibliotek GNOME-a czy KDE, jednak nic nie stoi na przeszkodzie, by zaprezentować np. File Rollera, jeżeli ktoś ma ochotę.

Przykładowa konstrukcja tekstu

W prezentacji dobrze jest zawrzeć:

• przedstawienie, jaki jest główny cel programu (archiwizer, odtwarzacz plików multimedialnych, czytnik RSS, etc.)
• jak zbudowany jest interfejs lub interfejsy (ncurses, GTK 1/2, QT, www, wiersz poleceń, etc.)
• wypunktowanie ciekawych/przydatnych funkcji programu
• zależności programu
• przykładowe obrazy prezentujące program
• krótka instrukcja obsługi, jeśli program jest nietypowy w użyciu
• link do strony domowej oraz innych stron opisujących

Ciekawe może okazać się porównanie programu z bardziej znanymi alternatywami.

Oczywiście nie są to ścisłe nakazy, a jedynie propozycja. Konstrukcja Twojego tekstu zależy wyłącznie od Ciebie.

Konwencja w Artykułach

Dział ten przeznaczony jest na nieco luźniejsze teksty, obejmujące szerszą tematykę niż jeden konkretny problem.

Przykładowy tekst jaki może być zamieszczony w Artykułach to np. opis krok po kroku jak zainstalować i doprowadzić do stanu używalności Fluxboksa, dogłębne opisanie tego menedżera okien, etc.

Teksty opublikowane w Artykułach mogą zawierać opinie - nawet niepochlebne - autora. Należy jednak pamiętać, że są to opinie tylko i wyłącznie autora i musi on podjąć konsekwencje swoich słów. Między innymi z tego powodu zaleca się unikanie niekonstruktywnej krytyki.

Dział ten jest zdecydowanie luźniejszy niż pozostałe, teksty zamieszczone w nim nie muszą mieć zbliżonej konstrukcji. Jak będzie zbudowany tekst w tym dziale zależy wyłącznie od jego autora.

Konwencja na Stronie głównej

Na Stronie głównej znajduje się krótki opis Fluxboksa oraz krótkie wiadomości, przede wszystkim aktualności ze świata Fluxboksa i naszego portalu, a także ważniejsze wiadomości ze świata FLOSS.

Propozycję wiadomości możesz podesłać któremuś z adminów portalu (najlepiej azhagowi) przez e-mail, priva na forum, na stronie dyskusji Strony głównej lub w jakikolwiek inny sposób.

Strona ta została zablokowana przed edycję przez zwykłego użytkownika, jeżeli masz jakieś uwagi zamieść je na stronie Dyskusji.

Konstrukcja wiadomości

Wiadmości zbudowane są na szablonie zgodnie z klasyczną konstrukcją informacji:

• Lid - pierwszy akapit, będący wstępem do wiadomości, mający w skrócie przekazać o czym jest cała wiadomość (tak aby czytelnik po przeczytaniu tylko lidu był w stanie mniej-więcej wiedzieć co chcieliśmy przekazać w newsie)
• Body - treść wiadomości
• Puenta (opcjonalnie) - ostatni akapit zawierający uzupełnienie wiadomości (bez którego jednak informacja nadal byłaby pełna), jakiś krótki komentarz, "smaczek", etc.

Konstrukcja tekstu wiadomości powinna kolejno odpowiadać na pytania "kto? co? gdzie? kiedy? dlaczego? w jakim celu? z jakimi skutkami".

Proporcje wiadomości powinny z grubsza odpowiadać poniższemu schematowi:

______________________________
\                            /
 \           Lid            /
  \________________________/
   \                      /
    \                    /
     \       Body       /
      \                /
       \              /
        \____________/
          __________ 
          \        /
           \Puenta/
            \    /
             \  /
              \/