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

[Vladislav Ivanishin]

Eugene Sharygin <eush at ispras.ru> writes:

> Vladislav Ivanishin <vlad at ispras.ru> writes:
>
>> # информация в этом письме не является побуждением к действию. См. финальную
>> # версию этого письма в архивах https://compilers.ispras.ru/pipermail/prac-sp-18/
>>
>> Добрый день, уважаемые студенты!
>>
>> В этом семестре в качестве практикума студентам групп 427 и 428 будет предложено
>> в составе команд выполнить проекты, связанные с курсом "Конструирование
>> компиляторов". При этом предполагается, что работа над проектами ведётся с
>> использованием списков рассылки. Данное требование способствует
>> - развитию навыков использования инструментов распределённой разработки
>> - упрощению оценки вклада участников (оценки за курс будут выставлены на основе
>>   осмысленной активности в списках рассылки)
>> - развитию диалога между участниками разных проектов и преподавателями
>
> Думаю, этот список следует заменить (или предварить) списком целей
> самого практикума, который как лучше сориентирует студентов, так и лучше
> обоснует выбор формата проведения.

Я за. Давай заменим.

> Одной из основных целей я вижу развитие навыков совместной работы над
> проектом.

Ага.

>> # Про git наверное стоит упомянуть. Думаю, заведём в облаке сервер, где все
>> # студенты будут пользователями, и репозиторий будет иметь права на запись
>> # соответствующими группами. Github использовать не хотелось бы, поскольку по
>> # задумке выполненные задания станут заданиями по компиляторам для
>> # последователей.
>
> Да, для организации совместной работы можно развернуть несколько
> непубличных Git-репозиториев. Репозитории будут служить точкой
> синхронизации усилий команды и позволят нам как отслеживать статус
> проектов во время выполнения, так и иметь единый снимок каждого проекта
> в конце курса.

Отлично. Соответственно, ровно это можно и сказать. На то, чтобы их
завести реально у нас ещё есть время в запасе.

>> Приватное общение без необходимости во время выполнения проектов не поощеряется.
>> # можно вставить https://producingoss.com/en/producingoss.html#avoid-private-discussions
>
> Думаю, ссылку можно вставить, хотя для команд, регулярно встречающихся
> IRL она может быть и не очень актуальна.

Это просто некая теория, поясняющая, почему мы в качестве практики даём
тренировку этого навыка, несмотря на то, что канал передачи сообщения
IRL гораздо шире и потому возникает соблазн им воспользоваться.

> Приватное общение точно не поощряется, потому что общение в списке
> рассылки является одним из элементов курса.

>> Общий план практикума:
>> 1. Студетны делятся на команды и выбирают тему проекта для команды. К концу
>>    недели (можно раньше) необходимо сообщить составы команд и
>>    темы.
>
> Надо поставить какой-то определённый дедлайн, чтобы команды понимали,
> сколько у них есть времени. Например, к концу воскресенья по MSK.

Хорошо. Конец это 23.59? Предлагаю либо вс, либо пн.

> Кроме того, нужно уточнить, какой способ коммуникации следует для этого
> использовать.

Поддерживаю.

> Я бы предпочёл сообщение в списке рассылке с каким-нибудь маркером в
> теме письма.

К примеру, "[newteam] <тема-проекта>". Думаю, за неделю не наберётся
большого количества сообщений, так что беды особой не будет, если тема
без маркера, но с ним наверное удобнее.

>>    Использование списка рассылки sp-prac-18 для координации поощеряется,
>>    но не является обязательным на данном этапе. Предполагаемое число участников
>>    команд -- от 3 до 5, в зависимости от сложности проекта.
>> # В случае коллизии тем -- кто успел, тот и съел?
>
> Если команды пишут сообщение в список рассылки, то да, по дате письма.
> Тем самым мы поощрим использование списка рассылки и для коммуникации на
> начальном этапе.

Гуд.

> Стоит ли предусмотреть возможность смены темы до конца отведённого
> срока?

