Opinia o opiniowaniu ;)

Pią, 19 Sty 2001, 22:56:11 CET

Dnia Fri, Jan 19, 2001 at 10:41:16AM +0100, Michal Moskal napisał(a):
> Hello,
> 
> Spróbuje ułożyć jakoś do czego doszliśmy:
> 
> 1. userów doajamy przez cgi (+ https [?])
> 2. statystyki również tak wyświetlamy [?]

powtórze jeszcze raz: user powinien mieć możliwość sprawdzenie jak się
miały "środowiska" osób opinujących opinie do jego środowiska. Więc
powinna być również statystyka uwzględniająca zainstalowane przez niego
pakiety. IMHO jeśli tego nie będzie, to userom nie będzie się chciało
opiniować pakietów, skoro i tak nie mogą skożystać z opini innych w sposób
"optymalny". No ale takie zbiorcze statystyki via cgi/php tez sa ok, ale
jako uzupełnienie a nie zastąpienie tych "interaktywnych".

> 3. pakiety oceniamy tylko w kategoriach, user może proponować now
>    kategorie, a jakiś moderator (kto to [?]) zatwierdza

ktokolwiek. myśle że znajdzie się jakiś ochotnik (w ostateczności mogę to
być ja, ale mam kiepski dostęp do sieci więc moge nie być "real time"). 

> 4. ocena jest w skali działa(1)/nie działa(0)/nie używam==nie wiem(n/a)
>    ja proponuje dorzucić jeszcze : prawie działa(0.5) z opisem, 
>    dla niezdecydowanych [?]

może lepiej: działa doskonale, dziala średnio, dziala kiepsko, nie dziala ?

> 5. opinie muszą być podpisane. gnupg czy md5 [?]

tylko id goscia. raczej nikt nie bedzie nam falszowal opini (jak by co to
się  w przyszłości dorobi podpisywanie)

> 6. potrzebujemy kolejkowania opini
> 7. do pakietu dołączamy wersje innych pakietów od których zależy.
>    ja sugeruje jeszcze wersje kernela bo ma wpływ na wszystko +
>    cpu info etc.

cpu info jest IMHO raczej nie przydatne.wersja kernela jak najbardzij OK.
Natopmiast pomocna może być architektura z której pochodzi pakiet.

> Teraz czego nie uzgodniliśmy:
> 1. protokół:
> 	a) xml
> 	b) name: value
> 	c) binarny
>    ja, ze swojej strony podejmuję się napisać jakieś przeźroczyste
>    funkcje dla protokołu binarnego, tak żeby działały na różnych 
>    architekturach, ale nie będe przy tym obstawał.

Nie wiem czy jest sens robnienia binarnie. Może lepiej prosty format 
tekstowy (napewno będzie to łatwiej parsować po stronie serwera (jeśli
będzie w php/cgi a chyba własnie tak będzie)).

> Teraz mój idea co do sposobu (dość dokładenego) działania serwera:
> Klient się łączy. 
> 
> 1. Prosi o liste zmian w opisie kategorii lub o pełną listę. 
> 2. wysyła podpisaną opinie.
> 
> 1 i 2 można zamienić lub opuścić cokolwiek.

ok.

> Server robi analizy danych, co jakiś czas, np. co 5 minut. Dostęp
> do wyników jest przez CGI.

A może analiza danych powinna być "na żądanie" ?

> Server zbiera opinie o każdej wersji pakietu osobno. Pamięta je
> wszystkie.

O ile dobże zrozumiałem to trzyma wszystkie ankiety. Jeśli tak to ok.

> Próbuje zgadywać co jest przyczyną błędu. Tzn. pakiet
> ten i ten wydaje się nie mieć wpływu, a ten po upgrejdzie
> robi kwas. To łatwo statystycznie znaleźć (tzn. serwer sam to
> zgadnie, a nie userzy mu powiedzą).

Jesteś pewny że to łatwo zrobić ? IMVHO dobre zrobienie tego (automatyczne)
to kupa roboty (wcale nie prostej).

> Jeśli problemy są z nową
> wersją (dużo większe niż ze starą) to trzeba wołać na alarm.

No tak. To jest proste.

> Takie typy serwera co do prawdopodobnych przyczyn awarii
> należy umieszczać w statystykach. To by chyba pozwoliło userom
> się zorientować czy u nich będzie działać. 

Może lepiej tak jak ja proponuje: user dostaje statystyke wyglądającą
mniej więcej tak (sumryczna ocena to powiedzmy średnia z oceny działania
poszczególnych właściwości):

Statystyka pakietu mutt:
Opini ogółem: 38

Sumaryczna ocena:  0       |  0.33     | 0.66       |    1    |
Ilość ankiet    :  2 (5%)  |    2(5%)  |  10 (26%)  | 26(63%) |

Zależność od innych pakietów

pakiet  | twoja   |  z wersją   |  ta sama   | z nowsza
        | wersja  |  mniejsza   |  wersja    | wersja
--------+---------+-------------+------------+----------
glibc   | 2.2-7   |    0.3 (20) |    0.4 (8) |   0.8 (10)
ncurses | 5.2-1   |    0.9 (6)  |    --- (0) |   0.9 (32)
openssl | 0.9-6   |    0.9 (10) |    0.2 (28)|   --- (0)
...

w tabelce jest : srednia ocena a w nawiasie ilośc ludzi którzy mieli takie
środowisko.
To samo będzie również dostępne dla każdej cechy (zamiast dla oceny
sumarycznej pakietu).
Jak wam się podoba ?

> Jest propozycją (dobrek czy pawelk?) żeby mówić userowi że
> na takiej configuracji jak jemu 20 osobom działa a 3 nie.
> Nie do końca wiem na ile mają to być zbliżone wersje pakietów?
> Takie same? Przy szybkości rozwoju PLD i ilości użytkowników 
> to chyba nie ma większego sensu (2 mówi że ok, 1 że nie i bądź
> tu mądry ;).

Można dać userwowi wybór jak mają być porównywane wersja pakietów : czy
liczy się sama wersja pakietu czy również rewizja.

> Pozatym jest z tym problem żeby dodać sporo
> funkcjonalności w kliencie (tego nie można zrobić przez http).

Przez http mozna. Nie można przez html (mam nadzieje, że widzisz różnice).

> Wydaje mi się że typy serwera o złych pakietach będa dla
> nas (developerów) lepsze, a dla userów też ujdą.

nie jestem przekonany że automatyka będzie działałą w tym przypadku
dobrze. IMHO prościej to będzie wykryć człowiekowi przez popatrzenie na
statystyki.

> Aha, jest jeszcze jedna ważna kategoria oceny pakietu:
> współpraca z innymi pakietami. Możliwe, że np. dla bibliotek
> będzie to jedyna checha. Ona będzie wypełniana *tylko*
> pośrednio, przez opinie o pakietach zależnych.

możliwe. Ale IMHO oceny libów nie są tak potrzebne dla zwykłego usera 
(wyłączywszy programistów) jak oceny aplikacji

-- 
Paweł Kołodziej 
pawelk w pld.org.pl 
,,O ile nam wiadomo, komputer nigdy nie popełnił niewykrytego błędu.''
                                                 -- Weisert