Aktiv Demokrati forum

jonas skrev:Perl har ett väl utvecklas system för att bygga auto-tester som kan köras innan en ny version tags i bruk...

Min erfarenhet är att testdriven utveckling mot programbibliotek är en ytterst viktig kvalitetsfaktor, men den görs bäst av utvecklarna och behöver kompletteras mot en slutanvändartest mot en användarfunktionalitet med hela miljön som testas i sin helhet. Min tanke var att hjälpa till med denna form av tester. Det behöver inte vara så omfattande att genomföra med lite erfarenhet, och kan göras av glada frivilliga icke-programmerare.

gilroitto skrev:... en slutanvändartest mot en användarfunktionalitet med hela miljön som testas i sin helhet. Min tanke var att hjälpa till med denna form av tester. Det behöver inte vara så omfattande att genomföra med lite erfarenhet, och kan göras av glada frivilliga icke-programmerare.

Ok kör på.

Har skickat lite bugginfo via mail.

jonas skrev:Vad har du för idéer om hur vi ska tillåta ändring och radering av prio-alternativ? ... Jag tillåter att man lägger till alternativ men inte ändra eller ta bort.

Den som har lagt upp en omröstning eller ett alternativ skulle kunna få ångra sig en tid efter upplagt alternativ, eller att man markerar den som ogiltig eller tillbakadragen. Det kan ju vara så att andra har giltiga invändningar mot omröstningar eller alternativ som gör att det finns skäl att dra tillbaks dem av uppläggaren eller en moderator.

Okej. Nu har jag lagt upp en ny version med några buggfixar.

* Kopplar props till rätt resolution-klass, så vi kan ha andra sorter än progressive

* Hanterar ett antal nya eventualiteter vid auto-inloggning via WP (CAS)

* Gömmer grafen om den är tom. (Tack Gil)

Detaljer: http://git.para.se/?p=gov.git

Rösta på vad du vill se i GOV:
http://ad.alternativ.se/proposition/display.tt?id=1480


***

Kom gärna med tips på hur vi ska hantera vem som får lov att rösta i vilket område, så att koden inte blir AD-specifik. Dvs kopplingen så att partimedlemmar får rösträtt i området "Aktiv Demokrati".

Jag har försökt hålla koden så det ska funka även för andra sammanhang. CAS och WP-sync går att stänga av i konfigurationen om man vill.

Jag är glad att GOV inte är skriven i php då det språket verkligen frammanar det sämsta hos många programmerar där man blandar databasanrop, datalogik och presentationsformattering i samma rader kod.

jonas skrev:Jag vill använda prio-omröstningar utan slut-datum för kontinuerligt val av alla förtroendeuppdrag, så som webbadmin, forumadmin, kassör, ordförande, osv.

Kan diskuteras, då ett förtroendeuppdrag gärna blir bättre med lita kampanjande och sedan lite tid att få bli varm i kläderna.

Men däremot så jar jag för första gången blivit riktigt övertygad om att kontinuerliga omröstningar kan ha sin plats! Priolistan över GOV utvecklingen är ju klockren! Inget slutdatum, en levande process för att vaska fram nästa task. Kan tillämpas på många polititskt styrda verk för att prioritera projekt utöver den dagliga verksamheten. Men jag är övertygad om att tanken känns skrämmande för många och är inget vi ska fronta med i vårt kampanjande utan är något vi helt enkelt tillämpar i delar då det är praktiskt tillämpbart.

Men det kräver också en hantering av borttagning av förslag ur listan då ett förslag är slutfört eller inte längre aktuellt. Ett slags modereringen med tillsyn och transparens och motivering till borttagning.

gilroitto skrev:

jonas skrev:Jag vill använda prio-omröstningar utan slut-datum för kontinuerligt val av alla förtroendeuppdrag, så som webbadmin, forumadmin, kassör, ordförande, osv.

Kan diskuteras, då ett förtroendeuppdrag gärna blir bättre med lita kampanjande och sedan lite tid att få bli varm i kläderna.

Jag har svarat här:
http://aktivdemokrati.se/forum/viewtopic.php?f=84&t=1197&p=12203#p12203

Det här med att kopiera in en massa vad andra har gjort utan att förstå hur det fungerar är inte riktigt min grej. Eller förstår du precis hur drag and droppfunktioner fungerar och kan bygga om dem så att t.ex. alternativ placeras på en valfri plats längs en linje och syftningslinjer sedan gör att alternativ med text kan vara godtyckligt nära varandra utan att texten i dem skrivs på varan?

