Referat fra workshop om politisk prosess 15. februar

Referat fra workshop om politisk prosess 15. februar.

Oppsummering

Vi kom i gang rundt 10:30 med workshoppen og fulgte programmet noelunde slavisk etter det.  Vi hadde gruppevis presentasjoner etter hver økt med en liten pause.  Gruppediskusjonene var ofte engasjerende og det ble av og til nødvendig å avbryte de for å fortsette programmet. Vi valgte å dele workshoppen i to grupper, der den ene såg på implementering Kjellsens vedtekt om politisk prosess og den andre såg på implementering av Jakobsens Distribuert Demokrati. Diskusjonene som oppstod bar oftest preg av å se hvordan disse skulle integreres og hvilke rolle de skulle ha for Piratpartiet (PIR), altså hva er Kjellsens vedtekt sitt domene og hva er Distribuert Demokrati sitt domene. Slik vi ser det er Distribuert Demokrati et effektiv virkemiddel på nasjonalpolitiske saker, men kan komme til kort i lokalpolitkk, her er Kjellsens vedtekt mer egnet. Kjellsens vedtekt er i hovedsak tiltenkt piratpartiets anliggende, kjerneprogram og vedtekter, lokalpolitikk m.m., mens Distriburert Demokrati skal forme breddepolitikken vår. Det vil i praksis si at Piratpartiet ikke skal forme sin egen breddepolitikk, men at vi skal ha en prosess som henter inn forslag fra ulike meiningsbærere basert på tilslutning. Vår oppgave bli så å vurdere om denne breddepolitikken kan forsvares av vårt kjerneprogram eller om den bryter den. Kjellsens vedtekt  skal i større grad ta for seg lokalpolitikk i og med at det kan være vanskeligere å finne meiningsbærere på dette planet av politikk, Kjellsens vedtekt sørger også for at partiet involveres på et lavterskelnivå og at man kan holde seg oppdatert på partiets status. Dette må sees på som en pågående diskusjon og det som står beskrevet her må sees på som et innspill, fremfor fasit. Reint konkret arbeida vi med brukerhistorier etter Jakobsens metode og disse legges ved som vedlegg, både rånotater og de rafinerterte brukerhistoriene.

Siste del av workshoppen gikk til å diskutere utvikling og vi la løst fram et budsjett på 30.000 NOK som forslag til midler som skal brukes til å ansette en profesjonell utvikler til å implementere Kjellsens vedtekt. Vi håper å ha systemet oppe å gå før 1. juni, men gikk ikke inn i videre detalj. Vi ønsker å finne en lokal utvikler i Trondheims­regionen som kan få betalt for oppdraget. Til slutt vil jeg si at slike workshopper er nyttige og effektive, men krever styring og håndhevelse av tidsplan for å fungere bra. Vi håper det kan bli et eksempel til etterfølgelse. Neste møte for politiske prosesser kommer til å finne sted i Trondheim innen 2 uker etter workshoppen.

Vedlegg 1: Brukerhistorier for Kjellsens vedtekt

Roller:

• System
• Admin
• PIRMedlem
• Publikum
• Meiningsbærer

Brukerhistorier.

1. System skal sende ut en invitasjonsepost til PIRMedlem når et nytt medlem av

piratpartiet blir registrert.

1. Som Admin skal jeg kunne redigere rettighetene til medlemmer.
3. Som PIRMedlem skal jeg kunne lage nye politiske forslag til validering
4. Som PIRMedlem skal jeg kunne trekke mine polititiske forslag.
5. Som PIRMedlem skal jeg kunne få tilbakemelding på innsendte politiske forslag
6. Som PIRMedlem skal jeg kunne bli invitert til å validere en sak per epost uten å logge inn

noe sted.

1. Som PIRMedlem skal jeg kunne invitere andre PIRMedlemmer til å bli medforslagstiller til

mitt forslag

1. Som PIRMedlem skal jeg kunne adoptere validerte forslag, dersom forslagsstiller trekker

seg.

1. Som PIRMedlem skal jeg kunne abbonere på et forslag.
2. Som Publikum skal jeg kunne se alle validerte forslag og enkelte innlegg fra

diskusjonsfasen/SaksForbedring mellom første og andrevalidering

