Przejdź do zawartości

Dyskusja wikipedysty:Kubahaha

Treść strony nie jest dostępna w innych językach.
Z Wikipedii, wolnej encyklopedii

Ad:PKP Intercity

[edytuj kod]
Ad:PKP Intercity

Witaj, czy mógłbyś uzupełnić źródło informacji o połączeniach obsługiwanych przez SKPL? Therud (dyskusja) 07:32, 4 paź 2018 (CEST)[odpowiedz]

Ostatnio popularne

[edytuj kod]

Jeżeli jakiś android sobie coś ustawił na stronie głównej, to do niego trzeba pisać. Sławek Borewicz, → odbiór 17:50, 4 cze 2019 (CEST)[odpowiedz]

Ten serwis takich rzeczy nie mówi. Nie ma takich informacji na stronach pl.wikipedia.org Sławek Borewicz, → odbiór 18:25, 4 cze 2019 (CEST)[odpowiedz]

Cześć. Czy mógłbyś w wolnej chwili zaktualizować trasy na mapkach dla linii 152 i 157 i ewentualnie utworzyć mapkę dla linii 150, która ma zastąpić dziesiątkę od października? Dzięki i pozdrawiam. Cynko (dyskusja) 18:02, 2 wrz 2019 (CEST)[odpowiedz]

Cześć. Mapki zostały zaktualizowane, więc sprawa już jest nieaktualna. Pozdrawiam. Cynko (dyskusja) 19:57, 15 wrz 2019 (CEST)[odpowiedz]

Czy moglibyśmy poprosić o wypełnienie krótkiej ankiety dla akademickiego badania, który pozwoli nam rozwinąć Wikipedie?

[edytuj kod]

Dzień dobry Kubahaha -

Czy moglibyśmy poprosić o wypełnienie krótkiej ankiety dla akademickiego badania, który pozwoli nam rozwinąć Wikipedie?

Organizacja non-profit CivilServant wraz z Uniwersytetem Princeton prowadzi projekt dotyczący ulepszenia polskiej Wikipedii. Zostałeś zaproszony do udziału w projekcie ze względu na swoje doświadczenie oraz Twój wkład w Wikipedię.

Czy zgodzisz się nam pomóc? Wystarczy wypełnić krótką ankietę, która zawiera pytania na temat Twoich doświadczeń związanych z Wikipedią.

Mamy nadzieję, że nam pomożesz, ponieważ tak jak my chcesz, żeby polska Wikipedia dalej się rozwijała. Po zakończeniu badań prześlemy do Ciebie informacje na temat tego czego się nauczyliśmy dzięki projektowi oraz Twojemu udziałowi w nim.

Kliknij tutaj, żeby dowiedzieć się więcej i wypełnić ankietę

Dziękujemy, mamy nadzieję, że nam pomożesz

W przypadku pytań prosimy o kontakt w języku angielskim z User:Juliakamin(cs). Możesz również spytać nas, User:Natalia Szafran-Kozakowska (WMPL) lub User:Wojciech Pędzich (WMPL), a pomożemy z tłumaczeniem pytań.

CivilServantBot (dyskusja) 22:44, 23 wrz 2019 (CEST)[odpowiedz]

Wiadomość dotycząca wyników badania związanego z Wikipedią

[edytuj kod]

Dzień dobry,

organizacja non profit CivilServant współpracowała z badaczami z Uniwersytetu Cornell przy badaniu, którego celem było uzyskanie informacji o możliwości podniesienia poczucia satysfakcji autorów polskiej Wikipedii. W ramach badania, które odbyło się pomiędzy sierpniem 2019 a lutym 2020, doświadczeni autorzy polskiej Wikipedii wysłali podziękowania innym edytorom za ich wkład.

Kontaktujemy się z Tobą, aby poinformować Cię, że mogłeś(-aś) być jednym z autorów, którzy otrzymali podziękowania w ramach projektu, oraz aby przedstawić wyniki badania, które znaleźć tutaj. Pamiętaj, że ewentualne podziękowania zostało wysłane przez doświadczonego edytora Wikipedii według jego własnego uznania.

