"Проект посвящен сбору и структурированию данных о топонимике Чувашии и сопредельных территорий" -- в этом документе мы постараемся ответить на вопросы, которые могут появиться к формулировке проекта.

Зачем? Работа над сбором чувашской топонимики заинтересовала нас в контексте решения задач более высокого уровня -- реконструкции языковой и этнической истории Поволжья и Прикамья. Это накладывает отпечаток на выбор источников данных, технические и прочие решения. Мы стремимся учесть доступные топонимические данные всех релевантных языков и временных срезов, что могут быть полезными для решения конечных задач.

Что за источники данных? Для сбора данных мы хотим инвентаризировать доступные источники:

• книги
• карты
• данные Росреестра
• прочее?

Как планируется структурировать данные? Пока неясно, что должно быть базовой единицей документации топонимики. Мне (RI) думается, что для базовой единицы достаточно названия (на любом релевантном языке), типа сущности и временной метки. В идеале же, если думать про данные и метаданные, может быть оправдана, например, такая структура: уникальный человекочитаемый идентификатор тип топонима (село, город, деревня, река, микротопоним...) название на русском языке название на чувашском языке названия на прочих языках... дата создания источника данных дата заполнения базы данных кем заполнено поле и так далее

Не слишком ли много труда по структурированию информации для второстепенного проекта? Ну... Да, много. Но. В начале проекта обычно не очень понятно, какой объем внутренней бюрократии достаточен для достижения целей. Мои (RI) представления о полезном и прекрасном базируются на опыте участия в долгосрочном лексикографическом проекте: словарь бесермянского диалекта удмуртского языка. Словарю на текущий день 21 год, я участвовал в проекте примерно треть этого времени и имел возможность увидеть последствия продвигаемых мной технических и организационных решений.
В глоссарии проекта Fossil (https://www.fossil-scm.org) дано такое определение проекта -- "A collection of one or more computer files that serve some conceptually unified purpose, which purpose changes and evolves over time, with the history of that project being a valuable record".
Мы не может наперед знать, что именно окажется важным для проекта в будущем, поэтому мы храним подробную историю изменений проекта.

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

Какие плюсы дает вся эта бюрократия? TLDR: информация не теряется. Если более подробно, то бюрократия нужна, потому что 1) люди совершают ошибки, 2) человеческая память несовершенна.
Хранение всех изменений долговременного проекта в системе контроля версий позволяет всем участникам:

1. иметь полный доступ к истории проекта
2. быть уверенными, что они помнят одно и то же и говорят об одном и том же, будь то мельчайшее изменение или общая картина
3. исправлять случайные ошибки
4. понимать, кто является ответственным за любое изменение
5. не делать одну и ту же работу несколько раз
6. всегда иметь доступ к свежей версии файлов проекта и т.д.

ОК, как устроен проект с технической и организационной точки зрения? Для организации хранения информации о проекте, включая полную историю проекта, используется уже упомянутый Fossil (https://www.fossil-scm.org).
Fossil это продвинутое средство управления программными проектами, он включает в себя:

• систему контроля версий
• вики
• баг-трекер
• форум и прочее Ко всему этому прилагается веб-интерфейс и CLI (подробнее см. https://www.fossil-scm.org/home/doc/trunk/www/quickstart.wiki). Что касается организационного устройства, то для начала стоит обсудить роли.
  Моя точка зрения такая, что у топонимических данных есть жизненный цикл и устроен он вот таким образом:
• ввод данных (data entry)
• обзор данных (data review)
• редактирование данных (data editing)
• анализ данных (data analysis)
• публикация данных (data publishing)
• еще что-то? В роли data entry person может выступать кто угодно после первичного обучения, а последующие роли (reviewer, editor, analyst, publisher) требуют большей экспертизы.
  Поэтому интерфейс ввода данных может отличаться от интерфейсов для остальных ролей, например, результат обработки первичных данных мы вводим в Google Sheets, далее там же проводим этап review и этап editing. Затем импортируем в Fossil эти табличные данные, скажем, в CSV или TSV формате, с прикрепленными метаданными, типа, кто вбивал исходные данные, кто выступал ревьюером, кто редактором, когда это было и т.д. Затем в какой-то момент экспортируем из fossil-репозитория некоторое подмножество данных для анализа, преобразуя при этом хранящийся в репозитории CSV в базу данных (PostGres, sqlite3 etc). Естественно, текстовые данные, хранящиеся в репозитории, можно редактировать в любой момент, например, по итогам какого-то анализа или после более глубокого ревью.