Information: Период проверки кода PR

У меня также сложилось впечатление, что процесс был написан с учетом репозиториев, ориентированных на сообщество, то есть PR ближе к организационным изменениям.

Согласен, код можно рассматривать как реализацию правил, которые меняют работу организации, но жесткие ограничения на то, как мы кодируем, невыполнимы. Это остановит развитие до практической остановки.

Может быть, сделать этот процесс более понятным, чтобы он не применялся к кодам PR?

Как можно быстрее? То есть в идеале вы бы слились сразу же после открытия пулл-реквеста или задачи? Нужно ли нам окно для диалога?

Я бы сказал, что мгновенно выходит за рамки возможного. :-) Нам нужно позволить рецензентам сделать обоснованный обзор, но поскольку им уже нужно время для этого, и слияние не происходит до того, как они это сделают, «мгновенно» является просто гипотетическим.

Итак, я не совсем согласен с @megoth в том, что мы просто не можем применить процесс к коду, поскольку есть спорные изменения кода.

Однако также стоит отметить, что весь смысл использования системы ревизий заключается в том, что изменения кода не являются необратимыми. Только после того, как изменение кода дойдет до полной версии, откат станет действительно важным делом, и это займет еще больше времени.

Я думаю, что суть здесь в том, что на самом деле не может быть жесткого правила относительно того, как долго каждый PR (будь то код или что-то еще) должен храниться до его слияния.

Множество изменений в коде и множество изменений в документации, ориентированной на человека, не вызовут споров, и нет причин устанавливать 14-дневную, 3-дневную или даже 3-часовую задержку между отправкой PR и слиянием чего-то вроде «исправленной опечатки». , гиперссылка на гиперссылку" ...

PR, как правило, должен просматривать кто-то(а), знакомый(ие) с изменяемой вещью(ями), независимо от того, является ли это кодом или нет. Кажется разумным сказать что-то вроде «w ИЛИ ((x и/или y) AND z) рассмотрит все PR для этого репозитория/файла/что угодно» — сроки, в течение которых проверки могут сильно варьироваться в зависимости от рабочей нагрузки рецензента (ов). на данный момент, а также цель PR!

Потенциально спорные изменения — любого рода — должны быть отмечены как таковые теми рецензентами, которым следует доверять, чтобы затем запросить более широкую проверку, потенциально включая «высшее руководство» любого рода.

Причина, по которой я бы выбрал фиксированный период, заключается в том, что были разговоры о 1) проблемах и запросах на вытягивание, которые не решаются достаточно быстро, 2) проблемах и запросах на вытягивание, которые не публикуются достаточно, чтобы дать возможность внести свой вклад и законность предложения ставятся под сомнение в результате. Если вы не записываете это явно, это означает, что люди, работающие над Solid в течение длительного времени, имеют преимущество перед новичками, которым приходится угадывать негласные правила взаимодействия, что делает присоединение к сообществу не открытой прозрачной средой.

В качестве решения мы можем сказать, что есть 3-дневный период для всех запросов на вытягивание и проблем, которые должны быть обработаны после публикации?

У меня все еще есть проблема с этим как с решением «один размер подходит всем». Я думаю, что это будет иметь несколько пагубных последствий для качества кода и хода проекта.

Прежде всего, не существует негласных правил взаимодействия, которые не существовали бы в течение как минимум пяти лет , и это очень стандартная практика для тысяч и тысяч проектов. Итак, конечно, если вы совершенно новичок в разработке в целом, вы окажетесь в невыгодном положении, но это не связано с чем-то конкретным с Solid, всегда есть кривая обучения, связанная с входом в новую область деятельности. Как я уже сказал, для меня важно, чтобы Solid имел очень низкий порог входа, но я не уверен, что разработка серверов — это то место, где люди должны начинать развивать свои навыки, среда, в которой им не нужно тесно сотрудничать с другими. разработчики с той же кодовой базой, вероятно, лучше подходят для них.