Wstępne wyniki badania dostępne są online: https://citizensandtech.org/ochotnicy-podziekowali-tysiacom-ludziom-za-ich-wklad-w-wikipedie-oto-czego-sie-dowiedzielismy/.

W ramach badania zebraliśmy publicznie dostępne informacje z Wikipedii. Jeśli chcesz abyśmy usunęli Twoje dane z badania, prosimy o kontakt z Meta:user:Juliakamin(cs).

Głównym badaczem w tym projekcie jest J. Nathan Matias, profesor Uniwersytetu Cornell. W przypadku pytań, które masz już teraz, albo będziesz mieć później, prosimy o kontakt z Nathanem Matiasem, wysyłając wiadomość na adres e-mail [email protected] lub z menagerem projektu Julią Kamin wysyłając wiadomość na adres e-mail [email protected]. Nathan jest założycielem organizacji CivilServant, odpowiedzialnym za oprogramowanie wykorzystywane w tym badaniu. Jeśli masz jakieś pytania w tym zakresie, prosimy o kontakt z Nathanem. Jeśli masz wątpliwości dotyczące Twoich praw w związku z udziałem w badaniu, prosimy o kontakt z Uniwersytetem Cornel, dzwoniąc pod numer +1 607-255-5138 lub poprzez stronę http://www.irb.cornell.edu. Cornell to amerykański uniwersytet, który poprosiliśmy o nadzór nad naszym badaniem, aby upewnić się, że jest ono przeprowadzone zgodnie z odpowiednimi standardami etycznymi. Swoje skargi lub zastrzeżenia możesz również zgłaszać anonimowo do Ethicspoint poprzez stronę http://www.hotline.cornell.edu, lub dzwoniąc pod numer 1-866-293-3077. Ethicspoint jest niezależną instytucją działającą jako pośrednik pomiędzy Uniwersytetem a osobą zgłaszającą skargę, zapewniając w ten sposób anonimowość.

Możliwe jest także, że jesteś jedną z osób, która wypełniała ankietę będącą częścią badania. Jeśli tak było, Twoje prawa dotyczące Twoich danych zostały wówczas przedstawione, ale w przypadku jakichkolwiek pytań prosimy o kontakt z Julią ([email protected]). Wyniki badania były niejednoznaczne, dlatego też nie zostaną one opublikowane.

Dziękujemy

CivilServantBot (dyskusja) 03:21, 12 cze 2020 (CEST)[odpowiedz]

Fajnie, że ktoś poza mną się w końcu zainteresował tym artykułem :)

