Aktiv Demokrati forum

Jag startar en ny tråd för GOV, för att så att säga börja ett nytt kapitel.

Jag har installerat GOV på nytt och uppdaterat installations-beskrivningen och börjat göra en del ändringar i programkoden. Jag har officiellt döpt om den från "active_democracy" till "gov", både i koden och i kod-arkivet. Så nu ligger den här: http://git.para.se/?p=gov.git -- där ni kan se koden och alla ändringar som gjorts, dag för dag.

(Som alltid. Jag uppskattar om ni finns på chatten, som moraliskt stöd och bollplank. Jag vill rekommendera att ni använder http://pidgin.im/ som tillåter ständig närvaro på chatten utan att det stör något annat ni har på datorn. Och i pidgin kan ni kombinera era chattkonton från MS Live/MSN, ICQ, Google talk, Facebook, etc.)

Och som första punkt rationaliserar jag bort code och name från vote-instanser eftersom datan redan ligger i weight.

Fredrik: om du inte har något annat, så tänkte jag börja med flervalsomröstningar nu.

För att numrera en del av variablerna här:

I en flervalsomröstning kan vi ha en eller flera vinnare. Exempelvis vid val av vilka som ska ingå i en arbetsgrupp eller ha en viss access. Då kan man rangordna personer och ange vilka man vill ha med och vilka man inte vill ha med. Om antalet deltagare i gruppen är odefinierat behövs ett annat kriterie för om personen kommer med eller inte. Exempelvis om det är fler som vill ha med personen än som inte vill ha med personen, och då räknar man inte de som sagt varken eller för personen.

Men om det är ett begränsat antal så kan man även rösta om antalet tillgängliga platser och då summeras rangordningen och de som hamnar under strecket kommer inte med. Men det kan fortfarande vara så att det inte finns tillräckligt många kandidater för att fylla alla platser.

Det kan också vara så att första platsen anses vara ordförande för gruppen och näst högsta platsen vice ordförande och övriga platser gruppmedlemmar.

Vid personval kan personer nomineras men de måste godkänna nomineringen för att vara valbara. Dessutom kan personer själva indikera ifall de vill ha positionen eller inte. Det kan ju hända att personen i fråga placerar sig själv långt ned i priolistan för att helst bara bli vald i sista hand. Man kanske bör ta extra hänsyn till det...

Även när det bara ska utses en enda vinnare borde listan fortfarande kunna bestå av tre kategorier av val. a) rangordnade alternativ som man vill ha, b) alternativ som man inte tagit ställning till, och b) rangordnade alternativ som man inte vill ha.

Alla dessa saker ska sedan kunna kombineras med en massa annat så som "resoltution method" vilket bör inkludera den kontinuerliga omröstningen där nya resultat införs allt eftersom de förändras.

GOV har klasser för Proposition, av vilka Yay_Nay är implementerad. Och klasser för Resolution Method, där vi har Progressive och EndTime.

Det finns en lång rad av metoder för flervalsomröstning och dessa kan tänkas dela en del egenskaper. Min uppfattning är att "Schulze method" är den bästa av dem, så jag tänker börja att skapa en Proposition-klass för den och se hur det utvecklar sig.

http://en.wikipedia.org/wiki/Schulze_method

Och här är perlmoduler som kan användas:

Algorithm::Voting
http://search.cpan.org/~jtrammell/Algorithm-Voting-0.01/

Voting::Condorcet::RankedPairs
http://search.cpan.org/~pjf/Voting-Condorcet-RankedPairs-1.01/

Statistics::RankOrder
http://search.cpan.org/~dagolden/Statistics-RankOrder-0.12/

Condorcet with Dual Dropping Perl Scripts
http://condorcet-dd.sourceforge.net/

jonas skrev:Statistics::RankOrder
http://search.cpan.org/~dagolden/Statistics-RankOrder-0.12/

Jag går vidare med denna eftersom den existerar och är nästan lika bra som Schulze...

Enligt wikipedia:

This is the main difference between the Schulze method and the ranked pairs method (both of which have tick the same boxes in the above table) can be seen in this example:

