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

Wed Mar 7 00:17:49 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:
>>>>
>>>>> # информация в этом письме не является побуждением к действию. См. финальную
>>>>> # версию этого письма в архивах 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) не совсем честно, когда
какая-то команда может окончательно выбрать свою тему, обладая
информацией, недоступной другим командам, отправившим свои сообщения
вовремя (о предполагаемом наполнении проектов / первых советах
преподавателей). Но наверное это преувеличено.

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

>>>> Кроме того, нужно уточнить, какой способ коммуникации следует для этого
>>>> использовать.
>>>
>>> Поддерживаю.
>>>
>>>> Я бы предпочёл сообщение в списке рассылке с каким-нибудь маркером в
>>>> теме письма.
>>>
>>> К примеру, "[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-пушам, но осложняется их возможностью.

>>>>> # Я не знаю, насколько достоверна информация о дате зачёта/"экзамена". Возможно,
>>>>> # времени уже меньше.
>>>>
>>>> Это стоило бы уточнить.
>>>
>>> Я думаю, это нужно уточнять либо в учебной части, либо у старост. Можно
>>> написать какой-нибудь 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.