Skulle kanske kunna skriva Java Script på mitt eget lågnivåvis utan att behöva använda serverprogrammering i början

Jag har ägnat massa tid åt att skriva något långt inlägg till den där internationella direktdemokratiska Google-gruppen och replikera svar jag fått. Kanske var onödigt. Fick träna lite på att skriva på engelska.

Erik Bengtsson skrev:Jag har ägnat massa tid åt att skriva något långt inlägg till den där internationella direktdemokratiska Google-gruppen och replikera svar jag fått. Kanske var onödigt. Fick träna lite på att skriva på engelska.

jag tror att fler är intresserade i MG. De är mer tekniskt inriktade. Gå med i deras lista. De har också flera projekt. En del i java.

Det du skriver Jonas är väll i praktiken att jag är utestängd överallt. Det lär nog inte vara enklare att samarbeta med utländska direktdemokratiska partier eller vad står MG för egentligen. Om andra programmerar i java använder de väll något ramverk där typ JSF (Java Server Faces) eller Hibernate mm. Jag är väll korkad som försöker med något över huvud taget ingen förstår ändå riktigt vad jag menar. Och framförallt kan andra inte förklara hur de tänker och varför de gör vad de gör.

Jag skulle t.ex. gärna vilja veta varför gilroitto tycker det är så fel med programspråk där det går att kombinera databasanrop med datalogik och presentationsformattering i samma rader. Detta är väll i så fall också möjligt på JSP-sidor, i Servlets och på ASP-sidor (tror jag). Som jag ser det bör programspråk vara flexibla utgående från ett fåtal kommandon man väl känner till. Skall man t.ex. tvingas skilja på layout och programlogik då faller genast en massa idéer bort som bygger på annan dynamik än de som utvecklat programspråket har tänkt. Att använda css-filer borde väll gå i både PHP och JSP om man vill förkorta formateringskoden.

Ett problem med högnivåprogrammering är också att den kan bli väldigt datakraftskrävande utan att man själv förstår varför. Den kod man skriver kanske ser enkel och snabb ut men såg man helheten skulle man upptäcka att t.ex. samma sak görs fram och tillbaka en massa gånger eller massa onödiga saker lagras och bearbetas. Jonas inkluderar t.ex. långa programbibliotek som skickas till klientdatorer i GOV fast än förmodligen mycket i dem aldrig används.

Nu har jag väll skrivit en massa som stänger mig ute helt. Att färdiga rutiner används för t.ex. scripts kanske är för att det skall se professionellt ut utan att man behöver lägga ner så mycket tid själv. För mig känns det dock rent kränkande att lägga in funktioner som man inte själv råder över. Speciellt sådana som skall se grafiskt avancerade ut men som jag själv tycker är irriterande och opraktiska.

Alla tror liksom att allting borde vara så lätt för mig som kan en hel del, kan argumentera för min sak och kan lära mig nya saker själv utan att behöva fråga om så mycket hjälp. Det verkar dock absolut inte vara någon i hela välden som kan samarbeta om att göra något av mina idéer. Helt själv utan hjälp blir det dock inget av dem.

Det här forumet är väll gjort i PHP men är det är väll styrt av en ”web template system” användandes en ”template processor” tillhandahållet av Wordpress. Annars hade jag en hel del ideér om hur man skulle kunna göra ett bättre forum också.

Du har absolut inte utestängt dig själv från något. Som utvecklare har jag dock kommit till en allt större förståelse att det är minst 10 ggr svårare och tidskrävande att ta fram en produkt som man ska leva med än en trevlig proof of concept. Krav på flexibilitet, förändring, ny grafisk profil, snabba tillägg av funktioner, avancerad rättighetshantering, adminstrationsfunktioner, integrering med an dra produkter, skalbarhet över en farm av datorer osv. Allt det kommer, och då ställs andra krav på arkitektur på koden.

Men så länge man jobbar med proof of concept eller mindre produkter går det utmärkt att göra lite hur som helst bara det är prydligt och strukturerat.

När man utvecklar system underlättar det om man gör det inom en befintlig arkitektur, t ex en CMS som WordPress eller Drupal, då man utom viss funktionalitet får en modulariserad arkitektur på köpet där många besvärlig beroenden undviks. För övrigt så är Drupal utvecklat i PHP och är enligt vad jag läst föredömligt strukturerat för att kunna underhållas och kommuniceras mellan utvecklarna.