1. Som Publikum skal jeg kunne se status på forslag.
2. Som Meiningsbærer skal jeg kunne backe et forslag
3. Som Meiningsbærer skal jeg kunne komme med innstilling til et validert forslag.

Vedlegg 2: Brukerhistorier for Jakobsens Distribuert Demokrati

Roller

• ­ PP Sysadmin
• ­ PP politisk representant
• ­ 3.parts vurderer
• ­ Velger
• ­­ PP medlem
• ­­ PP velger
• ­­ Norsk borger
• ­­ Utenlandsk
• ­ Meningsbærer

Brukerhistorier

Som PP Sysadmin skal jeg kunne tilordne rettigheter til brukere

Som PP politisk representant skal jeg kunne opprette et politisk saksområde

Som meningsbærer skal jeg kunne søke opp en eksisterende politisk sak

Som meningsbærer skal jeg kunne lage en ny politisk sak

Som PP politisk representant skal jeg kunne sammenslå duplikater av politiske saker

Som meningsbærer skal jeg kunne lage et synspunkt på en politisk sak

Som meningsbærer skal jeg kunne lage mitt eget politisk saksområde

Som meningsbærer skal jeg kunne tilordne et synspunkt til et politisk saksområde

Som meningsbærer skal jeg kunne stemme på andre meningsbærere (inkorporere deres synspunkter i sitt program)

Som velger skal jeg kunne få oversikt over synspunktene til de forskjellige meningsbærerne

Som velger skal jeg kunne sammenligne meningsbærere

Som velger skal jeg kunne finne ut hvilke meningsbærere som samsvarer best med egne synspunkter

Som velger skal jeg kunne velge en meningsbærer til å representere meg innen et politisk saksområde

Som velger skal jeg kunne markere og kommentere synspunkter til en meningsbærer som jeg er uenig i

Som velger skal jeg kunne prioritere et politisk saksområde

Som velger skal jeg kunne dele mine valg med andre

Som velger skal jeg kunne kopiere og benytte en annen velgers oppsett ­ helt eller delvis

Som velger skal jeg kunne endre mine stemmer

som velger skal jeg kunne få varsel hvis et kopiert oppsett endrer seg/autosynke

Som velger/meingsbærer skal jeg kunne få varsel hvis mine meningsbærere endrer på sine synspunkter

Som PP politisk representant skal jeg kunne få se resultatet

Som PP politisk representant skal jeg kunne publisere det endelige resultatet

Som besøker skal jeg kunne se det endelige resultatet

Som PP politisk representant må jeg ha en prosess for å avsjekke om hvorvidt en organisasjon er forenelig med PP kodeks

Som PP politisk representant må jeg ha en prosess for å avsjekke om hvorvidt en organisasjon har fått ekstra tilslutning pga rike onkler (ref ­ holde penger ut av politikken)

Som PP politisk representant må jeg ha en prosess for å avsjekke om hvorvidt et politisk synspunkt kommer i konflikt med et punkt i kjerneprogrammet

Som PP politisk representant må jeg ha en prosess for å sammenstille synspunktene fra de forskjellige meningsbærerne etter deres tilslutning og prioritet av saksområde

Som 3. parts vurderer skal jeg kunne se det uredigerte stemmeresultatet for å kunne vurdere om hvorvidt PP politisk representant har tilpasset programmet kun ift PP kodeks, kjerneprogram og penger

Vedlegg 3: Rånotater for Kjellsens vedtekt

Punkt som bør være med i en kravspesifikasjon

Hovedområder:

• Brukergrensesnitt (PiRMedlem)
• Administratorgrensesnitt
• Offentlig grensesnitt
• Meningsbærergrensesnitt
• Databasesystem
• Saksbehandlingsmodul
• Valideringssystem
• Grunnleggende HW­krav
• Beslutningssystem
• Behandle saken som en pakke gjennom systemet?
• Tag for saker
  • når sak sendes til V1 får en se saker med samme tag
  • en del av validering, avvisningsgrunn “for lik annen sak”?
• er en sak hugget i stein når den har passert V1?
  • forslagsstiller kan modifisere
  • tydelig change­log siden V1 når saken kommer til V2
  • unngå at noen “gamer” ved å få endre en sak for å få den gjennom V1 med formål

å endre den tilbake etterpå

