Bug 38490 - Формальная процедура разрешения споров
Summary: Формальная процедура разрешения споров
Status: NEW
Alias: None
Product: Infrastructure
Classification: Infrastructure
Component: cross-component (show other bugs)
Version: unspecified
Hardware: all Linux
: P5 enhancement
Assignee: Dmitry V. Levin
QA Contact: Andrey Cherepanov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-15 23:16 MSK by Aleksey Cheusov
Modified: 2021-01-30 01:43 MSK (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aleksey Cheusov 2020-05-15 23:16:18 MSK
По отношению к AltLinux я человек сторонний, и, тем не менее, набрался наглости записать таки свои предложения к комьюнити, тем более, что они неоднократно обсуждались в приватной обстановке с mike@ и ldv@. Возможно, и с aen@, но тут не уверен. Сюда -- чтобы на память осталось, в назидание потомкам, так сказать.

Итак, проблема. Как и в любом команде open source разработчиков в AltLinux нет выделенного "начальника", который бы решал вопросы на правах "главного". Технические же споры время от времени возникают, возникали, и, уверен, будут возникать всегда, поскольку разработка ПО -- дело сложное, и единственно верного пути здесь просто не существует.

Возможные варианты решения:
1) Неформальный лидер/диктатор решает все. За примерами далеко ходить не нужно: Линус Торвальдс в разработке ядра Линукс, Тео в OpenBSD, Ульрих Дреппер в не столь далеком прошлом в glibc и т.д. Уверен, все знают многие примеры подобного рода. В спорные вопросы вмешивается Он Самый, и все решается так, как скажет Фюрер. Ни влево, ни вправо! Отдали честь и идем исполнять.
2) Спустить проблему на тормозах. Давайте сделаем так, как будто спора не было, аргументы высказаны не были, и сохраним статус кво, т.е. остаемся в рамках существующего решения, каким бы кривым оно ни казалось, или ничего не делаем, так как Всеобщего Одобрения получено не было.
3) Решения по спорным и нерешенным коллегиально вопросам принимает специальный комитет, состоящий из разработчиков, избранных специально с этой целью.

Преимущества и недостатки:
1) Я думаю, здесь все ясно и просто. Если Фюрер -- Бог, то это единственно правильный способ решать все вопросы. Люди, с чем-либо несогласные, могут идти лесом, поскольку уровень их компетенции недостаточен для того, что хотя бы немножко приблизиться к Богу! Если же Фюрер -- самозванец, то рано или поздно кто-нибудь форкнет проект, и все недовольные уйдут развивать альтернативный вариант, или вообще бросят всё и уйдут вникуда или в другой проект (нужное подчеркнуть). Фюрер же останется на бобах, и проект его скоро умрет, поскольку он остался один, или рано или поздно останется (или разорится).
2) Здесь, в общем, что-то похожее на пункт 1. Претенденты на Трон^w^w^w, желающие
сделать что-то великое и светлое, раз за разом наталкивающиеся на броню непонимания, рано или поздно покинут проект. Система же, оставшаяся без новых идей и наработок, превратится в замороженные эксремен^wокаменелости с тем же результатом.
3) На мой взгляд наиболее взрослый и разумный вариант для комьюнити, история которого насчитывает уже два десятка лет ;-) Во-первых, комитет принимает взвешенное решение, поскольку его принимает не один человек, а несколько, что позволяет среди прочего минимизировать и межличностные конфликты, которые, увы, тоже возможны. Сторона, чье решение не приняли, не будет "обижена" так сильно, как если бы Фюрер назвал его публично "мастурбирующей обезьяной"(с) или же его просто проигнорировали. Если человек адекватен, всеже что-то должно в голове зашевелиться, и у него появится шанс найти пробелы в своих предложениях и/или аргументах в ее защиту. Таким образом вполне успешно работают многие коллективы разработчиков во всем мире. Думаю, примеры приводить нет смысла. Их все знают.