Многие, если не большинство, PR, естественно, будут иметь период проверки более трех дней, ограниченный наличием рецензентов. Тем не менее, мы также, естественно, стремимся к относительно небольшим PR, которые легко просматривать. Это хорошая практика, чтобы вы получали ранние отзывы и это не было слишком сложно для рецензентов. Однако это часто означает, что для решения более крупной задачи потребуется несколько дополнительных PR. Если для каждого PR требуется трехдневный период проверки, это значительно замедлит разработку. Если это политика, то я подозреваю, что мы, как разработчики, закончим тем, что не будем писать маленькие PR, а сделаем один большой PR, чтобы вам не нужно было ждать трехдневного периода проверки для каждого.

Это приведет к более крупным PR, которые труднее проверять, отходу от гибкой разработки и к большему риску ошибок, которые могут возникнуть в процессе проверки.

Мне было бы очень интересно узнать, что делают в этом отношении другие более крупные проекты, но для меня универсальный подход нежелателен и недостижим.

Мне трудно это сказать, так как я релиз-менеджер, но я думаю, что @TallTed поддержал бы это, процесс должен быть в большей степени на усмотрение релиз-менеджера. Менеджер релиза должен убедиться, что запрашиваются наиболее подходящие рецензенты, что запрашивается подходящее количество рецензентов в зависимости от проблемы, и что слияние не происходит до тех пор, пока нужное количество рецензентов не даст одобрение, что слияние не этого не произойдет, если есть запрошенные изменения, что нужные ветки заблокированы для обеспечения процесса проверки, что потенциально спорные PR доводятся, например, до сведения лидера сообщества с помощью некоторых средств уведомления, и действительно, другие рецензенты, безусловно, приветствуются, чтобы сделать это также.

Просто хотел включить заметки из разговора на собрании поддержки сообщества. Эти моменты были сделаны разными людьми в Solid Team:

• 3-дневный период проверки может замедлить работу.
• Какова практическая польза периода времени? Практической выгодой будет создание более открытой инклюзивной среды с прозрачным процессом принятия решений, который можно понять и на который можно ссылаться.
• какую проблему мы пытаемся решить? Есть ли другие способы ее решения? Что мы действительно пытаемся решить, так это то, что при внесении изменений возникают ограничения, и у них не было возможности представить свою точку зрения. Ограничение по времени — это способ дать возможность. Еще один подход к инклюзивности — убедиться, что предложения публикуются в среде, которую люди могут проверить, например, твердые/предложения.
  - Дискриминация скорее побочный эффект, чем корень.
• Где грань между инклюзивностью и эффективностью? Вы должны позволить людям, которые что-то делают, решать. Небольшая автономия — еще одна крайность, в которую нам не следует впадать. Метрократия – дократия. Реализация этих идеалов может быть токсичной для меньшинств.

• Постараемся быть в авангарде. Чему мы можем научиться на ошибках. Давайте не будем делать все так, как это делалось раньше, давайте задумаемся, почему мы делаем то, что делаем. Работайте над переводом спецификаций на естественный язык. Особенно, когда спецификации развиваются, их трудно поддерживать в актуальном состоянии. Это может быть очень длинно, и людям будет легче читать, может быть слишком много для разжевывания. Предлагаю попытаться найти темы в спецификации. Найдите способы распространения взглядов на спецификацию. Пишите больше туториалов, для решения различных задач. Также есть место для сообщений в блогах, объясняющих элементы спецификации. Превратите его в жевательные лакомства.

• Мы можем удалить коммиты, они обратимы, однако практична ли отмена? Откат сообщества выполняется медленно, поэтому откат займет еще больше времени. Сложнее вернуться на сервер, потому что элементы созданы на основе предыдущих решений.