• • ønsker en mulighet for at en sak skal kunne “dø” mellom V1 og V2
  • prioriteringsliste over saker som skal arbeides videre med, upvote

Brukergrensesnitt

• Saksinngang
  • forslagsstiller
    • inloggingskrav
    • webinterface
    • mulighet til å trekke før V1
    • mailfeedback
• førstevalidering
  • LAV engasjementsterskel
  • random mailutsender
  • webinterface
  • voteringssystem
  • inloggingskrav eller engangslink
    • streng sikring av en stemme per medlem
    • engangskode sms/e­post

• SaksForbedring
• andrevalidering
• beslutningsledd

Kravspec, Jakobsenstyle

Forslagsstiller skal kunne:

• Saksinngang
  • sende inn ett forslag med gitt spesifikasjon igjennom ett webinterface
    • forslags heading
    • forslags body
    • vedlegg
  • klassifikasjon (lokal/nasjonal/kjerne/bredde/vedtekt, beslutningsmetode etc)
  • Ikke sende ubegrenset antall forslag. Time limit?
    • begrenset antall per uke
    • kan be om fritak av admin
    • karantene ved spamming
• spammer man mye vil man få redusert mulighet til å sende inn

forslag i uka, dersom man lar være å spamme vil man kunne få tillitt tilbake.

• • Setningsbeskrivelse av forslag
  • Legge til medforslagsstiller
• førstevalidering
  • sjekke fremgang
  • skal være anonym
  • killbutton
• SaksForbedring
  • Diskutere
  • endre forslaget
  • legge til utfyllende info
  • Komme med highlighted innspill
  • Kan trekke engasjement, hvis ingen medlemmer tar over ansvar for saken går

den ut av systemet

• • Legge til medforslagsstiller
• andrevalidering
  • sjekke status på prosessen
  • få tilbakemelding om resultat
  • ikke anonym
• beslutningsledd
  • Stemme
  • sjekke status

Valideringsmedlem skal kunne:

• Saksinngang
• førstevalidering
  • lavterskelengasjement!
  • få forespørsel om å validere
  • kunne legge inn kommentar til saken
  • flagge saken ut fra foreslått nivå
  • Ha et utvalg av forhåndsdefinerte tilbakemeldinger.
  • Vurdere saker i tråd med Piratkodeks og kjerneprogram.
  • Se tags/merkelapper av hva saken angår.
  • Ha en kort oppsummering av saken
  • Link til guide for validering
  • Forslag til valideringsgang: Man får en link til en autogenerert side der man kan

lese saken og stemme. Kan kun brukes en gang. Når validerer har stemt går linken til saken i SF. Vi må vurdere om validerer skal få mailbeskjed om at saken har gått igjennom validering og ligger i SF

• SaksForbedring
  • med tanke på at valideringen er anonym har ikke valideringsmedlem noen spesiell

rolle her

• andrevalidering
  • Som valideringsmedlem skal man en tydelig se hvilke endringer som har skjedd

fra førstevalidering.

• beslutningsledd

Medlem skal  kunne:

• Saksinngang
• førstevalidering
• SaksForbedring
  • kunne abbonere på alle førstevaliderte saker via. email
  • kunne kunne diskutere saken på nett
  • kunne upvote eller downvote saken, prioritere
  • kunne legge inn “saksopplysning”, link osv. (komme med highlighted innspill)
  • legge seg inn på adopteringsliste
  • adoptere forslag der opprinnelig forslagsstiller har trekt seg
  • markere seg som backer
  • sortere innlegg i diskusjonen på navn, fylkestilhørighet osv.
• andrevalidering
• beslutningsledd
  • Stemme
  • sjekke status

Ekstern meningsbærer skal kunne:

• Saksinngang
  • Bør invitert til det rundebord om man har tilslutning i PIR (DD)?
    • Eksempel: Meningsbærere som har støtte i partiet kan legge inn saker til

førstevalidering

• førstevalidering
  • følge med i progress
• SaksForbedring
  • Diskutere saken
  • Flagge med “feil nivå”, lokal, fylkes, nasjonal (litt usikker her)
  • Komme med highlighted innspill
  • markere seg som backer
• andrevalidering
• beslutningsledd
  • sjekke status

ffentligheten skal kunne:

• Saksinngang
  • ingen rolle