Что делать по пункту 3:
а) Принять решение о количестве разработчиков в комитете так, чтобы учесть интересы как комьюнити, так и компании АльтЛинукс (или Базальт, все равно). Например, 2+3 (5 человек), 3+4 (7 человек) или 4+5(9 человек).
б) Разработать механизм голосования за членов комитета. Например, компания АльтЛинукс назначает своих представителей как угодно, ни перед кем не отчитываясь в своих действиях, в то же время за представителей комьюнити предусматривается закрытое голосование только членами комьюнити, но не сотрудниками AltLinux. При этом Равный голос имеют Все разработчики от комьюнити.
в) Члены комитета от комьюнити переизбираются каждый год/два/три/... и могут/не_могут быть переизбраны в течение, например, 3-х лет. Так обеспечивается ротация кадров, или, напротив, обеспечивается стабильно высокий уровень доверия к членам комитета и высокий уровень профессионализма каждого. Переголосование идет одновременно по всем членам комитета или по одному за какой-то период времени, в зависимости от того, что приоритетнее -- стабильность или гибкость этой структуры.
г) При обращении к комитету, несогласные друг с другом стороны (каждая сторона отдельно, сколько бы их ни было), сужают все свои 100500 писем в многочисленных списках рассылки до вменяемого размера, скажем, не больше трех страниц текста, и пересылают их их комитету. Комитет в закрытом режиме обсуждает проблему и принимает решение в пользу той или иной стороны. При этом голосование среди членов комитета закрытое (от членов комьюнити и спорящих сторон), а по результату их голосования комитет публикует ответ в списке рассылки о том, что по данному вопросу было принято такое-то и сякое-то решение потому-то и посему-то. Результат голосования внутри комитета публикуется/не_публикуется, как угодно.

The End
Comment 1 AEN 2020-05-18 11:43:58 MSK
Это все здорово, но совершенно не учитывает модель существования Альт, о которой я Вам писал.
Comment 2 Aleksey Cheusov 2020-05-18 13:09:47 MSK
(In reply to AEN from comment #1)
> Это все здорово, но совершенно не учитывает модель существования Альт, о
> которой я Вам писал.

Как правильно учесть интересы и компании и сообщества вам виднее. То, что описано здесь -- лишь пример, хорошо знакомый мне по одному из комьюнити, в котором я состою. Если вам эти идеи не близки в принципе, вы вправе просто закрыть тикет с пометкой WONTFIX. Это всего лишь "feature request".
Comment 3 AEN 2020-05-18 13:18:44 MSK
(Ответ для Aleksey Cheusov на комментарий #2)
> (In reply to AEN from comment #1)
> > Это все здорово, но совершенно не учитывает модель существования Альт, о
> > которой я Вам писал.
> 
> Как правильно учесть интересы и компании и сообщества вам виднее. То, что
> описано здесь -- лишь пример, хорошо знакомый мне по одному из комьюнити, в
> котором я состою. Если вам эти идеи не близки в принципе, вы вправе просто
> закрыть тикет с пометкой WONTFIX. Это всего лишь "feature request".

Мне они близки. Как идеи. 
Но далеки от нашей ситуации. 

Подумаю. 
Спасибо!
Comment 4 Alexey Gladkov 2020-05-20 15:42:05 MSK
> 1) Неформальный лидер/диктатор решает все.

В прошлом у нас были конфликты связанные как раз с этим. Чтобы этого избежать мы пришли к написанию полиси, которые обсуждаются и принимаются. Это конечно не панацея и споры иногда всё-таки возникают.

https://www.altlinux.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%9D%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D1%8B%D0%B5_%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B
https://www.altlinux.org/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%A7%D0%B5%D1%80%D0%BD%D0%BE%D0%B2%D0%B8%D0%BA%D0%B8_%D0%BD%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D1%8B%D1%85_%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%BE%D0%B2
Comment 5 Alexey Shabalin 2020-05-20 17:00:02 MSK
А что мешает в dns сделать понятные CNAME?
Comment 6 Andrew Savchenko 2020-05-20 17:13:32 MSK
(In reply to Alexey Shabalin from comment #5)
> А что мешает в dns сделать понятные CNAME?

Только отсутствие решения это сделать.
Comment 7 Andrew Savchenko 2020-05-20 17:14:23 MSK
(In reply to Andrew Savchenko from comment #6)
> (In reply to Alexey Shabalin from comment #5)
> > А что мешает в dns сделать понятные CNAME?
> 
> Только отсутствие решения это сделать.

Но всё же этот баг о более общей проблеме и названия ресурсов — это текущий пример.
Comment 8 Aleksey Cheusov 2021-01-29 21:54:07 MSK
С юбилеем!
Comment 9 AEN 2021-01-30 01:43:04 MSK
(Ответ для Aleksey Cheusov на комментарий #8)
> С юбилеем!

Алексей, спасибо!