Suppose the MinMax score of a set X of candidates is the strength of the strongest pairwise win of a candidate A ∉ X against a candidate B ∈ X. Then the Schulze method, but not the ranked pairs method, guarantees that the winner is always a candidate of the set with minimum MinMax score. So, in some sense, the Schulze method minimizes the strongest pairwise win that has to be overturned when determining the winner.

Här är hur jag tänker mig datamodellen just nu.
(GOV bygger på RDF, där all data beskrivs med noder och pilar.)

Antag att Förslag1 har alternativen A, B och C.

Ranked --scof--> Proposition
Förslag1 --is--> Ranked
Förslag1 --has_candidate-->A
Förslag1 --has_candidate-->B
Förslag1 --has_candidate-->C
Jonas --places_vote--> Röst1
Röst1 --is--> Vote
Förslag1 --has_vote--> Röst1
Röst1 --places_candidate-->C (weight 2)
Röst1 --places_candidate-->B (weight 1)
Röst1 --places_candidate-->A (weight -1)

Tanken här är att, enligt mina funderingar tidigare i denna tråd, man ska kunna placera alternativen i 3 olika sektioner, motsvarande Ja, Nej och vet ej. Om man exempelvis placerat alla kandidater och det sedan tillkommer en ny kandidat så får den vikten 0 och då kan den automatiskt få bättre rank än de man placerat i nej-högen. Så i exemplet ovan så är två alternativ rankade bland ja och ett lagt i nej

Vid sammanställning ska sedan alla kandidater jämföras parvis.

Om resolution method progressive används (istället för endtime) så kan grafer etc baseras på procentuella förhållandet mellan första- och andra-alternativet.


För sortering skulle man kunna använda detta bibliotek från jquery, där man ska kunna dra kandidater från listan på kandidater till sin sorteringslista:
http://jqueryui.com/demos/sortable/#connect-lists

Härligt att det händer saker!

Flervalsomröstning är huvudprioritet för GOV i sig ja.

Däremot skulle jag säga att vi för AD skulle behöva få in speglingen av medlemmar så att det ger rösträtt i just röstområdet AD. Det går givetvis att hantera manuellt, men en spegling underlättar ju mycket.

Kom vi inte fram till vilken algoritm som var lämpligast att använda för flervalsomröstningar i en annan tråd? Varför inte bara implementera den?

joasi skrev:Kom vi inte fram till vilken algoritm som var lämpligast att använda för flervalsomröstningar i en annan tråd? Varför inte bara implementera den?

Vi kan ha många olika algoritmer som man kan välja på. Just nu vill jag ta det som finns tillgängligt. Och som jag beskrev i den eller annan tråd, så är valsystem faktiskt en etablerad forsknignsgren där det finns utarbetade test och kriterier för bedömning av valsystem.

När vi började diskussionen så var jag inte medveten om detta. Wikipedia refererar till en del av detta. Se exempelvis jämförelsen här:
http://en.wikipedia.org/wiki/Schulze_method#Comparison_with_other_preferential_single-winner_election_methods

Ok, huvudsaken är ju givetvis att det blir implementerat, så hittar du något enklare och bättre färdigt beskrivet på internet så är det ju bara bra.

Man kan undra i vilka sammanhang man vill rösta fram mer än ett alternativ i samma omröstning. Kanske om man vill göra en grovgallring för att senare rösta fram endast ett alternativ.

I de flesta andra fall brukar dock inte summan av hur bra varje alternativ är för sig vara lika med eller stå i proportion till hur bra helheten blir. (Man borde ju i annat fall kunna dela upp en omröstning i flera separata omröstningar.)

Om man t.ex. väljer in personer i en styrelse, då borde vissa personer fungera bättre ihop än andra. Personer som kompletterar varandra eller kommer bra överens t.ex.

Bättre i de allra flesta fall vore nog att låta röstberättigade och rådgivare (valberedningar mm.) föreslå olika kombinationer av personer eller förslag som skall väljas ut och sedan tillämpa någon flervalsomröstning på dem.

I övrigt så bör nog Aktiv Demokrati ha något mer/annat att erbjuda än vad som redan tillämpas någon annan stans på Internet. Om Aktiv Demokrati skall kunna värva många röster och medlemmar, då måste man ha något andra inte har. Ingen gör säkert precis exakt som ni på Aktiv Demokrati gör. Man kan dock inte bara, så att saga, sätta samman några standardkomponenter på något eget vis och sedan tro att man gjort något förträffligt unikt.

