Процесс принятия решений #84
Conversation
sergeysova
requested review from
azinit,
AlexandrHoroshih,
ilyaagarkov,
carina-akaia and
a team
sergeysova
requested review from
a team,
binjospookie,
ilyaagarkov,
azinit,
AlexandrHoroshih and
carina-akaia
and removed request for
a team,
carina-akaia,
ilyaagarkov,
AlexandrHoroshih and
azinit
| @@ -136,6 +136,37 @@ | |||
|
|
|||
| > На данный момент ведется активная работа над тем, чтобы соединить опыт многих разработчиков и выразить его в единой методологии, помогающей в реализации методологии в проектах | |||
|
|
|||
| ## Как мы принимаем решения | |||
There was a problem hiding this comment.
Я бы старался держать README максимально простым, насколько это возможно
Человек, заходя на страницу вики - хочет сначала узнать о чем эта репа и какую пользу может ему принести, а потом уже - всяческие детали
Потому кста мне и показалось - что лучше такие вещи выносить как ссылки внизу (и то - их кол-во тоже потом бы уменьшить, как структуру добьем)
А потому - наверное стоит либо это же самое впихнуть в CONTRIBUTING (расширить, как по мне это прям про то), либо в другой файл (тоже в рут положить можно думаю)
There was a problem hiding this comment.
Можно добавить элемент "у меня есть предложение/проблема"
| 1. **Проблема**. Любое предложение должно решать какую-то проблему. Можно переименовать все сущности и сделать идеальную структуру, но это изменение ради изменений, если оно не решается хотя бы одну проблему потребителей, а ведь может и создать новую. Например, нельзя назвать проблемой легкую неконсистентность, до тех пор пока она не создает проблемы пользователям методологии. | ||
| 1. **Воспроизведение**. Чтобы каждому участнику команды было проще понять суть проблемы, её нужно воспроизвести. Здесь как в обычном open source, нужно по шагам описать действия и показать где проблема появляется. В случае структуры, можно создать простенький репозиторий с минимальным количеством файлов и кода, на которых проблема проявляется. | ||
| 1. **Целевая аудитория**. Здесь стоит описать проекты на которых встречается такая проблема. Методология не может решать проблемы всех возможных проектов, мы вынуждены сфокусироваться на ограниченном наборе типов проектов, на конкретной целевой аудитории и для качественного решения проблемы нужно четко понимать чью проблему мы решаем. Любая дополнительная информация о проекте и команде может помочь. Например, CRM для банковского продукта с командой от 10 разработчиков. | ||
| 1. **Возможное решение**. Несколько подробных предложений с практическими примерами как предлагается решить проблему из первого пункта. Чем больше подробной информации о том "почему именно так", тем лучше. Это самая спорная часть предложения, команда будет пытаться интегрировать его в методологию, но модификаций скорее всего не избежать. Предложенное решение может не дожить до внедрения в первозданном виде, это нормально, главное, чтобы решалась описанная проблема. |
There was a problem hiding this comment.
Очень похоже, что это надо засунуть в issue-template/pr-template не?
There was a problem hiding this comment.
Возможно то что здесь есть и можно оставить, но в темплейтах - по идее тоже должно быть (для нашего же удобства)
There was a problem hiding this comment.
Вот кста как вариант - можно этот чеклист еще в темплейты засунуть + твои критерии перечисленные
| 1. **Целевая аудитория**. Здесь стоит описать проекты на которых встречается такая проблема. Методология не может решать проблемы всех возможных проектов, мы вынуждены сфокусироваться на ограниченном наборе типов проектов, на конкретной целевой аудитории и для качественного решения проблемы нужно четко понимать чью проблему мы решаем. Любая дополнительная информация о проекте и команде может помочь. Например, CRM для банковского продукта с командой от 10 разработчиков. | ||
| 1. **Возможное решение**. Несколько подробных предложений с практическими примерами как предлагается решить проблему из первого пункта. Чем больше подробной информации о том "почему именно так", тем лучше. Это самая спорная часть предложения, команда будет пытаться интегрировать его в методологию, но модификаций скорее всего не избежать. Предложенное решение может не дожить до внедрения в первозданном виде, это нормально, главное, чтобы решалась описанная проблема. | ||
|
|
||
| Дальше есть два пути, что делать с собранной информацией: создать issue или создать pull request. |
There was a problem hiding this comment.
Мне казалось, что в воркфлоу главным образом должны быть и ответы на вопросы:
- Когда мне стоит создавать дискуссию/ишью?
Т.е. если у меня есть вопрос с возможным дополнением в методологию - должен ли я открывать ишью (у нас куча лежит и без подвижек пока) или же лучше начинать с дискуссии?
- Что делать с открытыми и затянувшимся дискуссиями (которые не связаны с задачей) - стоит их лочить и переписывать в доку или что-то другое?
Иными словами - есть ли у нас какие-то правила по очистке "бэклога" задач и дискуссий?
There was a problem hiding this comment.
- И самое главное - для нас - как принимать решения по дискуссии?
Ну да, кто-то может получить задачу на "расписывание доки по дискуссии" условно. Или же взять дискуссию для написания другой доки. А в какой момент нам нужно уметь остановиться и сделать выводы? (вытекает в каком-то виде из второго вопроса)
UPD:
| ## Как мы принимаем решения | ||
|
|
||
| В [CONTRIBUTING](./CONTRIBUTING.md) описано как предложить свои изменения, но это только первый шаг для внесения изменений. | ||
| Методология построена на базовых принципах и каждое новое предложение должно укладываться в эти принципы, поэтому после открытия pull request или issue, команда развития методологии будет заниматься интеграцией предложения в рамки существующих правил. Этот процесс можно ускорить и помочь команде, для этого нужно собрать как можно больше информации: |
There was a problem hiding this comment.
Я бы тут как-то дополнительно подчеркнул, что все то что ты ниже под этим написал (Проблема, Воспроизведение, ЦА, Возможное решение) - это то что нужно сделать перед ишью/дискуссией/pr
А потом уже (опираясь на доп. правила) контрибьюторы заводят ишью/дискуссию/pr
Кста опять же -нет ответа на вопрос, в каком случае можно заводить дискуссию - я бы это тоже проговорил, т.к. все остальное оч подробно описано - а про дискуссии ни слова
Как будто их сами по себе нельзя открывать
|
@sergeysova добей пож |
|
¯_(ツ)_/¯ |
|
@sergeysova До лучших времен оставляем( |
Closes #81