system opiniowania pakietów

[Paweł Kołodziej]

Dnia Sun, Jan 14, 2001 at 10:14:42PM +0100, Lukas Dobrek napisał(a):
[ciach technikalia]

> Moim zdaniem powinnismy teraz sie skoncentrowac na mysleniu o tym co my tak 
> naprawde chcemy od strony serwera bo strona klienta to technikalia. Natomias
> to jaka funkcjionalnos chcemy miec od strony serwera jest trudniejsze. 
> I tu zgadazm sie z Pawlem ze powinno sie dac takim serwerem sprawdzic czy w 
> nowych X komus dziala akceleracja. I tu zaczyna sie prawdziey problem
> jak do kazdego pakietu dolozyc liste funkcjonalnosci ktore on dostarcza 
> bo z drugiej strony nie mozna tego zrobic tylko na zasadzie wpisaywania 
> przez userow bo niecholery to nie zadziala z powodu burdelu. Tak wiec trzeba by 
> myslec o tym zeby to rozwinac w taki sposob zeby gdzies pewnie w specach taka
> liste tworzyc. Natomiast klienta ma tylko mowic co z tej listy mu dziala a co nie.

OK. faktycznie  jak ustalimy co potrzebujemy zrobić to będziemy się
zastanawiali jak, a narazie takie dyskusje są przedwczesne.

No to start:

1. Funkcjonalność dla końcowego użytkownika
Tak naprawdę to marzeniem urzytkownika nie jest opiniowanie pakietów,
tylko korzystanie z opini innych. No ale jak chce korzystać to musi
opiniować. No ale może zacznijmy od korzystania z opini

1a. Korzystanie z opini innych użytkowników.
Użytkownik pewnie chciałby wiedzieć (w kolejności od najmniej dla niego
pozytecznych, ale najprostczych w realizacji):
    (a) - ile osób zainstalowało dany pakiet w tej wersji. Ilu on działa,
	  ilu nie działa.
    (b) - ile osób z powyższych miało inne pakiety podobne do posiadanych
	  przez niego (wersje, i czy np był sendmail zamiast qmaila),
	  ilu troche inne , a ilu całkiem inne. W jakich pakietach były te
	  róznice. Które pakiety z środowikska były kluczowe. Np 95% ludzi
	  którzy mieli pakiet A w wersji V1 działało, ale jak była to
	  wersja V2 to działało tylko 2% ludzi (albo może lepiej: cztery
	  kataegorie odnośnie każdego pakietu ze środowiska: nie mieli
	  tego pakietu, mieli starszy nież Ty, mieli taki jak Ty, mieli
	  nowszy niż Ty.)
    (c) - powyższe ale każdy pakiet rozbity na funkcjonalności (w pewnym
          sensnie można traktować jak podpakiety) (np virtualhost w
	  apache).
	   + poza cechami samego programu, można też oceniać wartość
	     dodaną, czyli np czy skrypty pre/post są tak zrobione, że
	     zapewniają płynny upgrade powiedzmy bazy danych z poprzedniej
	     wersji.
      (d) - możliwość pogladania kto jak ocenił pakiet (np. jak kloczek, a
	    jak Zagrodzki itp).
1b. Wystawianie opini pakietu
	- użytkownik musi mieć możliwość zarejestrowania się do systemu
	  (jednorazowo). Podaje swoje imie, nazwisko, ksywke, e-mail i
	  określa swój stopień zaawansowania jako użytkownik linux'a (może
	  to służyć do oceny wiarygodności jego opini). Otrzymuje wtedy
	  coś co pozwoli go w przyszłości indentyfikować (numerek,
	  haselko, czy cokolwiek innego -- chwilowo nieistotne).
	- musi być lista pakietów o których użytkownik jeszcze nie
	  wsytawił opini (trzymana lokalnie, ale też do dociągnięcia z
	  serwera po radosnym rm -rf /).
	- wystawanie opini:
	   + ocena generalna działania pakietu (np od 0 do 10)
	   + ocena poszczególnych właściwości pakietu. Tu powinna być
	     lista dostępnych właściwości, a użytkownik ma wybrać: działą,
	     nie dziala (wtedy ewentualnie jakiś wyjaśniający komentaż),
	     albo niesparawdzałem (bardzo ważne pole). Każda kategoria
	     oprócz swojej nazwy (np w przypadku mutta "wsparcie dla
	     IMAP'a" mogła by mieć krótkie wyjaśnienie o co dokłądnie
	     chodzi, żeby użytkownik nie czuł się zagubiony).
	     Być może dobrą żeczą była by drzewiasta struktura
	     właściwości.
	     Poza tym jeśli użytkownik uzna że lista kategorii nie
	     obejmuje wszystkich istotnych funkcjonalności użytkownik
	     powienin mieć możliwość dodania swoich kategorii. Jeśli był
	     by to "niezaufany" użytkownik to przed wrzuceniem jej do
	     ogólnego zbioru kategorii musiała by być ona zakceptowana
	     przez moderatora.
	   + miejsce na "slowo od użytkownika". Wtedy był by jeż prawie
	     pełny bugtracing system.

2. Co by się przydało "przy okazji"
	- możliwośc preglądania zbiorczych statystyk, czy wręcz
	  alarmowanie pewnych osób gdy poziom opini o danym pakiecie
	  spadnie poniżej pewnego progu.
	- możliwość przeglądania kolejnych napływających do systemu
	  raportów.
	- licznik na www.pld.org.pl : "78% PLD działa poprawnie!"



> Ja wiem ze to jest plan maximum. Ale nie widze innego rozwiazania. 

W sumie najgorzej będzie chyba z interfejsem użytkownika do przeglądania
raportów.

-- 
Paweł Kołodziej 
pawelk w pld.org.pl 
Nie cierpię interfejsu użytkownika