Styrning av FreedomBox Community

Om vår gemenskap

Programvaruprojektet FreedomBox styrs av en gemenskap som inkluderar deltidsvolontärer och heltidsbidragsgivare. När det gäller styrning förlitar vi oss på vår skriftliga uppförandekod och ömsesidigt tillämpade standarder. Gemenskapen strävar efter att fatta beslut genom öppen diskussion och konsensus. I fall av oenighet diskuterar gemenskapen tills en lösning har hittats eller går med på att skjuta upp diskussionen. Även om ett utvalt antal av våra utvecklare har makten att acceptera sammanslagningsförfrågningar, är alla välkomna att gå med i vår bidragsgivargemenskap och skicka in kod eller icke-kodbidrag.

Kärnteam

Möt medlemmarna i vårt kärnteam! Även om flera gemenskapsmedlemmar bidrar, består kärnteamet av de som är mest involverade i utvecklingen av FreedomBox.

Bidragsgivare

Även om vårt kärnteam är litet, har hundratals volontärer bidragit till FreedomBox genom åren. Många av dessa bidragsgivare är listade här. Vi tackar dem för deras arbete!

Hur beslut fattas

I allmänhet diskuteras beslut om mjukvaruutveckling och design av medlemmar i kärnteamet och implementeras med hjälp av vår öppna mjukvaruutvecklingsplattform (dvs GitLab). Många av de beslut som tas av vårt team är okontroversiella och kräver inte längre diskussionsperioder.

Men ibland krävs längre diskussionsperioder. För förslag som sannolikt kan vara föremål för oenighet använder vi en "Request for Comments" (RFC)-procedur. RFC:er bör läggas upp på en av våra öppna utvecklingsplattformar (dvs Gitlab eller forumet) och bör innehålla (1) en skriftlig sammanfattning, skiss eller modell av förslaget, (2) en kort förklaring av varför förslaget behövs , och (3) en lista över åtgärder som krävs för att genomföra förslaget. Alternativt kan man också inkludera en fjärde punkt i RFC:n: en föreslagen tidslinje för diskussionsprocessen för att förhindra onödiga förseningar. Ibland gör oenighet det svårt att följa föreskrivna tidslinjer; i sådana fall bör deltagarna göra ansträngningar i god tro för att kompromissa och, om det inte är möjligt, kan de utöka diskussionen.

Förbättring genom revision

I allmänhet, när förslag angående mjukvaruutveckling eller design accepteras, behandlas dessa förslag som reviderbara, inte permanenta. Denna förbättring-för-revidering-strategi för förslag gör det möjligt för oss att acceptera generellt solida förslag utan att uppehålla oss vid mindre detaljer. Mindre justeringar av accepterade förslag kan alltid göras senare istället för i förväg. Liksom det ursprungliga förslaget är ändringar föremål för diskussion och kan inte göras ensidigt. I experimenterandets anda anammar vi reviderbarhet för att främja stegvisa förbättringar av vår programvara.