[prac] Черновик письма студентам

Wed Mar 7 00:52:03 MSK 2018

Vladislav Ivanishin <vlad at ispras.ru> writes:

> Eugene Sharygin <eush at ispras.ru> writes:
>
>> Vladislav Ivanishin <vlad at ispras.ru> writes:
>>
>>> Eugene Sharygin <eush at ispras.ru> writes:
>>>
>>>> Vladislav Ivanishin <vlad at ispras.ru> writes:
>>>>
>>>>> Eugene Sharygin <eush at ispras.ru> writes:
>>>>>
>>>>>> Vladislav Ivanishin <vlad at ispras.ru> writes:
>>>>>>
>>>>>>> # информация в этом письме не является побуждением к действию. См. финальную
>>>>>>> # версию этого письма в архивах https://compilers.ispras.ru/pipermail/prac-sp-18/
>>>>>>>
>>>>>>> Добрый день, уважаемые студенты!
>>>>>>>
>>>>>>> В этом семестре в качестве практикума студентам групп 427 и 428 будет предложено
>>>>>>> в составе команд выполнить проекты, связанные с курсом "Конструирование
>>>>>>> компиляторов". При этом предполагается, что работа над проектами ведётся с
>>>>>>> использованием списков рассылки. Данное требование способствует
>>>>>>> - развитию навыков использования инструментов распределённой разработки
>>>>>>> - упрощению оценки вклада участников (оценки за курс будут выставлены на основе
>>>>>>>   осмысленной активности в списках рассылки)
>>>>>>> - развитию диалога между участниками разных проектов и преподавателями
>>>>>>
>>>>>> Думаю, этот список следует заменить (или предварить) списком целей
>>>>>> самого практикума, который как лучше сориентирует студентов, так и лучше
>>>>>> обоснует выбор формата проведения.
>>>>>
>>>>> Я за. Давай заменим.
>>>>
>>>> Тогда "развитие навыков" переносится дословно, развитие диалога,
>>>> пожалуй, тоже.
>>>>
>>>> Является ли простота выставления оценок одной из целей практикума? При
>>>> прочих равных - конечно да, но я не знаю, стоит ли это включать в
>>>> этот список.
>>>
>>> Не является целью, конечно. Можно вынести вне списка, но нужно написать
>>> и желательно где-нибудь рядом (или в другом месте, где фокус на
>>> использовании ML).
>>
>> Хорошо.
>>
>>>> Что-то ещё, наверное, можно добавить.
>>>
>>> Студентам полезно понимать цели курса, но полезнее непосредственно
>>> выполнять задание. Предлагаю долго об этом не думать.
>>
>> Хорошо.
>>
>>>>>> Одной из основных целей я вижу развитие навыков совместной работы над
>>>>>> проектом.
>>>>>
>>>>> Ага.
>>>>>
>>>>>>> # Про git наверное стоит упомянуть. Думаю, заведём в облаке сервер, где все
>>>>>>> # студенты будут пользователями, и репозиторий будет иметь права на запись
>>>>>>> # соответствующими группами. Github использовать не хотелось бы, поскольку по
>>>>>>> # задумке выполненные задания станут заданиями по компиляторам для
>>>>>>> # последователей.
>>>>>>
>>>>>> Да, для организации совместной работы можно развернуть несколько
>>>>>> непубличных Git-репозиториев. Репозитории будут служить точкой
>>>>>> синхронизации усилий команды и позволят нам как отслеживать статус
>>>>>> проектов во время выполнения, так и иметь единый снимок каждого проекта
>>>>>> в конце курса.
>>>>>
>>>>> Отлично. Соответственно, ровно это можно и сказать. На то, чтобы их
>>>>> завести реально у нас ещё есть время в запасе.
>>>>>
>>>>>>> Приватное общение без необходимости во время выполнения проектов не поощеряется.
>>>>>>> # можно вставить https://producingoss.com/en/producingoss.html#avoid-private-discussions
>>>>>>
>>>>>> Думаю, ссылку можно вставить, хотя для команд, регулярно встречающихся
>>>>>> IRL она может быть и не очень актуальна.
>>>>>
>>>>> Это просто некая теория, поясняющая, почему мы в качестве практики даём
>>>>> тренировку этого навыка, несмотря на то, что канал передачи сообщения
>>>>> IRL гораздо шире и потому возникает соблазн им воспользоваться.
>>>>
>>>> Согласен. Развернуть действительно распределённую разработку на двух
>>>> группах и одном факультете мы не в силах, но студенты должны понимать,
>>>> почему тренировка этого навыка им может пригодиться.
>>>>
>>>>>> Приватное общение точно не поощряется, потому что общение в списке
>>>>>> рассылки является одним из элементов курса.
>>>>>
>>>>>>> Общий план практикума:
>>>>>>> 1. Студетны делятся на команды и выбирают тему проекта для команды. К концу
>>>>>>>    недели (можно раньше) необходимо сообщить составы команд и
>>>>>>>    темы.
>>>>>>
>>>>>> Надо поставить какой-то определённый дедлайн, чтобы команды понимали,
>>>>>> сколько у них есть времени. Например, к концу воскресенья по MSK.
>>>>>
>>>>> Хорошо. Конец это 23.59? Предлагаю либо вс, либо пн.
>>>>
>>>> Можно в 23:59 в понедельник. Это бы дало студентам дополнительный
>>>> невыходной, чтобы всё утрясти. Тогда во вторник можем начать второй
>>>> этап.
>>>
>>> Хорошо.
>>>
>>>> Кто-то точно опоздает. Не хотелось бы, чтобы подача какими-то командами
>>>> своих списков пересекалась по времени с первыми сообщениями в списках
>>>> других команд.
>>>
>>> Чем это плохо? По мне так пускай пересекается.
>>
>> Я думал, что было бы (1) удобно в один день отправить в списки всех
>> команд первые сообщения согласно их темам и (2) не совсем честно, когда
>> какая-то команда может окончательно выбрать свою тему, обладая
>> информацией, недоступной другим командам, отправившим свои сообщения
>> вовремя (о предполагаемом наполнении проектов / первых советах
>> преподавателей). Но наверное это преувеличено.
>
> Действительно, это не совсем честно. С другой стороны, команды-пионеры в
> выигрыше просто от того, что они быстрее приступили к заданию. Мне бы не
> хотелось сдерживать команды, которые уже со всем определились из-за
> команд, которые ещё не готовы (конечно, они могут начинать работу без
> ML, но мы ведь это не поощряем).

