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

Wed Mar 7 00:28:34 MSK 2018

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 всех
репозиториев. 

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

-- 
Влад