[prac] Черновик письма студентам
Eugene Sharygin
eush at ispras.ru
Tue Mar 6 23:09:42 MSK 2018
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 будет предложено
>>> в составе команд выполнить проекты, связанные с курсом "Конструирование
>>> компиляторов". При этом предполагается, что работа над проектами ведётся с
>>> использованием списков рассылки. Данное требование способствует
>>> - развитию навыков использования инструментов распределённой разработки
>>> - упрощению оценки вклада участников (оценки за курс будут выставлены на основе
>>> осмысленной активности в списках рассылки)
>>> - развитию диалога между участниками разных проектов и преподавателями
>>
>> Думаю, этот список следует заменить (или предварить) списком целей
>> самого практикума, который как лучше сориентирует студентов, так и лучше
>> обоснует выбор формата проведения.
>
> Я за. Давай заменим.
Тогда "развитие навыков" переносится дословно, развитие диалога,
пожалуй, тоже.
Является ли простота выставления оценок одной из целей практикума? При
прочих равных - конечно да, но я не знаю, стоит ли это включать в
этот список.
Что-то ещё, наверное, можно добавить.
>> Одной из основных целей я вижу развитие навыков совместной работы над
>> проектом.
>
> Ага.
>
>>> # Про git наверное стоит упомянуть. Думаю, заведём в облаке сервер, где все
>>> # студенты будут пользователями, и репозиторий будет иметь права на запись
>>> # соответствующими группами. Github использовать не хотелось бы, поскольку по
>>> # задумке выполненные задания станут заданиями по компиляторам для
>>> # последователей.
>>
>> Да, для организации совместной работы можно развернуть несколько
>> непубличных Git-репозиториев. Репозитории будут служить точкой
>> синхронизации усилий команды и позволят нам как отслеживать статус
>> проектов во время выполнения, так и иметь единый снимок каждого проекта
>> в конце курса.
>
> Отлично. Соответственно, ровно это можно и сказать. На то, чтобы их
> завести реально у нас ещё есть время в запасе.
>
>>> Приватное общение без необходимости во время выполнения проектов не поощеряется.
>>> # можно вставить https://producingoss.com/en/producingoss.html#avoid-private-discussions
>>
>> Думаю, ссылку можно вставить, хотя для команд, регулярно встречающихся
>> IRL она может быть и не очень актуальна.
>
> Это просто некая теория, поясняющая, почему мы в качестве практики даём
> тренировку этого навыка, несмотря на то, что канал передачи сообщения
> IRL гораздо шире и потому возникает соблазн им воспользоваться.
Согласен. Развернуть действительно распределённую разработку на двух
группах и одном факультете мы не в силах, но студенты должны понимать,
почему тренировка этого навыка им может пригодиться.
>> Приватное общение точно не поощряется, потому что общение в списке
>> рассылки является одним из элементов курса.
>
>>> Общий план практикума:
>>> 1. Студетны делятся на команды и выбирают тему проекта для команды. К концу
>>> недели (можно раньше) необходимо сообщить составы команд и
>>> темы.
>>
>> Надо поставить какой-то определённый дедлайн, чтобы команды понимали,
>> сколько у них есть времени. Например, к концу воскресенья по MSK.
>
> Хорошо. Конец это 23.59? Предлагаю либо вс, либо пн.
Можно в 23:59 в понедельник. Это бы дало студентам дополнительный
невыходной, чтобы всё утрясти. Тогда во вторник можем начать второй
этап.
Кто-то точно опоздает. Не хотелось бы, чтобы подача какими-то командами
своих списков пересекалась по времени с первыми сообщениями в списках
других команд.
>> Кроме того, нужно уточнить, какой способ коммуникации следует для этого
>> использовать.
>
> Поддерживаю.
>
>> Я бы предпочёл сообщение в списке рассылке с каким-нибудь маркером в
>> теме письма.
>
> К примеру, "[newteam] <тема-проекта>". Думаю, за неделю не наберётся
> большого количества сообщений, так что беды особой не будет, если тема
> без маркера, но с ним наверное удобнее.
Хорошо.
>>> Использование списка рассылки sp-prac-18 для координации поощеряется,
>>> но не является обязательным на данном этапе. Предполагаемое число участников
>>> команд -- от 3 до 5, в зависимости от сложности проекта.
>>> # В случае коллизии тем -- кто успел, тот и съел?
>>
>> Если команды пишут сообщение в список рассылки, то да, по дате письма.
>> Тем самым мы поощрим использование списка рассылки и для коммуникации на
>> начальном этапе.
>
> Гуд.
>
>> Стоит ли предусмотреть возможность смены темы до конца отведённого
>> срока?
>
> Думаю, запрещать не нужно. Я не вижу здесь какой-то возможности для
> злоупотребления. Нельзя ведь "застолбить" сразу все темы. А пока команда
> занимает какую-либо тему, другие темы уже разберут.
Согласен.
>> В любом случае стоит уточнить, какое письмо (первое или последнее)
>> является определяющим, чтобы другие команды знали, какие темы свободны,
>> а какие уже нет.
>
> Как насчёт того, чтобы просто знать в каждый момент текущую тему и в
> момент дедлайна её фиксировать?
А если команды опаздывают? Тогда можно считать по первому сообщению
после дедлайна.
>>> 2. Преподаватели утверждают составы команд (вернее, их размеры)
>>
>> Можно оставить за преподавателями право утверждать и составы тоже.
>
> Да, право лишним не будет. Я сейчас понял, что могут найтись студенты,
> неохотно объединяющиеся в команды. Тогда их можно будет собрать вместе и
> назначить командой.
>
>>> и заводят отдельный список рассылки для каждой команды.
>>> 3. В течение следующей недели команды вырабатывают постановку задач (по
>>> имеющимся темам) и планы их решения, распределяют работу
>>
>> ... распределяют работу по времени и между участниками команды
>>
>>> с учётом зависимости
>>> между подзадачами. На этом этапе необходимо общаться в рассылке, чтобы
>>> преподаватели могли контролировать сложность и выполнимость плана.
>
> Ок.
>
>> По результатам второй недели в рассылке команды должен появиться план
>> проекта - письмо, содержащее список задач, выполнение которых
>> запланировано в рамках проекта, и предварительное распределение задач по
>> времени (с гранулярностью в одну неделю) и между участниками.
>>
>> Дальнейшие изменения плана должны также сопровождаться соответствующей
>> коммуникацией в списке рассылки.
>>
>> Запланировать все задачи на последние две недели нельзя. Все участники
>> должны быть вовлечены.
>
> Ок.
>
>>> # Ссылку даём https://en.wikipedia.org/wiki/Work_breakdown_structure ?
>>
>> Наверное, не стоит, по крайней мере пока мы не требует формализации
>> этапа постановки задач.
>
> Ок. Если кому-то будет интересно, почерпнёт эту информацию из данного треда.
>
>>> 4. В течение следующих четырёх недель команды работают над проектом. Требуется
>>> по меньшей мере поддерживать следующий инвариант: "в основную ветку
>>> репозитория не попадают патчи, не прошедшие обсуждения в рассылке".
>>
>> И не force-пушить. Force-пуши нам, пожалуй, стоило бы даже отключить.
>
> Да. Отключить-то мы их можем. Но тем же способом желающие их смогут
> включить :) Сказать это одназначно нужно.
Если давать доступ по HTTPS, то конфиг должен быть защищён. Предполагаю,
что можно его защитить и от доступа по SSH при помощи read-only
Unix-прав на файл с конфигом.
>>> # Я не знаю, насколько достоверна информация о дате зачёта/"экзамена". Возможно,
>>> # времени уже меньше.
>>
>> Это стоило бы уточнить.
>
> Я думаю, это нужно уточнять либо в учебной части, либо у старост. Можно
> написать какой-нибудь 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. Но это так, небольшой оффтоп.
Да, это стоит сделать.
Стоит ли постить на сайт выдержки из новостей и дискуссий из основного
списка рассылки? Я думаю, что нет, по крайней мере на первом этапе:
пусть архив читают.
>>> [1]: https://compilers.ispras.ru/cgi-bin/mailman/listinfo/prac-sp-18
>
> Нужно как-то теперь наши комментарии преобразовать в прозу и ещё раз
> посмотреть, что получилось. После того, как ты эту стену текста
> просмотришь, мог бы ты внести замечания и сделать это, либо делегировать
> мне половину? Либо сначала сейчас быстро всё склеим и напишем ещё раунд
> комментариев.
>
>> --
>> Regards,
>> Eugene Sharygin,
>> ISP RAS.
More information about the prac-sp-18
mailing list