Керівництво спільнотою FreedomBox

Про нашу спільноту

Проєктом програмного забезпечення FreedomBox керує спільнота, в яку входять добровольці за сумісництвом та штатні співрозробники. В управлінні ми покладаємося на наші письмові норми поведінки та взаємно забезпечені стандарти. Громада прагне приймати рішення шляхом відкритих дискусій та консенсусу. У випадку розбіжності поглядів громада обговорює це, поки не буде знайдено вирішення або не погодиться відкласти обговорення. Незважаючи на те, що вибрана кількість наших розробників має право приймати запити на обʼєднання, кожен хто бажає приєднатися до нашої спільноти співрозробників та надсилати код або внески, які не є кодом.

Ядро команди

Зустрічайте учасників нашої основної команди! Хоч деякі учасники спільноти роблять внески, основна команда складається з тих, хто найбільше бере участь у розробці FreedomBox.

Співрозробники

Не зважаючи на те, що наша основна команда маленька, протягом років сотні добровольців зробили внесок у FreedomBox. Деякі з цих співрозробників перелічено тут. Ми дякуємо їм за їхню роботу!

Як приймаються рішення

Як правило, рішення про розробку програмного забезпечення та дизайну обговорюються учасниками основної команди і впроваджуються через нашу відкриту платформу для розробки ПЗ (таку як GitLab). Деякі рішення нашої команди суперечливі і не вимагають тривалого періоду обговорення.

Але іноді необхідні тривалі періоди обговорення. Для пропозицій, які, ймовірно, можуть бути предметом розбіжностей, ми використовуємо процедуру «Запит на коментарі» (RFC). RFC слід розміщувати на одній з наших відкритих платформ розробки (тобто Gitlab або форум) і включати (1) письмове резюме, ескіз або макет пропозиції, (2) коротке пояснення, чому така пропозиція потрібна та (3) перелік заходів, необхідних для реалізації пропозиції. За бажанням, можна також включити до RFC четвертий пункт: запропонований графік процесу обговорення з метою запобігання зайвим затримкам. Іноді розбіжності ускладнюють дотримання встановлених термінів; у таких випадках учасники повинні добросовісно докладати зусиль для компромісу і, якщо цього не зробити, можуть продовжити обговорення.

Покращення шляхом розгляду

Загалом, коли пропозиції щодо розробки або проектування програмного забезпечення приймаються, ці пропозиції розглядаються як переглянуті, а не постійні. Такий підхід до вдосконалення пропозицій дозволяє нам приймати тверді пропозиції, не зупиняючись на незначних деталях. Незначні зміни у прийнятих пропозиціях завжди можна зробити пізніше, а не заздалегідь. Як і оригінальна пропозиція, зміни можуть обговорюватися та не можуть бути в односторонньому порядку. У дусі експерименту, ми охоплюємо перегляд, щоб сприяти поступовим удосконаленням нашого програмного забезпечення.