Справедливо.

>> Ещё можно сказать, что утренний дедлайн провоцирует студентов работать
>> над заданием по ночам, в то время как вечерний дедлайн совместим с более
>> здоровым режимом сна.
>
> Я тоже об этом думал. Давай делать вечерний дедлайн.

Ок.

>>>>>> Кроме того, нужно уточнить, какой способ коммуникации следует для этого
>>>>>> использовать.
>>>>>
>>>>> Поддерживаю.
>>>>>
>>>>>> Я бы предпочёл сообщение в списке рассылке с каким-нибудь маркером в
>>>>>> теме письма.
>>>>>
>>>>> К примеру, "[newteam] <тема-проекта>". Думаю, за неделю не наберётся
>>>>> большого количества сообщений, так что беды особой не будет, если тема
>>>>> без маркера, но с ним наверное удобнее.
>>>>
>>>> Хорошо.
>>>>
>>>>>>>    Использование списка рассылки sp-prac-18 для координации поощеряется,
>>>>>>>    но не является обязательным на данном этапе. Предполагаемое число участников
>>>>>>>    команд -- от 3 до 5, в зависимости от сложности проекта.
>>>>>>> # В случае коллизии тем -- кто успел, тот и съел?
>>>>>>
>>>>>> Если команды пишут сообщение в список рассылки, то да, по дате письма.
>>>>>> Тем самым мы поощрим использование списка рассылки и для коммуникации на
>>>>>> начальном этапе.
>>>>>
>>>>> Гуд.
>>>>>
>>>>>> Стоит ли предусмотреть возможность смены темы до конца отведённого
>>>>>> срока?
>>>>>
>>>>> Думаю, запрещать не нужно. Я не вижу здесь какой-то возможности для
>>>>> злоупотребления. Нельзя ведь "застолбить" сразу все темы. А пока команда
>>>>> занимает какую-либо тему, другие темы уже разберут.
>>>>
>>>> Согласен.
>>>>
>>>>>> В любом случае стоит уточнить, какое письмо (первое или последнее)
>>>>>> является определяющим, чтобы другие команды знали, какие темы свободны,
>>>>>> а какие уже нет.
>>>>>
>>>>> Как насчёт того, чтобы просто знать в каждый момент текущую тему и в
>>>>> момент дедлайна её фиксировать?
>>>>
>>>> А если команды опаздывают? Тогда можно считать по первому сообщению
>>>> после дедлайна.
>>>
>>> Тогда так. Не нужно им говорить, что можно опаздывать ;-)
>>
>> Хорошо.
>>
>>>>>>> 2. Преподаватели утверждают составы команд (вернее, их размеры)
>>>>>>
>>>>>> Можно оставить за преподавателями право утверждать и составы тоже.
>>>>>
>>>>> Да, право лишним не будет. Я сейчас понял, что могут найтись студенты,
>>>>> неохотно объединяющиеся в команды. Тогда их можно будет собрать вместе и
>>>>> назначить командой.
>>>>>
>>>>>>>    и заводят отдельный список рассылки для каждой команды.
>>>>>>> 3. В течение следующей недели команды вырабатывают постановку задач (по
>>>>>>>    имеющимся темам) и планы их решения, распределяют работу
>>>>>>
>>>>>> ... распределяют работу по времени и между участниками команды
>>>>>>
>>>>>>>    с учётом зависимости
>>>>>>>    между подзадачами. На этом этапе необходимо общаться в рассылке, чтобы
>>>>>>>    преподаватели могли контролировать сложность и выполнимость плана.
>>>>>
>>>>> Ок.
>>>>>
>>>>>> По результатам второй недели в рассылке команды должен появиться план
>>>>>> проекта - письмо, содержащее список задач, выполнение которых
>>>>>> запланировано в рамках проекта, и предварительное распределение задач по
>>>>>> времени (с гранулярностью в одну неделю) и между участниками.
>>>>>>
>>>>>> Дальнейшие изменения плана должны также сопровождаться соответствующей
>>>>>> коммуникацией в списке рассылки.
>>>>>>
>>>>>> Запланировать все задачи на последние две недели нельзя. Все участники
>>>>>> должны быть вовлечены.
>>>>>
>>>>> Ок.
>>>>>
>>>>>>> # Ссылку даём https://en.wikipedia.org/wiki/Work_breakdown_structure ?
>>>>>>
>>>>>> Наверное, не стоит, по крайней мере пока мы не требует формализации
>>>>>> этапа постановки задач.
>>>>>
>>>>> Ок. Если кому-то будет интересно, почерпнёт эту информацию из данного треда.
>>>>>
>>>>>>> 4. В течение следующих четырёх недель команды работают над проектом. Требуется
>>>>>>>    по меньшей мере поддерживать следующий инвариант: "в основную ветку
>>>>>>>    репозитория не попадают патчи, не прошедшие обсуждения в рассылке".
>>>>>>
>>>>>> И не force-пушить. Force-пуши нам, пожалуй, стоило бы даже отключить.
>>>>>
>>>>> Да. Отключить-то мы их можем. Но тем же способом желающие их смогут
>>>>> включить :) Сказать это одназначно нужно.
>>>>
>>>> Если давать доступ по HTTPS, то конфиг должен быть защищён. Предполагаю,
>>>> что можно его защитить и от доступа по SSH при помощи read-only
>>>> Unix-прав на файл с конфигом.
>>>
>>> SSH проще. Да, можно, пожалуй. Получается, что они не вполне будут
>>> контролировать свой репозиторий, но в принципе, это не страшно. С другой
>>> стороны, мб просто не стоит этого делать -- это выглядит как решение
>>> социальной проблемы техническими средствами (мы не должны этого хотеть;
>>> доступ на чтение у нас и так будет к репозиторию в любой момент,
>>> force-push при желании мы легко обнаружим. Кроме того, либо команда
>>> будет делать force-push сообща, либо кто-то из студентов должен будет
>>> возмутиться в рассылке. В том и в другом случае просто выскажем
>>> неодобрение и расскажем что-нибудь поучительное, если случаи будут).
>>
>> Да, наверное это не страшно, но мы бы наверное хотели, чтобы вместо
>> force-пушей студенты пользовались ревертами, и не меняли публичную
>> историю - это вообще плохой стиль и в серьёзных проектах обычно не
>> применяется. Подождать, пока они сделают свой первый force-пуш и
>> рассказать им, как это плохо, может не сработать, потому что в маленькой
>> локальной команде force-пуши не проблема, они могут не связать это с
>> тем, что команда в реальности большая и распределённая.
>
> Я предлагаю обязательно написать не делать форс-пушей (кстати, только в
> мастер, или вообще?) А если кто-то не внял, то пожюрить пост-фактум.