• Мы ничем не отличаемся от другого проекта. Хотя установка периода времени отличается от предыдущей практики, мы пытаемся построить другую модель, а в предыдущих моделях доминировала однородная группа, поэтому хотим ли мы использовать прошлые практики или стремимся быть на грани мысли? Можем ли мы научиться на предыдущих примерах, как не попасть в те же ловушки и проанализировать, что сработало? Мы обещаем быть другими – то, что работало в прошлом, не сработало.

• Можем ли мы различать репозитории? Если да, то как?

• Кодекс отличается от правил? Сервер Node Solid оказывает влияние на общество, как и репозиторий сообщества и спецификация Solid. Так как отличить? Трудно оценить, что будет иметь влияние на общество, особенно когда профессионалы, проводящие эту оценку, не могут получить доступ к информации, потому что она не на языке, который они могут интерпретировать.
• Solid Server — это нормативная часть программного обеспечения, которое оказывает огромное влияние на общество, поэтому решения в коде имеют большое влияние.
• Отдельные запросы на вытягивание представляют собой небольшие изменения, не обладающие этим свойством. Они просто существуют для того, чтобы сделать изменения постепенными, чтобы охватить наше внимание. Не то же самое, что социальные изменения, потому что они качественно и количественно не совпадают.
• Три репозитория спецификации и репозиторий сообщества должны иметь более строгие процессы, например, с определенным минимальным периодом проверки и назначенным рецензентом. Спецификация имеет большое нормативное действие. Хороший способ отличить репозитории по нормативному эффекту, который они могут иметь в целом. Репозиторий сообщества и надежная спецификация относятся к этой категории. Так что было бы хорошо иметь прозрачное слияние.

• Может быть установлен гибридный набор правил для node-solid-server, говорящий, что если изменение отклоняется от спецификации, для него требуется более длительное время проверки. Случаи, когда мы реализуем спецификации в коде, который отличается от спецификации, также важно иметь процесс.

• Рабочий процесс и шаги не документированы.

• Инженеры больше доверяют конвейеру, чем не инженеры. Может быть, мы верим в это. Может есть смысл. Демография культуры разработчиков, может быть, это потому, что мы думаем, что так и должно быть.
• Ключевые решения маскируются под технические, хотя на самом деле они имеют серьезные последствия, выходящие за рамки технических.
• Код может иметь огромное влияние на общество, поэтому важно понимать его влияние и позволять людям вносить свой вклад.
• Естественный язык — спецификациям в любом случае не помешало бы обновление. При этом есть лучший способ объяснить вещь. Не стал бы переписывать технические элементы как нетехнические. Существует возможность улучшить читабельность спецификации, чтобы убедиться, что она правильная. Получит много отпора, говорящего, что техническое будет удалено.
  
  
  
  • Нам нужно создавать вещи, которые принимаются и, следовательно, должны быть понятны всем.
  
  

@TallTed , у вас есть какие-нибудь мысли о протоколе встречи в предыдущем комментарии?

В качестве дальнейшего пути предлагаю следующее:

Запросы на включение и проблемы, связанные со следующими репозиториями, должны быть открыты в течение как минимум трех дней:
https://github.com/solid/solid-спецификация
https://github.com/solid/веб-доступ-контроль-спецификация
https://github.com/solid/webid-oidc-spec
https://github.com/solid/сообщество

Запросы на вытягивание и проблемы, связанные со всеми другими репозиториями, могут быть закрыты немедленно, и у них нет минимального времени, в течение которого они должны оставаться открытыми, если только они не отклоняются от спецификации, и в этом случае они должны быть открыты как минимум три дня.

Есть возражения?

Работает на меня. Также есть возможность добавить текст к описанию роли менеджера по выпуску, описывающий, что он должен делать с оставшимися репозиториями.

Мне тоже нравится это решение :smile_cat: Давайте тоже куда-нибудь запишем аргументацию, чтобы люди поняли, что мы за ней думаем

@kjetilk Да, я добавлю примечание на https://github.com/solid/community/pull/44 .

@megoth хорошо, включит краткое описание в файл readme репозитория сообщества.

https://github.com/solid/community/blob/master/README.md