LINUX.ORG.RU
ФорумTalks

Метаданные файлов (github)


0

1

Когда мы смотрим на репозиторий github, то напротив каждого файла мы видим комментарий про последнее изменение в коммите. Как правило на коммит общее описание и оно бестолковое.

Глядя первый раз на репозиторий, хотелось бы видеть, зачем нужны каждый каталог каждая папка и каждый файл. А если имя файла соответствует какому-то соглашению, то и ссылку на это соглашение. Например C#-программисту непросто сразу понять, что делают .po-файлы трансляции от gettext в проекте beagle написанном на C#. Особенно это относится к файлам для пакетирования - дистрибутивов много, все знать не будешь. Или то же самое про системы сборки (компиляции), их тоже много и в каждой свои стандарты.

Идея такая - сделать отдельный сайт, который бы хранил метаописания файлов. Передавать туда адрес git-репозитория и позволять через web-интерфейс редактировать метаданные, а так же быстро просматривать именно описания файлов, а не тексты последних коммитов. Метаописания можно даже не отдельно хранить, а обратно в git-репозиторий складывать (в его метаданные).

Как правильно толкнуть такую идею владельцам github? Может где-то ещё на сайтах конкурентах такая фича реализована?



Последнее исправление: terradot (всего исправлений: 2)

В нынешних условиях это ресурсозатратно. По одному только расширению файла ты ничего толком не узнаешь. Следовательно надо использовать file/libmagick. Кроме того, что они тормозы, надо писать и писать и писать много много правил на распознование.

Если эту часть ты осилишь, тогда можно думать о каком-то сервисе. Ибо гитхаб огромен.

gh0stwizard ★★★★★
()

Пиши документацию к проекту.

Deleted
()

Когда мы смотрим на репозиторий github, то напротив каждого файла мы видим комментарий про последнее изменение в коммите. Как правило на коммит общее описание и оно бестолковое.

Да там и в коммитах куча текста вида «Small fix», а ты думаешь многие ещё будут заморачиваться с описанием каждого файла? Ну даже если раз напишут, то при последующих изменениях забудут обновить.

aidan ★★★★
()
Ответ на: комментарий от gh0stwizard

это ресурсозатратно

кеширование после первого детектирования решает эту проблему

надо писать и писать и писать много много правил на распознование

а эту проблему решает crowd-соурсинг. Надо дать пользователям возможность создавать шаблоны и пусть создают.

aidan

terradot
() автор топика
Ответ на: комментарий от aidan

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

в википедии слова описывают, значит и файлы могут описать, не обязательно авторы.

terradot
() автор топика
Ответ на: комментарий от Stahl

есть ещё бинарные файлы (например рисунки) и не во всех них можно впихнуть метаданные и неединообразно это будет.

terradot
() автор топика
Ответ на: комментарий от terradot

Думаю этот вопрос надо решать в более общем виде.
Например продумай и проталкивай стандарт в виде дополнительного файла с именем в виде filename.meta (где filename имя описываемого файла) где будет храниться дополнительная информация по файлу как для человека, так и для машины.

Stahl ★★☆
()
Ответ на: комментарий от Stahl

А у меня другая идея. Есть такой фреймворк, называется Jekyll. На основе этого фреймворка сделан движок для блогов Octopress.

Идея в том, что можно сделать ветку gh-pages и там внутри конфигурационный файл для Jekyll, и тогда github.io будет показывать страницы, статически сгенерированные движком Jekyll.

Octopress, используя java-скрипты позволяет вести блог, а посетителям - добавлять комментарии, вот как это выглядит (просто произвольная страница произвольного блога на Octopress с комментариями):
http://imathis.github.io/octopress/blog/2011/07/23/octopress-20-surfaces/

Раз можно добавлять комментарии, то таким же макаром, наверное можно сделать и что-то wiki-подобное, то есть можно сделать аналог Octopress, только не для ведения блога, а для описания файлов проектов.

продумай и проталкивай стандарт в виде дополнительного файла с фиксированным именем

есть уже - file_id.diz, используется в Dos Navigator

terradot
() автор топика

Какую конкретно информацию ты хочешь увидеть?

https://github.com/justAmoment/iptvka

iptvka

Generate m3u playlists for iptv.

Requirement: Python2

Directory structure

Directory	Action	Description
format		in 	Specify internal playlist structure
img		---	Screenshots
list		in	Special lists of the selected channels
m3u		out	Generated m3u playlists
provider	in	Full channel list (IP & port & name)
Ну вот, я как автор во время написания программы описал структуру директорий. Этого достаточно?

Или ты хочешь:

  1. увидеть тех. описание:
    • install.sh — скрипт установки
    • iptvka.py — скрипт на питоне
    • iptvka_core.py — скрипт на питоне
  2. увидеть авторские мысли по поводу:
    • install.sh — необязательный скрипт установки, создаёт ярлык запуска только для систем, понимающих «/.local/share/applications»
    • iptvka.py — стартовый модуль
    • iptvka_core.py — многократно используемые функции вынесены сюда
  3. увидеть комментарии в луркостиле, только правда, ничего кроме правды и пох на мнение автора:
    • install.sh — ненужная х-ня
    • iptvka.py — жми сюда, чтобы заработало
    • iptvka_core.py — не трогай, тут всякие штуки для программы, а не для тебя
justAmoment ★★★★★
()

Например C#-программисту непросто сразу понять, что делают .po-файлы трансляции от gettext в проекте beagle написанном на C#.

Создаёшь в директории с .po-файлами файл README.md, в нём пишешь, что такое gettext, зачем он нужен и с чем его едят. При входе в директорию через морду гитхаба он видит этот файл и рисует его содержимое непосредственно под списком файлов. Левые сервисы, на которые всё равно ходить никто не будет, ВНЕЗАПНО становятся не нужны, к тому же в склонированном репозитории можно без всякого гитхаба и вообще без браузера сделать cat README.md и прочитать твои гениальные мысли.

А отдельный сайт не нужен.

INFOMAN ★★★★★
()
Последнее исправление: INFOMAN (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.