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

Tue Mar 6 23:51:39 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:
>>>
>>>> # информация в этом письме не является побуждением к действию. См. финальную
>>>> # версию этого письма в архивах 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 в понедельник. Это бы дало студентам дополнительный
> невыходной, чтобы всё утрясти. Тогда во вторник можем начать второй
> этап.

Хорошо.

> Кто-то точно опоздает. Не хотелось бы, чтобы подача какими-то командами
> своих списков пересекалась по времени с первыми сообщениями в списках
> других команд.

Чем это плохо? По мне так пускай пересекается.

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

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

-- 
Влад