Хорошо.

>> Я ещё думал насчёт того, можно ли обнаружить, если студенты смастерят
>> фейковую историю с подложными GIT_AUTHOR_DATE и GIT_COMMITTER_DATE и
>> запушат всё перед зачётом - эта проблема в какой-то степень ортогональна
>> force-пушам, но осложняется их возможностью.
>
> Ну мы можем просто в автоматическом режиме делать pull всех
> репозиториев.

Хорошее решение. Это довольно просто сделать технически, позволит
обнаруживать force-push и отправку сообщений пост-фактум и одновременно
оставляет студентам полную свободу над своим репозиторием.

>>>>>>> # Я не знаю, насколько достоверна информация о дате зачёта/"экзамена". Возможно,
>>>>>>> # времени уже меньше.
>>>>>>
>>>>>> Это стоило бы уточнить.
>>>>>
>>>>> Я думаю, это нужно уточнять либо в учебной части, либо у старост. Можно
>>>>> написать какой-нибудь placeholder -- например, $(дата зачёта - 2 дня) --
>>>>> и понядеяться, что значение выяснится в ближайшие пару дней.
>>>>
>>>> Ок.
>>>>
>>>>>>> 5. Команды составляют отчёты о выполненной работе.
>>>>>>
>>>>>> Думаю, в духе распределённой разработки принимать отчёты можно также
>>>>>> через список рассылки.
>>>>>
>>>>> Да. Список рассылки данной команды -- совершенно логичное место. Можно с
>>>>> пометкой [отчёт].
>>>>
>>>> Хотелось бы, чтобы все пометки были на одном языке ;-)
>>>
>>> Ну тогда логично на русском, остаток темы же на русском будет обычно.
>>
>> Согласен.
>>
>>>> Кстати, язык рассылки - русский? Может быть, и это надо уточнить.
>>>
>>> Думаю, язык рассылки должен соответствовать языку курса...
>>
>> Согласен.
>>
>>> Если команда решит общаться на эсперанто, это затруднит прочтение нами
>>> их сообщений и воспрепятствует диалогу между преподавателями и
>>> студентами.
>>
>> Очевидно, что выбор был бы не между эсперанто и русским.
>
> Ну я утрирую.
>
>>>>>> Кроме того, (по крайней мере) по завершении выполнения каждой из
>>>>>> поставленных задач в рассылке следовало бы ожидать появления писем о
>>>>>> статусе выполнения соответствующих задач.
>>>>>
>>>>> Было бы не плохо. Стоит ли это требовать и заводить маркер. Без
>>>>> предыдущего опыта сложно сказать, будет ли достаточно самих
>>>>> сообщений.
>>>>>
>>>>> Может, потребовать status-report один раз в некоторое время (вернее даже,
>>>>> просто назначить 2-3 даты для этих чекпоинтов), где будут перечислены
>>>>> все задачи и их статус.
>>>>
>>>> Ок, тогда можно каждой команде в конце первой недели назначить 2-3 даты
>>>> исходя из полученного от неё плана.
>>>
>>> Хорошо. Я изначально думал зафиксировать одинаковые даты для всех, но
>>> так логичнее. Больше работы, зато меньше принуждения.
>>>
>>>>>>> 6. Встреча IRL с выставлением оценок в зачётки.
>>>>>>>
>>>>>>> Предполагается, что темы проектов таковы, что команды могут работать
>>>>>>> изолированно. Однако обсуждение тем, которые могут быть интересны участникам
>>>>>>> других команд (вопросы по QBE, UNIX, git, ssh, использованию и настройке email
>>>>>>> клиентов и т.д.), имеет смысл проводить в рассылке prac-sp-18.
>>>>>>>
>>>>>>> Возможные темы проектов:
>>>>>>> - подготовить задачу построения SSA-формы в духе задач из домашнего задания
>>>>>>> - подготовить задачу выделения регионов в духе задач из домашнего задания
>>>>>>> - исследовать быстрые алгоритмы поиска доминаторов и границы доминирования,
>>>>>>>   подготовить задачу в духе задач из домашнего задания
>>>>>>> - составить документацию на QBE для будущих поколений студентов и предложить
>>>>>>>   генерацию web-based тэгов в духе mozilla dxr/doxygen/woboq для
>>>>>>>   compilers.ispras.ru
>>>>>>> - написать интерфейсы (bindings) к QBE для другого языка программирования
>>>>>>> - визуализация алгоритмов из курса
>>>>>>> - предлагайте свои идеи проектов (нужно успеть обсудить на первой неделе)
>>>>>>> # Ничего не забыл?
>>>>>>
>>>>>> - разработать систему плагинов для QBE, позволяющую запускать проходы из
>>>>>>   динамически подгружаемых библиотек
>>>>>
>>>>> Точно.
>>>>>
>>>>>>> Пожалуйста, подпишитесь на список рассылки prac-sp-18 [1] и передайте товарищам,
>>>>>>> которые не были зарегистрированы в ejudge.
>>>>>
>>>>> Ещё на сайте дадим ссылку на ML. Но это так, небольшой оффтоп.
>>>>
>>>> Да, это стоит сделать.
>>>>
>>>> Стоит ли постить на сайт выдержки из новостей и дискуссий из основного
>>>> списка рассылки? Я думаю, что нет, по крайней мере на первом этапе:
>>>> пусть архив читают.
>>>
>>> Да, читать архив очень полезно. FWIW ссылка (не предлагаю её в
>>> сообщение, над которым мы сейчас работаем)
>>> https://producingoss.com/en/growth.html#using-archives.
>>>
>>>>>>> [1]: https://compilers.ispras.ru/cgi-bin/mailman/listinfo/prac-sp-18
>>>>>
>>>>> Нужно как-то теперь наши комментарии преобразовать в прозу и ещё раз
>>>>> посмотреть, что получилось.  После того, как ты эту стену текста
>>>>> просмотришь, мог бы ты внести замечания и сделать это, либо делегировать
>>>>> мне половину? Либо сначала сейчас быстро всё склеим и напишем ещё раунд
>>>>> комментариев.
>>>>>
>>
>> Хорошо, тогда я сейчас попробую свести и послать вторую версию.
>
> Ок, спасибо.
>>
>>>>>> --
>>>>>> Regards,
>>>>>> Eugene Sharygin,
>>>>>> ISP RAS.