• førstevalidering
• SaksForbedring
  • Lese saksteksten og highlighted, backers etc.., ikke diskusjonen
• andrevalidering
• beslutningsledd
  • se status

Vedlegg 4: Løpende referat

Start 10:25

• programmet som er satt opp er en disposisjon, må sannsynligvis endres underveis
• lokale meiningsbærere, hvordan skal de legges til i systemet
  • skal lokallag av PIR gi de makt?
  • de skal ikke få makt, de skal komme med forslag
  • hvordan vekte meningsbærere?
  • Gi engangskontoer til meningsbærere?
• Hvordan hente inn saker fra meningsbærere, få deres innspill i en sak (hørings­ish)?

Mål med dagen

• Hva betyr dette systemet i praksis, hva bør vi gjøre?
  • Starte med flytdiagrammet, se hva vi trenger i de ulike prosessene
• Med utgangspunktet vi har, hvordan gjøre det brukbart i praksis?
• Ikke mye som er “fast” i prosessen,
• Sikkerhet mot hacking?
  • Hvor høy sikkerhet trengs?

11:20 Øystein Jakobsen

• DD, stor spørreundersøkelse
  • The day we fight back, masse folk bak, blir oversett av “makten”
• hva er du opptatt av?
  • prioriteringer
  • meningsbærere
  • kan resultere i et program
• føringer
  • piratkodeks
  • kjerneprogram
  • breddeprogram
• skille mellom breddesaker og kjernesaker
• lokal/sentral
  • hvordan skal vi sørge for at vi ikke får et nytt Buskerud og fremdeles utvikle mye

lokalpolitikk?

• • må tilføre lokalpolitikken noe nytt
  • lobby for mer teknologikompetanse i lokalmyndigheter
• bredde/kjerne, lokal/sentral kan spesifiseres av forslagsstiller i Kjellsen­prosessen
  • som oftest ikke enkeltpersoner som bryr seg
  • som regel organisasjoner
  • klasifisering fra sak til sak
• vetorett?
  • flagging
  • hvor mange som godkjenner i V1 god indikator for saken
• brukerhistorier
  • hvordan skal hver  prosess foregå?, egenskaper til brukerhistorien
  • overordnet design­krav?

DVD­gruppa

• tvinge medlemmer inn? opt out­mulighet?
• systemet fungerer med mange medlemmer, maktkonsentrasjon med få?
• unngå at spamfiltersystemet blir spam :­)
• e­post en gang i blant, plagsomt for medlemmer?
• engasjere den tause majoriteten
• historikk for innsending av saker for et medlem, dersom den sender inn mange dårlige

forslag bør det være en form for restriksjon

Prosess, diskusjon:

• Man må kunne velge meningsbærere, men også velge bort enekltsaker, feks “tenka

representerer meg, men ikke i DLD ­saken”, eller ”Mitt grunnsyn er grunnleggende enig med Greenpeace, men ikke vedrørende hvalfangst ”

• Skille mellom det å være medlem i organisasjon, og det å støtte en organisasjon
• fem aktører:
  • piratpartiets medlemmer ­ høy promoeffekt.

12:05 Videre systemutvikling

• to system ­ DD og valideringssystemet, sammenføyes med brukerhistorier?
• DD ­ system med oversikt over hva meningsbærere står for og rangsjerer disse.
• Den overordnede minigsbæreren er PIRs medlemsbase.

12:15 ­ 13:50 Arbeid i to grupper, DD og prosess.

1350­ 1430­ presentasjon av arbeid

• diskusjon om diskusjonen.

1500 Veien videre

• skrive om kravspesifikasjonen til Kjellsen­prosessen til brukerhistorier
• plakatkampanje på Gløshaugen for å få frivillige utviklere til systemene våre?
• undersøke om det eksisterer noe fra før som kan brukes for å utvikle systemet for

Kjellsen­prosessen

• Per snakker med utvikler
• avtale nytt møte for videre utvikling
  • gå inn for møter annenhver uke
• ferdig brukerhistorier for Kjellsen­prosessen til neste møte
• møtereferat til onsdag
• verktøy for utvikling: confluence
  • i bruk av informed individual
  • egen JIRA (https://www.atlassian.com/software/jira) og confluence for PIR
  • Øystein Jakobsen tar ansvar for å finne/velge utviklerverktøy