Mam jednak pewne uwagi co do podpunktów usuniętych przez ciebie.

  • ulepszona funkcjonalność i efektywność w porównaniu do tradycyjnych formatów graficznych (m.in. JPEG, GIF oraz PNG),
    przez ulepszoną funkcjonalność miałem na myśli improved functionality, czyli że nie trzeba już wybierać, jakiego formatu chce się użyć na podstawie fikuśnych diagramów, tylko po prostu: wektor? SVG. Raster? JPEG XL, on ma wszystkie wymagane funkcje. Z kolei efektywność kompresji to w oryginale efficiency, czyli wydajność w sensie stopnia kompresji. Gdybym użył słowa "wydajność", to niektórzy mogliby założyć, że chodzi o wydajność w sensie prędkości, a to nie zawsze jest prawdą (JPEG XL jest dość szybki na domyślnych ustawieniach w przeciwieństwie do AVIF, ale możesz spowolnić JPEG XL, jeśli bardzo tego chcesz).
  • wsparcie zarówno dla fotografii, jak i sztucznych obrazów,
    Teoretycznie każdy stratny rastrowy format grafiki "wspiera" sztuczne obrazy (lineart, tekst, screenshoty itp.), ale gorzej z efektywnością kompresji i jakością wizualną takich danych... Do fotografii JPEG XL używa VarDCT (DCT jak w JPEG'u, ale na sterydach), a do "sztucznych" treści lepiej się sprawdzi stratny tryb modularny, bo artefaktów VarDCT nie da się obejść. Faktycznie z tym "wsparciem" można by było sformułować to lepiej, ale od razu wywalać fajną funkcję formatu?
  • łagodny spadek jakości obrazu dla coraz niższych ustawień kodowania,
    W porównaniu do JPEG'a to niebo a ziemia, bo JPEG XL jakoś trzyma poziom mimo zmniejszania jakości, a JPEG czasami już na najwyższych nie wyrabia, ale jak uważasz, że to nie jest ważny podpunkt, to nie będę aż tak bardzo tego bronił.
  • wsparcie dla szerokiego zakresu kolorów oraz HDR,
    Trochę źle się wyraziłem. JPEG obsługuje szeroki gamut dzięki profilom ICC, ale... 8 bitów? Serio? Z czymś takim daleko nie zajedziemy pod względem jakości. 12-bitowa wersja JPEG'a jest nieobsługiwana w praktyce i kompletnie niekompatybilna z 8-bitową. Przede wszystkim JPEG XL obsługuje większą ilość bitów, dzięki czemu jest w stanie zapisać kolory dokładniej, bez ditheringu i bandingu na niższych ustawieniach jakości. HDR też jest dość ważną funkcją, większość współczesnych kodeków wideo to obsługuje, pora zatem na jakiś format graficzny.
  • bezpłatny format z otwartoźródłową implementacją referencyjną[1].
    Tego akurat nie oddam. Będę o to walczył, bo ten punkt jest ważniejszy niż myślisz. Taki np. JPEG 2000 – było wiele czynników, przez które nie zastąpił JPEG'a (był m.in. powolny), ale brak otwartej implementacji na samym początku, czyli w najważniejszym momencie, sprawił, że JPEG 2000 wylądował w niszy zamiast w mainstreamie. JPEG XL ma od samego początku otwartą implementację, dzięki czemu praktycznie od razu po zamrożeniu bitstream'u można było zaimplementować go w przeglądarkach internetowych, programach graficznych i gdziekolwiek indziej. Było to możliwe bez żadnych kosztów, bo JPEG XL jest royalty free, czego nie można powiedzieć o HEIF oraz BPG (oba na bazie HEVC'a) będących kompletnym pierdolnikiem patentowym. Gdyby Cisco nie uwolniło swojej implementacji H.264, nadal nie mielibyśmy AVC w Firefoxie i nadal trzeba by tam było używać VP8.
    A, i przy okazji skasowania tego punktu wywaliłeś źródło, z którego zostały wzięte wszystkie te punkty. Na drugi raz uważaj bardziej na to, co usuwasz...

Na drugi raz bardziej polecam coś dodać/zmienić zamiast kasowania, bo trochę się postarałem, żeby się to jakoś kupy trzymało ;) ZiemekZ (dyskusja) 08:56, 17 maj 2021 (CEST)[odpowiedz]

Dzięki za szybką odpowiedź. Na podstawie twoich uwag naniosłem trochę zmian w moim brudnopisie, co zresztą zobaczysz w jego historii edycji. Jeszcze nie wprowadzam ich do głównego artykułu, bo przy okazji poprawię jeszcze parę rzeczy na podstawie artykułu z enwiki. ZiemekZ (dyskusja) 22:03, 17 maj 2021 (CEST)[odpowiedz]
Nowa wersja artykułu została przejrzana! Jeszcze raz wielkie dzięki za uwagi, jakich udzieliłeś i mam nadzieję, że rozwiniemy temat, bo to trochę męczące samemu to ogarniać w polskojęzycznym internecie (poza ogólnikowym i dość przestarzałym artykułem sprzed 3 lat oraz świeżym wpisem na Wykopie, notabene linkującym do anglojęzycznych stron nie znalazłem w Google nic innego po polsku). Miłego edytowania! ZiemekZ (dyskusja) 22:21, 18 maj 2021 (CEST)[odpowiedz]