Если вы читаете эту статью, я надеюсь, что вы знаете что такое пул-реквест (pull-request) и как его сделать. Здесь пойдет речь о требованиям к исходному коду.

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

1. Исправления опечаток в названиях переменных, функций (принимаются быстро с огромной благодарностью, накосячить в таких исправлениях сложно)
2. Исправления опечаток в названиях классов, интерфейсов, юнитов (принимаются быстро с огромной благодарностью, главное ничего не забыть и не добавить лишних изменений)
3. Добавление комментариев в код (комментарии должны быть по делу, они должны описывать не что происходит, а почему именно это)
4. Добавление и исправление юнит-тестов (принимаются быстро с огромной благодарностью)
5. Исправление ошибок в коде в пределах одного юнита (крайне желательно указание инцидента в багтрекере, чем более локальное изменение тем лучше)
6. Добавление новых экспортов, импортов и тд. (такие изменения, если они не добавляют новых интерфейсов и зависимостей будут приниматься без особых претензий, большую часть кода, который не хочется приводить под стандарты САС.Планеты, можно расположить в отдельном юните в папке Includes как это сделано для SAS4WinCE, YaMobileCache, LibBMP и тд)
7. Добавление новых элементов в графический интерфейс, параметров в окно настроек (такие изменения, если они не добавляют новых интерфейсов и зависимостей будут приниматься без особых претензий, крайне желательно не менять существующее поведение без веских аргументов для этого)
8. Изменения в поведении основных подсистем, конвейеров подготовки отображаемой карты и тд. (нужно быть готовым обосновать необходимость изменений и почему именно так, код должен строго соответствовать по форматированию и стилю остальному коду)
9. Изменения существующих интерфейсов и добавление новых (нужно быть готовым обосновать необходимость изменений и почему именно так, код должен строго соответствовать по форматированию и стилю остальному коду, возможны претензии к именованию интерфейсов и их методов и тд.)

Общий итог - чем локальнее изменение, тем проще ему будет пройти ревью. Файлы с интерфейсами i_*.pas - изменять в последнюю очередь и быть готовым доказывать необходимость их изменения для достижения поставленной цели и необходимость этой цели вообще. Причем крайне желательно это делать еще в багтрекере в подтвержденной хотелке до отправки пул-реквеста.