Думаю, запрещать не нужно. Я не вижу здесь какой-то возможности для
злоупотребления. Нельзя ведь "застолбить" сразу все темы. А пока команда
занимает какую-либо тему, другие темы уже разберут.

> В любом случае стоит уточнить, какое письмо (первое или последнее)
> является определяющим, чтобы другие команды знали, какие темы свободны,
> а какие уже нет.

Как насчёт того, чтобы просто знать в каждый момент текущую тему и в
момент дедлайна её фиксировать?

>> 2. Преподаватели утверждают составы команд (вернее, их размеры)
>
> Можно оставить за преподавателями право утверждать и составы тоже.

Да, право лишним не будет. Я сейчас понял, что могут найтись студенты,
неохотно объединяющиеся в команды. Тогда их можно будет собрать вместе и
назначить командой.

>>    и заводят отдельный список рассылки для каждой команды.
>> 3. В течение следующей недели команды вырабатывают постановку задач (по
>>    имеющимся темам) и планы их решения, распределяют работу
>
> ... распределяют работу по времени и между участниками команды
>
>>    с учётом зависимости
>>    между подзадачами. На этом этапе необходимо общаться в рассылке, чтобы
>>    преподаватели могли контролировать сложность и выполнимость плана.

Ок.

> По результатам второй недели в рассылке команды должен появиться план
> проекта - письмо, содержащее список задач, выполнение которых
> запланировано в рамках проекта, и предварительное распределение задач по
> времени (с гранулярностью в одну неделю) и между участниками.
>
> Дальнейшие изменения плана должны также сопровождаться соответствующей
> коммуникацией в списке рассылки.
>
> Запланировать все задачи на последние две недели нельзя. Все участники
> должны быть вовлечены.

Ок.

>> # Ссылку даём https://en.wikipedia.org/wiki/Work_breakdown_structure ?
>
> Наверное, не стоит, по крайней мере пока мы не требует формализации
> этапа постановки задач.

Ок. Если кому-то будет интересно, почерпнёт эту информацию из данного треда.

>> 4. В течение следующих четырёх недель команды работают над проектом. Требуется
>>    по меньшей мере поддерживать следующий инвариант: "в основную ветку
>>    репозитория не попадают патчи, не прошедшие обсуждения в рассылке".
>
> И не force-пушить. Force-пуши нам, пожалуй, стоило бы даже отключить.

Да. Отключить-то мы их можем. Но тем же способом желающие их смогут
включить :) Сказать это одназначно нужно.

>> # Я не знаю, насколько достоверна информация о дате зачёта/"экзамена". Возможно,
>> # времени уже меньше.
>
> Это стоило бы уточнить.

Я думаю, это нужно уточнять либо в учебной части, либо у старост. Можно
написать какой-нибудь placeholder -- например, $(дата зачёта - 2 дня) --
и понядеяться, что значение выяснится в ближайшие пару дней.

>> 5. Команды составляют отчёты о выполненной работе.
>
> Думаю, в духе распределённой разработки принимать отчёты можно также
> через список рассылки.

Да. Список рассылки данной команды -- совершенно логичное место. Можно с
пометкой [отчёт].

> Кроме того, (по крайней мере) по завершении выполнения каждой из
> поставленных задач в рассылке следовало бы ожидать появления писем о
> статусе выполнения соответствующих задач.

Было бы не плохо. Стоит ли это требовать и заводить маркер. Без
предыдущего опыта сложно сказать, будет ли достаточно самих
сообщений.

Может, потребовать status-report один раз в некоторое время (вернее даже,
просто назначить 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. Но это так, небольшой оффтоп.

>> [1]: https://compilers.ispras.ru/cgi-bin/mailman/listinfo/prac-sp-18

Нужно как-то теперь наши комментарии преобразовать в прозу и ещё раз
посмотреть, что получилось.  После того, как ты эту стену текста
просмотришь, мог бы ты внести замечания и сделать это, либо делегировать
мне половину? Либо сначала сейчас быстро всё склеим и напишем ещё раунд
комментариев.

> --
> Regards,
> Eugene Sharygin,
> ISP RAS.

-- 
Влад