För bra nyskapande krävs god förståelse av olika metoder, så att man kan välja ut, anpassa och skapa nya metoderna som fungerar bra ihop. Om man inte vet så noga kan man testa många metoder. Man bör dock tänka på att det inte bara är varje metod för sig man testar, utan också hur de fungerar ihop.

Valde att kalla det för alternative istället för candidate. Så nu har vi
vote_alternative, has_alternative och places_alternative

Next up blir gränssnitt för att skapa en ny ranked proposition.

Fredrik: Ser att du lagt in en hel del jquery redan för olika saker. Du har mer erfarenhet av det så berätta gärna vad du har på gång där. En del av det är utkommenterat och det ser ut som om inget av det används i gränssnittet just nu.

Jag har gränssnitt för att lägga till alternativ i flervalsomröstning. Nu ska jag lägga till kod för att presentera alternativen så man kan sortera dem.

Det finns flera tänkbara gränssnitt att använda här. Just nu lutar jag åt att Ha tre fält i två kolumner. En för osorterade, en för ja och en för nej. Går förståss att ändra senare.

(Om någon här vill stödja utvecklingen. Det bästa ni kan göra är att gå in på chatten. När det är tomt där tolkar jag det som att ingen bryr sig...)

jonas skrev:(Om någon här vill stödja utvecklingen. Det bästa ni kan göra är att gå in på chatten. När det är tomt där tolkar jag det som att ingen bryr sig...)

Jag bryr mig - som jag själv ser det - men anser själv att jag inget har att IT-tekniskt tillföra. Jag är helt enkelt rudis på sådant. Så det får vara tillsvidare för mig - med att chatta om det också.

Däremot så ser jag mycket fram emot attt få vara med på ett hörn och "provköra" - när det är så dags för det.

Grr... Satt flera timmar med att försöka få jquery att funka.
Till slut såg jag att TT åt upp mina $. ... Vilket är vad jag sagt åt den att göra.

Undrar om vi kanske skulle ta och stänga av interpolation globalt eller kanske bara för GOV.

Alternativet är inte så svårt egentligen. Dollartecken behöver bevaras med \. Så det är bara att ersätta $ med \$ för att bevara dem från TT.

Nu ska här sorteras.

Alrighty. Nu när dollartecknen är på plats så...

Här är en dummy-lista som visar hur jag tänkt mig själva sorteringen.
http://hem.jonas.liljegren.org/~jonas/gov/html/doc/sortable2.tt

Ni får gärna titta och komma med uppmuntrande kommentarer. ... Men ingen kritik tack. Jag vill komma vidare och vill inte sinkas. ... Men uppskattar om ni tittar på det.

Next up: Spara sorteringen i databasen.

Snyggt!
Gött att det rör på sig!

jonas skrev:Ni får gärna titta och komma med uppmuntrande kommentarer. ...

"Lämna alternativ du inte har någon åsikt om i det BLÅA fältet"

Kan det förstås som VET EJ-bedömning/röstning

Josef Boberg skrev:"Lämna alternativ du inte har någon åsikt om i det BLÅA fältet"

Kan det förstås som VET EJ-bedömning/röstning

Det motsvarar "ingen röst" eller "blankröst" eller "vet ej".

Det är tänkbart att man kan utöka med mer detaljer om man vill. Men det är också viktigt att systemet är någorlunda enkelt.

Så som jag tänkt göra i första omgången här så betyder det egentligen bara att allt man lämnar där samt alla framtida nya alternativ sorteras in mellan det gröna och det röda i prio-röstningen. Det är därmed en lösning på vad som händer när nya alternativ dyker upp under en pågående omröstning.

Det är tänkbart att man kan utöka med mer detaljer om man vill. Men det är också viktigt att systemet är någorlunda enkelt.

Så som jag tänkt göra i första omgången här så betyder det egentligen bara att allt man lämnar där samt alla framtida nya alternativ sorteras in mellan det gröna och det röda i prio-röstningen. Det är därmed en lösning på vad som händer när nya alternativ dyker upp under en pågående omröstning.

En vettig utgångspunkt!