Helt OK att det är bökigt, ingen anledning att kräva t.ex. samma inlogg eller så.
Också helt OK om mkt annat saknas, men det hade varit kul om vi kunde börja med kontinuerliga omröstnigar. Hur mkt jobb är det?
Då kunde vi börja labba vilken demokratikonstant vi skall ha men ändå till att börja med köra på en fast tid som idag 1 månad.
Då kan vi se vilken konstant som verkar fungera bäst.

Vad behövs för att vi ska kunna testanvända systemet med riktiga omröstningar? Om vi fortsätter med öppna omröstningar som i forumet kan vi nog komma undan ganska enkelt.

1. Kunna få ut en lista på användare okk vad de har röstat från servern.
2. Kunna sätta slutdatum.
3. Användarkonton för partimedlemmar.

Med 1 kan vi kontrollräkna allt för hand så att vi inte behöver oroa oss för felaktiga resultat. Det viktigaste är att vi kan testa hur systemet fungerar i praktiken så att vi kan förbättra det, inte att vi ska ha ett perfekt system från början. Om vi kan sätta slutdatum skulle det vara bra, men även om vi inte kan det går det att hålla reda på slutdatumen utanför systemet. Användarkonton är nog ok om det är lite bökigt till att börja med. I framtiden skulle det vara bra om det namnet okk lösenordet man fick när man gick med i partiet/forumet fungerade även på wiki och omröstningssystem, men, somsagt, "i framtiden".
Så just nu tror jag bara nr 1 hindrar oss från att testa systemet med riktiga omröstningar, vad har jag missat?

bussfantasten skrev:Hej!

Var inne igen och kollade runt lite på valsystemet! Blir bara bättre o bättre Ketti! Men i framtiden, kommer det att bli "knappar" istället för länkar då? Som mycket annat är det ju en vanesak, men de flesta är nog mer inne på en knapp än en länk. Tror iaf jag.

Patrik

Jag svarar i tråden "Förslag / Problem" så att det händer lite där också

Hej!

Var inne igen och kollade runt lite på valsystemet! Blir bara bättre o bättre Ketti! Men i framtiden, kommer det att bli "knappar" istället för länkar då? Som mycket annat är det ju en vanesak, men de flesta är nog mer inne på en knapp än en länk. Tror iaf jag.

Patrik

Du menar som implementerar din kontinuerliga metod? Den nuvarande versionen är ju faktiskt också kontinuerlig då det inte går att sätt slutdatum än

Vad tror du om att skapa en version som jobbar kontinuerligt?

Dags att jag skriver något här igen.
De mesta av ändringarna jag gjort på sistone har inte varit direkt synliga för användaren så jag har därför inte tyckt det var intressant att skriva något här. Men nu är det somsagt dags

Osynliga ändringar:
* All html är nu genererad istället för handskriven.
* Diverse andra saker är också autogenererade för att minska risken för misstag.
* Använder nu "gettext" för översättning av klienten till olika språk. (*)
* Börjar så smått göra saker mer konfigurerbara.

Synliga ändringar:
* Det står nu (nästan) alltid en användbar URL i webbläsaren.
* Man fortsätter nu att vara inloggad tills man stänger webläsaren eller loggar ut manullt. (i stället för att loggas ut lite då och då av mystiska anledningar)
* Man kan nu titta på omröstningarna utan att vara inloggad.
* Inloggningssidan är inte längre förstasida.
* Det går att ändra språk på klienten från varje sida (inte bara från loginsidan). (*)
* Det är förhoppningsvis tydligare att rösta nu.

Det är nu enkelt att bidra med översättning (till svenska eller andra språk). Det är bara att fylla i en fil där de engelska fraserna står med motsvarande för det aktuella språket. Ett perfekt tillfälle för ickeprogrammerare att bidra!
Men det kan vara lite tidigt att lägga ner arbete på översättning då mycke kommer att ändras och måste då översättas på nytt.

+poäng demexp !

>> "Mer än en klient är nog tom nödvändigt att ha struktur för, på samma sätt som mer än en modul för t.ex. rösträkning och röstlängd.
Detta för att dels kunna byta ut dåligt fungerande utan att för mkt påverka andra funktioner, dels för att sporra programmerare att komma med nya och bättre moduler.
Jfr utvecklandet av Linux."

Jag håller helt med. Och jag kan bekräfta att demexp är utvecklat med det i tanke. För tillfället finns det faktiskt tre(!) klienter: gtk-klienten, våran demo-klient, och drupal-klienten i utveckling.

Det finns väl i AD:s fall fyra sorters omröstningar.

Prioritetsomröstningar ämnade för att rangordna olika alternativ där det första är det som skall genomföras (om möjligt).

Ja/nej till ett lagt förslag. (specialfall av prioritetsomröstning)

Sammanställningar, ämnade för fördelningar i t.ex. en budget.

Personval, där man antingen kanha en vanlig omröstning eller en condorcet omröstning.http://en.wikipedia.org/wiki/Condorcet_method
Ett alternativ till rena personval kan vara SD2-metoden, se mer här, wikin funkar inte just nu:http://top.xwiki.com/xwiki/bin/view/Main/Network
-där man rangordnar kandidater enligt pagerank metoden men möjlighet till omedelbar recall.