Donald Knuth har sagt "premature optimization is the root of all evil". Vill man uppnå en viss mängd funktionalitet och vill bli klar inom en viss tid måste man prioritera, och då kanske optimeringar gör sig bäst på 1-2 ställen och resten av koden kan vara fokuserad på att vara strukturerad för enkel underhåll och utbyggnad. Man ska inte underskatta vad antalet rader kod gör för enkelheten att underhålla och vidareutveckla den. Men färdiga bibliotek blir min kod minst 10 ggr mindre.

Erik Bengtsson skrev:... vad står MG för ...

The Metagovernment project

Du kan gå med i e-postlistan här:
http://metagovernment.org/mailman/listinfo/start_metagovernment.org

Behöver en modell för röstområden, för vilka som ska vara medlemmar där.
Något i stil med:

"Aktiv Demokrati" --is--> proposition_area
"Aktiv Demokrati" --has_membership_criterion--> ad_membership_criterion
ad_membership_criterion --is--> membership_criterion_by_json_attribute
membership_criterion_by_json_attribute --scof--> membership_criterion
ad_membership_criterion --using_json_attribute_exist--> "ad_member"

Och sedan låta ha ett anrop till WP som listar alla som har attributet ad_member, som är en boolean.

Som alternativ till detta skulle vi ha det som idag är default:

membership_criterion_by_admission --scof--> membership_criterion


Eller vad tror ni?

Nu synkar GOV rösträtten i "Aktiv Demokrati" med partimedlemskapet i AD.
Synkning sker en gång i timmen.

Modellen är ganska flexibel där vi kan styra medlemskapet på data från WP och kan även ha andra typer av algoritmer för andra areas. Kan även låta flera "proposition areas" ha samma medlemskriterier.

Näst på tur är att ändra gränssnittet så att områdesadministratören inte kan lägga till medlemmar om det sköts på annat vis.

Så vi kommer till att börja med ha tre sorters röstområden
1. Administratör hanterar medlemskap manuellt (Sveriges riksdag)
2. Alla är medlemmar (GOV)
3. Medlemskap hämtas från WP baserat på metadata (Aktiv Demokrati)

Nu så motsvarar gränssnittet kriterierna för att få rösta i området, så att man exempelvis inte kan ansöka om medlemskap i området "Aktiv Demokrati".
Därmed tror jag jag är tillräckligt klar med detta för att gå vidare.

Jag har även lagt in en "turnout" för att visa hur många som deltagit i omröstningen, inklusive blankröster och inklusive delegerade röster. För AD blir detta baserat på totalt antal medlemmar i partiet.

Näst på tur, enligt http://ad.alternativ.se/proposition/display.tt?id=1480 blir att implementera omröstning med fast tidslängd.

Ska personen som lägger upp omröstningen kunna sätta längd i antalet dagar?
Vi kommer att lägga in en längd per röstområde.

Jag skulle vilja ställa frågan igen vad ni tycker saknas innan vi kan använda GOV för omröstningar inom AD.

Närmast på listan har vi
* Fast längd på omröstningstiden, till exempelvis 7 dagar
* Användargränssnitt

Andra punkten är iofs ganska odefinierad, men jag tänkte iaf försöka göra det lite snyggare och enklare.

Vad mer behövs?

Prioröstningen i nuvarande utformning går att använda även med föreslagen tillhörande binär omröstning, om man bara ser till att lägga in ett "NEJ" eller "status quoe" när man skapar omröstningen. Men jag lägger upp det som en punkt i priolistan.

Lägger också upp en punkt om att inte tillåta nya alternativ vid prioomröstning.

Vi behöver möjligheten att löpande anpassa systemet efter reglementet. Snart har vi förmodligen en knippe nya omröstningsregler i stadgarna som behöver implementeras. Kan systemet göras så flexibelt så att en administratör kan gå in och ändra funktionen, så att man inte behöver programmeringsinsatser vid varje förändring?

joasi skrev:Vi behöver möjligheten att löpande anpassa systemet efter reglementet. Snart har vi förmodligen en knippe nya omröstningsregler i stadgarna som behöver implementeras. Kan systemet göras så flexibelt så att en administratör kan gå in och ändra funktionen, så att man inte behöver programmeringsinsatser vid varje förändring?