Mer än en klient är nog tom nödvändigt att ha struktur för, på samma sätt som mer än en modul för t.ex. rösträkning och röstlängd.
Detta för att dels kunna byta ut dåligt fungerande utan att för mkt påverka andra funktioner, dels för att sporra programmerare att komma med nya och bättre moduler.
Jfr utvecklandet av Linux.

Användarkontona skulle vara samma på båda systemen. Och egentligen så är det ju fortfarande bara ett system då båda använder samma server. Dessutom finns det inget som hindrar andra från att göra egna klienter som ansluter till servern då allt är öppen källkod och nätverksprotokollet är väl definierat.

Blir väldigt tufft att hålla reda på 2 klienter. Svårt med uppdateringar.

Allt integrerat skulle vara så fruktansvärt bra om de olika funktionerna bara är tillräckligt bra. 1 system att hålla reda på, bara 1 användare osv.

Fantastiskt ketti. Du är en hjälte.

Källkoden för http://equah.afraid.org/demexp/demexpweb.cgi är nu tillgänglig online genom mercurial [1]. Addressen är: http://equah.afraid.org/demexp/hgweb.cgi

Att kompilera demexp för första gången kan vara en riktig utmaning, så fråga gärna om saker ni undrar över.

För er som vill hjälpa till med utvecklingen av demexp föreslår jag att ni börjar med att titta på ocaml (http://caml.inria.fr/ocaml/index.en.html) om ni inte redan har gjort det. Flera tutorials och andra document är listade här: http://caml.inria.fr/resources/doc/index.en.html .
Det absolut viktigaste dokumentet är den officiella manualen: http://caml.inria.fr/pub/docs/manual-ocaml/index.html

[1]: Ett Source Control Management system motsvarande cvs, subversion, etc. Men med en decentaliserad modell. Läs mer på deras hemsida: http://www.selenic.com/mercurial/wiki/index.cgi

OK!

En kommentar om integrerade system.
Vi har diskuterat saken förut och kommit fram till at det inte nödvändigtvis är det optimala att ha alla systemkritiska funktioner i ett o samma system.
Dels kan ngt krångla och sänka allt, dels kan man vilja uppdatera delarna var för sig.
Men om utvecklingen ändå skulle gå mot integrerat kan vi ju om vi tycker isåfall välja att t.e.x bara använda oss av valsystemsdelen i Drupal-systemet.

Bra ide också att ha en tung och en lätt klient, dels redundans, dels olika nivåer för olika användare (bara allt gällande demokratin är synligt i båda varianterna förstås).

Ny uppdatering:
* Jag har snyggat till koden så att jag inte skäms att visa den för andra lika mycket längre
* Koden är nu mer rubust vilket teoretiskt borde betyda färre oväntade felmedelanden.
* Resultatet på omröstningar uppdateras nu utan att man måste ändra till en annan omröstning och sedan ändra tillbaka.

Planer för framtiden:
Ett webbinterface till demexp baserat på drupal (http://drupal.org/) är under utveckling. En fördel med det är att vi då kan ha [ Websida / Forum / Demexp-client / fler saker? ] allt i samma system.
Jag kommer fortsätta utveckla den nuvarande klienten för närvarande, men jag uppmuntrar människor att även undersöka drupal redan nu.
Kanske kan det vara en idee med två olika klienter? En drupal-baserad med många "features" och en lite mindre som inte är så krävande för server/webläsare?

Mmm, jag har också för mej att det finns ett allmänt problem med prioritetsröstningar som ska leda till procentsatser. Men jag kan ha fel, det är inget jag har tänkt igenom ordentligt.

Magnus: "OJdå Joakim..
Den beskrivningen av valsystemet var inte att leka med..
Något för matematiker snarare än programmerare?"

Ja det dokumentet ska nog mer ses som ett mellansteg som jag använde när jag skulle implementera modellen, för att jag skulle veta vad jag höll på med. Om någon visar intresse för den så skulle jag kunna försöka pedagogisera den lite. Poängen med modellen är hur som helst att den ska vara så generell så att man kan använda samma modell men justera parametrarna beroende på hur vi besultar att omröstningarna ska fungera.

Appropå "genomsnitts-röstningar" så har vi väl redan kommit fram till att lösningen är att använda medianen istället? Eller har den metoden någon svaghet?

Magnus: "Detta duger inte som ersättning till AD:s prioritetsomröstningar.
> I dessa skall slutresultatet leda till en viss fördelning, t.ex. olika procentsatser för olika poster i en budget."

Jag tror inte det är möjligt att ta fram några procentsatser från en prioritetsomröstning, helt enkelt eftersom informationen inte finns i resultatet. Hur värderar man t ex någons alternativ tre jämfört med dennes alternativ två? Har den hälften så hög prioritet? 2/3? 10%? Eller varierar det från fråga till fråga och från person till person?

När man vill få fram procentsatser får man nog använda sammanställningar istället, där man sätter ett värde på varje alternativ. Ev. kan man ju kalibrera värdena i efterhand så att summan blir 100%.