Går ju inte att veta vad som kan komma i framtiden.
I så fall får vi hålla oss till papper och penna eller kalkylark eller forumet.

Det går även att ha förhållningsregler utöver funktionerna i röstningssystemet. Exempelvis om man skulle ha en regel om att alla omröstningar ska föregås av ett visst procentuellt stöd så kan man manuellt lägga upp förberedande omröstning. Så det gäller det mesta man kan tänka sig hitta på.

GOV har visserligen en massa flexibilitet, men det är orimligt att kräva att det ska kunna hantera alla tänkbara framtida scenarior.

Det är ju alltid en avvägning mellan flexibilitet och enkelhet/stabilitet.
frågan är var GOV ligger på skalan?
Finns det i dagsläget någon form av konfigurerbarhet vad gäller omröstningsfunktionaliteten?

joasi skrev:Det är ju alltid en avvägning mellan flexibilitet och enkelhet/stabilitet.
frågan är var GOV ligger på skalan?
Finns det i dagsläget någon form av konfigurerbarhet vad gäller omröstningsfunktionaliteten?

* Presentationen ligger i TT-mallar som gör det ganska enkelt att ändra på gränssnittet.

* Datan ligger i en RDF-databas med ett webbgränssnitt som gör att administratörer kan ändra på "allt" oavsett om det finns speciellt framtagna gränssnitt för det eller inte.

* Kod ligger separerat i klasser knutna till noder i datamodellen, vilket gör det enkelt att lägga till nya funktioner

* I nuläget har vi gränssnitt för att för nya omröstningar välja a) område, b) typ (ja/nej eller prio) och snart även c) metod för avslutning (slut-tid eller integral).

* Varje röstområde har för tillfället sin egen demokratikonstant och kan även ha andra variabler för exempelvis längd på omröstning.

Faktum är att GOV har kunnat användas för omröstning i flera månader. Men nu tycker jag att den nått en punkt där den är bättre än nuvarande systemem (i forum).


Exempel på autogenererad graf från en del av databasen relaterat till en omröstning:
http://e2d.se/files/gov-example.svg

Viktigast är nog att få fram en bra grundstruktur för att uppmärksamma förslag som sedan kan gå vidare till en mer slutgiltig omröstning av valfri typ. Förberedande omröstning borde inte behöva ha så höga tekniska krav på sig. Förslag som konkurrerar/utesluter varandra bör dock inte kunna komma till mer slutgiltig omröstning samtidigt som separata förslag.

För övrigt så har jag skrivit en lång harang om bland annat maktfullkomlighet, programmeringskultur och exempel från problematiskt beslutsfattande i praktiken. (Chattande kan dock också bli långt totalt sett.) Jag har aldrig skrivit vanliga pappersbrev men tycker ändå att det är bättre att skriva långa genomtänkta meddelanden än korta konverseringar där det blir svårt att frångå samtalsgruppens tankekonventioner.


Är det något jag fruktar och avskyr så är det personer som slår fast att man skall göra på något visst vis, inte för att man i en väl avvägd analys av för och nackdelar kommit fram till att detta är det bästa sättet, utan för att personen kollat runt hur det är normalt att göra och okritiskt lyssnat på vad stora auktoriteter säger.

Anledningen till att personer i olika ledande positioner gör på detta vis är antagligen att de inte orkar väga samman alla viljor med faktiska förutsättningar som bivillkor och sedan fatta ett så bra beslut som möjligt. Enklare då att bara rätta in sig i ledet, göra som andra brukar göra och göra som ledare högre upp förespråkar.

Resultatet av detta blir dock en likriktning som gör att totalt sett färre nya idéer testas och att de idéer som testas utvärderas dåligt. Detta borde också öka på maktfullkomligheten uppåt i samhällshierarkier.

När det gäller programmering av hemsidor då måste det som skickas ut till klientdatorer kunna tolkas på ett bra sätt av de flesta webbläsare. HTML och java-script mm. är för mig redan högnivåspråk. Om man sedan använder ytterligare något programskal i en dataserver för att generera denna kod då vill man gärna kunna förstå vilken kod som slutligen skickas ut till klientdatorer. Man kan tänka att programmering i skal skulle kunna göra det enklare att anpassa sig till nya webbläsarversioner genom att byta skalet. Programmering inom skal/ramar borde dock bara krångla till det om man försöker göra sådant som de som konstruerat skalen/ramarna inte har tänkt på att någon vill göra. Webbläsare brukar för övrigt minst klara av det tidigare versioner klarar av. T.ex. fungerar Frames och tabeller, vad jag vet bra även på nya webbläsare även om de flesta har gått ifrån den programmeringstekniken.

I stället verkar det här med att okritiskt följa med i trender vara prio ett i webbprogrammeringsbranschen. Det som var rätt förut har helt plötsligt blivit helt fel nu så att säga. Just förändringar som går ut på att saker skall se professionella ut men i övrigt bara krånglar till det och kräver datorkraft, detta är jag mycket skeptisk till. Detta gäller t.ex. grafik med gradvis förändring enligt vissa mönster där förändring i stora steg skulle gå lika bra. Olika mouseover funktioner där menyer, previewers mm. flippar upp, krånglar ofta till programmeringen och är vad jag tycker mest irriterande. Egentligen är det nog enklast om t.ex. alla länkar är blå understruken text. Programmerare verkar dock vilja flasha till det genom text som förändras när pekaren kommer över. Abstrahering och användande av färdiga rutiner för databashantering mm. kanske gör det enklare i vissa fall. De idéer som jag skulle vilja genomföra ryms dock inte alltid inom abstraktionsmodellen. Finns det t.ex. databaser där alternativ rankas efter hur de utvärderas indirekt i flera led då utvärderare utvärderar andra utvärderare genom att indirekt utvärdera deras utvärdering.

I stället för att så att säga göra ”proof of concept” med enkel grafik gör man det genom färdig inklippta programbibliotek. Något som jag ser det tvingar in kreativa programmerare på konventionella banor.


Personligen så har jag väll väldigt mycket åsikter om saker men väldigt lite formell makt. Det ända jag har formell rätt att bestämma över är väll mina egna finansiella tillgångar på ca 1 milj. kr. Bor hemma hos mina föräldrar fast än jag är 34 år och har en civilingenjörsexamen. Senast hade jag en massa invändningar på samfällighetsmötet i området jag bor (54 hushåll i 27 parhus) . Man kanske skulle kunna dra lite slutsatser utgående från hur det gick till där beträffande system för att underlätta beslutsprocesser.

Vi har gemensamma garage som ägs av samfälligheten. Ca halva samfällighetsavgiften (på 3500kr/år) går åt till att bekosta elräkningen för att värma upp dessa garage. Ett långdraget tvistemål har varit om man inte kunde ha kallgarage i stället. Kompromisser kan vara att sänka termostaten i alla garage eller ha vissa garage som är varmgarage och vissa som kallgarage och låta samfällighetsmedlemmar betala därefter. Att välja mellan kall och varmgarage har inte visat sig praktiskt möjligt. Sänka termostattemperaturen gör att det inte torkar upp så bra (bilar rostar) när det är halvvarmt och slaskigt ute. Själv tycker jag att man borde ställa termostaten ganska högt men värma med mycket låg effekt 1-2kw per garage i stället för 5kw.

Senast kom en ny sådan här fråga som det kan bli tvistemål om, garageportarna var gamla och fungerade dåligt. Samfällighetens styrelse hade då pratat med andra samfälligheter och fått uppfattningen att man måste köpa nya porter och att föreningen skall ta lån till detta. Jag och en del andra tyckte dock att man kunde försöka renovera de gamla portarna. Och om man skulle köpa nya portar då borde man försöka få så många som möjligt att betala (ca 13k kr) direkt och låta föreningskassan betala för de andra mot en avbetalningsplan. Vad ordföranden gjorde vad dock att försöka få en proposition om att köpa nya garageportar snabbt igenomröstad utan att man viste riktigt vad man röstade på.

Ett som jag ser det mycket bättre sätt att fatta sådana beslut på vore att medlemmar utvärderar olika målsättningar med beslut t.ex. att garage skall värmas upp minst 10 grader över utomhustemperatur eller till max 15 grader, att det ska vara frostfritt i garage, att det garageportar skall se bra ut utanpå, att garageportar skall gå lätt att öppna mm. Med datateknik borde man kunna välja en person som administrerar en sådan utvärdering/omröstning. Denna person skulle sedan kunna sätta upp villkor för vilka målsättningar som är förenliga med vilka tekniska lösningar.