Редактирование своей статьи на Хабре через выделение цитаты в HabrAjax; поддержка Iceweasel

[@spmbt]

Я же говорю — используют десятки человек. Но часть из них не могут писать или даже ставить оценки на Хабр. Поэтому такие фичи как редактирование собственных постов, практически интересно 5.5 человекам. Или тем, кто узнАет, что может использовать.

[@ertaquo]

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

[@spmbt]

На этот счёт тоже есть статистика.
1. 10000 установок собирались в течение года, а за этот год было более 100 версий-билдов. Поэтому каждому постоянному пользователю приходилось раз в 1-3 недели скачивать и ставить заново.
2. Более года счётчик у них был сломан в обратную сторону — считал 1 установку за 2. Так что реальных установок там — тыс. 6. И эта ошибка относится ко всем скриптам того сайта. Месяца 3 назад её починили.
3. Но месяц назад счётчик встал и держится на этой отметке. У других скриптов — то же самое.
4. Относительно числа удаливших — я исследовал этот вопрос. Пока можете принять на веру, но это достоверно: 10% установивших больше скриптом не пользуются; 50% установивших пользуются около часа; примерно 20% установивших пользуются постоянно (неделю и более). Т.е., отвечая на Ваш вопрос — 80% — установили и выкинули. Оценка в 50 человек — это оставшиеся постоянные пользователи. В том смысле, что относительно долго используют, хотя могут выкинуть позже. А 10 тыс. никак не соотносится с реальным количеством пользователей.

[@ArturSitnikoff]

И не жаль вам столько времени тратить на ерунду, которая, как вы сами говорите, ни кому не нужна…

[@spmbt]

Поддержка Iceweasel? Восстановить поддержку Fx3.6 (не до конца) заняло несколько часов и было интересным упражнением. Заодно и настоящий Fx3.6 захвачен. А захотелось сделать, потому что он занимает очень мало памяти ОЗУ по сравнению с установкой Fx20 в Дебиане, может нормально работать в виртуальной машине с 384М ОЗУ. И главное, идёт в стандартной поставке Дебиана до сих пор. Вполне возможно, что будут использовать 0 человек сейчас, но я могу ставить скрипт со стилями на стандартный Дебиан, подгрузив только Greasemonkey 0.8 — это было достаточным основанием, чтобы сделать.

Но правка статей по выделению — это весьма удобная фича, заняла часа 3-4 со всеми режимами использования (через фрейм, в другом окне, в своём окне). Это — действительно, проблема при правках; ускорение работы ощущается с первого раза. Опять же, основная ценность — не экономия десятков минут в будущем (хотя, думаю, и я, и пользователи оценят), а собственное знакомство с технологиями того, как это сделать в браузере.

[@CaptainFlint]

А не планируете сделать изменение внешнего вида хабра в скрипте более настраиваемым, чтобы им могли пользоваться также и те, кому текущий дизайн Хабра нравится больше, чем результат работы HabrAjax'а? Скажем, лично мне очень хотелось бы пользоваться некоторыми из плюшек скрипта, но то, как он корёжит хабр, для меня оказалось совершенно неприемлемым. :-(

[@spmbt]

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

Поэтому улучшение настроек коснётся в первую очередь их понятности, классификации. А также, будет написано, что делает скрипт в разных блоках сайта безусловно, без настроек. Например, так он сейчас меняет шрифт в заголовках аннотаций — шрифты уменьшаются, и это уменьшение неотключаемо. Связано с тем, что ручная настройка пользователем всех стилей создаст много непропорциональностей — огромные заголовки и плотные тексты, например.

Может быть, если бы кто-то сделал клон с использованием фич, но на традиционном дизайне Хабра, то получилось бы как раз то, что Вы хотите.

[@ertaquo]

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

[@akzhan]

Среднее число пользователей скрипта — 40-60 человек.

Соответственно статья на Хабре бессмысленна, есть и иные каналы доставки (обновления, сайт приложения).

[@spmbt]

Смотря для какой цели смотреть. Ведь основная цель — не рассказать о скрипте, который и так многие знают (а 10% активных читателей пытались пробовать, это 200-300 чел.), и обновление увидели вчера по каналам автопроверки. А вот многие ли видели реализацию редактирования статьи описанным способом? Много ли видевших могли попробовать на действующем примере? Описание этого интерфейса и есть основная цель. Статья так и названа: «Редактирование своей статьи на χ·е через выделение цитаты...». К количеству пользователей скрипта это имеет слабое отношение — лишь в том, что проверить в работе могут авторизованные пользователи, могущие редактировать статьи, а это, по оценке — 5.5 человек из нынешних пользователей. (Ну, может 15, точно сказать нельзя. Но не меньше 5.)

[@ZyXI]

Интересно, я не нашёл никаких ссылок на репозиторий какой‐либо DVCS (да и не D тоже). Да и reformal.ru для отслеживания задач выглядит странно (не могу сказать, насколько он хорош или плох, но то, что он не походит на другие bug tracker’ы — это точно. Возможности интеграции с VCS, привязка задач к планируемым версиям, задание срочности, назначение ответственных за реализацию (← только для совместной разработки), присоединение патчей, расширенные возможности форматирования сообщений, по‐видимому, отсутствуют).

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

[@spmbt]

Да, всё верно, но не было ни одного пожелания от разработчика видеть код в репозитории, чтобы участвовать в разработке. Однако, и хостинг юзерскриптов содержит всё для контроля версий. Дублирование где-нибудь ещё создало бы ненужную копию, а сейчас всё просто: актуальная версия — на хостинге скрипта.

Форкание на Гит-хостинг, тем не менее, очень просто: вместо клика по кнопке просто делаете копипейст, а затем сообщаете о пулл-реквесте.

[@ZyXI]

Да, всё верно, но не было ни одного пожелания от разработчика видеть код в репозитории, чтобы участвовать в разработке. Однако, и хостинг юзерскриптов содержит всё для контроля версий. Дублирование где-нибудь ещё создало бы ненужную копию, а сейчас всё просто: актуальная версия — на хостинге скрипта.

Всё? Там только старые версии и diff’ы. Нет объяснений «что изменилось», обычно присутствующих в комментарии к изменениям, нет вспомогательных файлов (вроде README), нет информации об авторах изменений, слишком большая зернистость изменений (обычно в одну новую версию входит несколько новых возможностей и несколько исправлений старых и это отражается в VCS, но никак не в разнице между двумя версиями). Ненужная копия — это файлы на userscripts.

Я с этим работаю просто скриптом (тоже, кстати, вспомогательный файл) — он присваивает изменению метку версии, создаёт версию для распространения, заливает её куда нужно и обновляет все копии README (как пример: aurum — моё дополнение для Vim, — там этих копий 3 (само README делается из первой секции справки, затем обновляется страница на www.vim.org и страница на mercurial.selenic.com/wiki; отдельно обновляется HTML версия справки)). Ненужная копия просто становится производной от нужной и более не требует моего внимания.

Форкание на Гит-хостинг, тем не менее, очень просто: вместо клика по кнопке просто делаете копипейст, а затем сообщаете о пулл-реквесте.

Это «просто» не работает при сколько‐нибудь сложных изменениях: при использовании патчей вы лишаетесь умных алгоритмов слияния и, самое главное, удобных возможностей разрешения конфликтов (точнее, не их самих, а удобных к ним интерфейсов — я не знаю ни одного, который не был бы завязан на какую‐либо VCS). Другие пользователи лишаются удобной возможности вести собственую ветку изменений (впрочем, они могут написать скрипт для импорта версий в git). Я лишаюсь удобной возможности использовать hg pull для обновления (тоже можно написать скрипт, но зачем, если все мои настройки и так под контролем mercurial, который умеет подрепозитории). Конкретно с отказом от bitbucket/github вы ещё и лишаетесь связи кода с bug tracker’ом и возможности получать запросы на слияние в несколько кнопок. Как я понял, под «вместо клика по кнопке просто делаете копипейст, а затем сообщаете о пулл-реквесте» понимается

1. Найти на сайте файл.
2. Скачать его.
3. Сделать изменения.
4. Проверить их.
5. Если в голову пришло более одного варианта реализации, то, долго ругаясь, гулять по дереву изменений. Интерфейс к нему в Vim’е гораздо хуже, чем CLI даже пресловутого git. Или поместить файл сразу под контроль VCS.
6. Если за это время автор обновил скрипт, то, долго ругаясь, найти старую версию, использовать diff, чтобы создать патч, использовать patch, чтобы его применить. Долго придумывать, как при этом поступать с конфликтами (или просто создать ветку в VCS).
7. Найти на сайте контакты автора
8. Отправить ему новую версию.
9. Дальше уже не наши проблемы, но рассматривать такой запрос на слияние мне было бы весьма неудобно при наличии своих собственных изменений.

С mercurial+bitbucket можно забыть про пункты 1 (найти что‐либо надо только один раз), 2 (hg pull — настолько просто, что под него не нужно даже отдельного пукнта), 5 (гораздо проще, чем без VCS), 6 (то же, что и 5; если нет конфликтов, то можно и не заморачиваться, отправляя запрос на слияние так), 7 (выполнено один раз при пункте 1, дальше сохранено в настройках репозитория), 8 (одна кнопка на сайте + немного текста). Помещение страницы в закладки не убирает проблемы с 1: всё ещё нет прямой связи файла на диске и страницы на сайте; да и дополнений, открывающих (aurum: копирующих в буфер обмена) в браузере текущий файл под контролем VCS я знаю как минимум два (aurum (mercurial/git/subversion/(теоретически (= при наличии некоторых настроек в vimrc))bazaar) и fugitive (git)), а для userscripts — 0. В заголовке нужных ссылок не видно. Открытие страницы сильно уменьшает количество телодвижений для создания запроса на слияние; а сам сайт служит в том числе для общения с автором.

Большинство пунктов можно убрать, написав несколько скриптов, но кому охота этим заниматься?

Относительно разработчиков, не запрашивающих VCS: я их отлично понимаю. Куда проще либо пройти мимо, либо ограничиться созданием задачи на reformal.ru, чем убеждать автора использовать VCS. Для многих использование VCS просто самоочевидно и отсутствие репозитория является тревожным сигналом. Чтобы сказать, что VCS не нужно, потому что разработчики не просят, надо знать, почему они не просят и сколько было тех, кто воспользовался первыми двумя вариантами (пройти мимо и ограничиться задачей). Последнее можно прикинуть только добавив репозиторий; я лично могу только сказать, что от наличия репозитория число задействованных разработчиков не уменьшится. Чтобы прогнозировать (не)увеличение я недостаточно знаю.

Только я использую DVCS даже если могу достаточно твёрдо прогнозировать участие только одного разработчика (меня) — bitbucket и mercurial дарят неплохие преимущества и в этом случае.

[@spmbt]

> Там только старые версии и diff’ы. Нет объяснений «что изменилось»,

Я с самого начала установил систему, что в 3-4 строчках метафайла (директивы // @ update и другие в начале юзерскрипта) описаны объяснения, что изменилось. Больше изменений — больше строчек. Причём, с системой контроля версий, встроенной с скрипт там всё достаточно удобно.
1) открываете настройки скрипта;
2) клик по «проверка обновлений» — выводятся апдейты с нового метафайла, если он появился на хостинге. Там же — номер и дата новой версии;
3) если заинтересовало, можете тут же 1 кликом инсталлировать новую версию или по ссылке перейти на дифф.

> нет информации об авторах изменений

В те же @ update вписываются авторы, если бы их было более одного. Но вообще — это продукт одного автора, а он написан в мета-директивах (@ author).

> Ненужная копия — это файлы на userscripts.

Этот сайт — основной канал распространения и поддержки контроля версий скрипта.

Несколько старых фич от 2-3 последних версий тоже держатся в @ update, пока не вытеснятся новыми. Просто загрузите скрипт и посмотрите, как это работает. Для пользователя последние фичи всегда на виду, последние 20-30 дней. И они же складываются в список обновлений на странице скрипта, но немного более подробно (в 1.5 раза больше текста). Посмотрев в любую версию, вы увидите эти последние фичи в данной версии. (Правда, это никогда не нужно.)

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

Если бы я делал аддоны и расширения для 4 основных браузеров, то система сборки понадобилась бы. Но пока что нужды скриптов для сайта полностью обеспечиваются юзерскриптом. Это упрощает ведЕние единой версии вместо 4 разных для браузеров. Хотя там кроссбраузерные и версионные проблемы регулярно появляются.

Далее, о том, что «просто копипейст» не работает. Если бы кто-то когда-то хотел делать форк, мы бы об этом узнали. На самом деле, никого этого до сих пор не интересовало. Только один человек помог сделать стили в формате Less в рамках своей инициативы, но его код ни он, ни кто другой далее не поддерживал (и договорённости не было). Поэтому, зачем изобретать то, что не востребовано?

> при использовании патчей вы лишаетесь умных алгоритмов слияния

diff на 1 файле никто не отменял

> Пункты 1-9
Вообще, Вы как-то очень механистично рассматриваете пулл-реквест. Если второй разработчик не договорился с первым о совместной разработке, то сложности будут обеспечены в любой СКВ.

Вот когда будет востребована работа в команде, тогда я тут же подниму все проблемы структуризации, которые вижу на сейчас, расформируем код, придумаем систему сборки. Но пока что это никому не нужно. (Несмотря на то, что многие жалуются на отсутствие дизайна. Все хотят, чтобы кто-то сделал, и тогда они бы пользоватлись. Но этого «кого-то» как не было, так и нет.) Основная мысль: под несуществующего человека ничего не надо делать.

Для своих других задач я использую Git и Битбакет. Это — многофайловые проекты, в которых имеются наблюдатели, скачивающие проект для своих нужд. Для однофайлового скрипта — не вижу необходимости создавать копию. Сам код скрипта открыт под LGPLv3 — это значит, что если другой разработчик имеет такие же убеждения, как у Вас, то ему даже спрашивать меня не надо — он может самостоятельно скопировать проект в репозиторий и пригласить меня же для продолжения.

> Куда проще либо пройти мимо, либо ограничиться созданием задачи на reformal.ru, чем убеждать автора использовать VCS.

У меня в использовании коллективных VCS большой опыт. Просто не было ни единого разработчика, желавшего участвовать в проекте на JS.

Чтобы сказать, что VCS не нужно, потому что разработчики не просят, надо знать, почему они не просят и сколько было тех, кто воспользовался первыми двумя вариантами

Я могу это оценить: 6-7 дельных предложений через Реформал (скорее, не от разработчиков, а от пользователей). Не просят коллективной разработки — потому что вообще разрабочиков юзерскриптов мало (это можно видеть по количеству активных и старых скриптов на userscripts.org), а более-менее опытный с лёгкостью напишет свой скрипт, чем будет участвовать в другом проекте. Написать скрипт под свои нужды 1 задачи — дело от 30 минут до нескольких часов (пример). Для этого не надо вливаться в чужой проект и даже форкать его.

В общем — спасибо за подробный разбор достоинств СКВ и минусов хостинга на userscripts.org. Тут действительно, много ценных мыслей. Но пока нет человека, сказавшего «Я готов это сделать», об изменениях речи нет — это было в своё время продумано.

[@ZyXI]

1) открываете настройки скрипта;
2) клик по «проверка обновлений» — выводятся апдейты с нового метафайла, если он появился на хостинге. Там же — номер и дата новой версии;
3) если заинтересовало, можете тут же 1 кликом инсталлировать новую версию или по ссылке перейти на дифф.

Это удобно для обычных пользователей, и то когда скриптов мало. Если настройки браузера уже под констролем СКВ, то обновление всего хозяйства силами этой СКВ гораздо удобнее. Впрочем, обновление силами пакетного менеджера обычно ещё удобнее, чем нецелевое использование СКВ. Для userjs я специализированных программ для их обновления не знаю, но не знаю ≠ не существует.

Этот сайт — основной канал распространения и поддержки контроля версий скрипта.

Это не означает, что эта копия нужна. Для того же www.vim.org как‐то пытались написать систему, которая забирает все нужные данные (README и сам исходный код дополнения) прямо из удалённого репозитория безо всяких костылей вроде скрипта, но проект заглох.

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

Скрипт пишется за десяток минут, большая часть которых уходит на освежение в памяти документации по WWW::Mechanize или аналога на вашем любимом ЯП. А один файл на 4000+ строк, да ещё из без проставленных маркеров складок — слишком большой размер для одного файла.

Если бы я делал аддоны и расширения для 4 основных браузеров, то система сборки понадобилась бы. Но пока что нужды скриптов для сайта полностью обеспечиваются юзерскриптом. Это упрощает ведЕние единой версии вместо 4 разных для браузеров. Хотя там кроссбраузерные и версионные проблемы регулярно появляются.

Она и сейчас нужна. Без неё можно обойтись, но … У меня уже есть один проект такого вида (один файл на много‐много строк), так один раз забросив на несколько месяцев разработку я теперь боюсь его трогать; несмотря даже на наличие этих самых маркеров складок и разделение на относительно независимые модули внутри файла.

Далее, о том, что «просто копипейст» не работает. Если бы кто-то когда-то хотел делать форк, мы бы об этом узнали. На самом деле, никого этого до сих пор не интересовало. Только один человек помог сделать стили в формате Less в рамках своей инициативы, но его код ни он, ни кто другой далее не поддерживал (и договорённости не было). Поэтому, зачем изобретать то, что не востребовано?

Ничего бы не узнали. Для того, чтобы сделать форк, нужно чтобы было что форкать. Для того, чтобы было, что форкать, нужно убедить автора воспользоваться DVCS (причём здесь именно D). Убеждать кого‐то сделать то, что нужно тебе, а не ему — занятие неблагодарное, проще пройти мимо.

Я иногда вношу мелкие исправления в различные проекты, но если этого проекта нет на github (где мелкое исправление можно сделать прямо в браузере) или bitbukect, вы моего исправления никогда не увидите — слишком много телодвижений. Немелкие изменения — вопрос отдельный. К счастью, мне ещё не попадалось проектов где большое исправление сопровождалось бы необходимостью работать без VCS.

diff на 1 файле никто не отменял

Конфликты тоже. Слияние в DVCS использует также и информацию об общем предке. А diff’ы — ещё хуже, чем процедура слияния в subversion, до сих пор остающаяся одной из основных претензий к нему.

Вообще, Вы как-то очень механистично рассматриваете пулл-реквест. Если второй разработчик не договорился с первым о совместной разработке, то сложности будут обеспечены в любой СКВ.

Наблюдая и учавствуя в разработке некоторых проектов, в том числе крупных вроде vim практически никогда не видел, чтобы кто‐то о чём‐то договаривался перед созданием запроса на слияние. Изредка запрашивают мнение разработчиков и пользователей о некотором планируемом изменении, ещё реже всё же договариваются: последнее нужно только для крупных изменений. Никаких сложностей — вы просто делаете изменение и запрашиваете слияние. И такое возможно именно благодаря СКВ.

(Впрочем, запросы на слияние в Vim — отдельная головная боль: Bram принимает только патчи. Mercurial только облегчает их создание и ведение своей ветки до принятия патча; а также обновление Vim.)

Для своих других задач я использую Git и Битбакет. Это — многофайловые проекты, в которых имеются наблюдатели, скачивающие проект для своих нужд. Для однофайлового скрипта — не вижу необходимости создавать копию. Сам код скрипта открыт под LGPLv3 — это значит, что если другой разработчик имеет такие же убеждения, как у Вас, то ему даже спрашивать меня не надо — он может самостоятельно скопировать проект в репозиторий и пригласить меня же для продолжения.

Для этого нужно написать скрипт, импортирующий текущую версию в СКВ: потому что пока разработчик создаёт изменение вы запросто можете не раз обновить скрипт на userjs. Или вносить ваши изменения туда самому.

Если разработчик имеет такие же убеждения, как у меня, то он в первую очередь постарается обойтись тем, что есть (я имею ввиду, не писать патч вообще). Во вторую — написать отдельный userjs или же дополнение (как раз вариант, о котором вы написали ниже). В третью — попробовать обойтись без DVCS вообще или только локальным репозиторием. В четвёртую — убедить автора, что ему нужна DVCS. И только потом, при получении ответа выше, создавать свой репозиторий.

Я могу это оценить: 6-7 дельных предложений через Реформал (скорее, не от разработчиков, а от пользователей). Не просят коллективной разработки — потому что вообще разрабочиков юзерскриптов мало (это можно видеть по количеству активных и старых скриптов на userscripts.org), а более-менее опытный с лёгкостью напишет свой скрипт, чем будет участвовать в другом проекте. Написать скрипт под свои нужды 1 задачи — дело от 30 минут до нескольких часов (пример). Для этого не надо вливаться в чужой проект и даже форкать его.

Насчёт ситуации с разработчиками userjs я не в курсе. Боюсь, до повсеместного распространения pathogen и Vundle то же самое было и с дополнениями к Vim. (После старо проще использовать репозиторий на github, что не увеличило количество разработчиков, но создало дополнительные причины использовать git+github, причём именно их.)

[@spmbt]

Неудобство разобранного на части файла ещё вот в чём. Если из-за изменений сайта возникает ошибка, то найти источник ошибки проще через браузер в собранном файле. Разобранный на части проект необходимо собирать, чтобы запустить его в виде юзерскрипта (в отличие от запуска в виде аддона/расширения). Поэтому и отладка скриптов в разобранном на части проекте — сложнее, чем в едином файле.

Решение могло бы быть в отладке в искусственном проекте в формате настоящих скриптов, подмешанных в макет сайта. От этого немного изменятся свойства скриптов и макет будет вести себя иначе, чем юзерскрипт (в частности, приоритетность стилей). Но отлаживать модифицированный проект гораздо проще. Но таких официальных систем нет — никто не рекомендует отлаживать в таком формате. Наоборот, с запозданием, но подгоняют средстьва отладки браузеров для поддержки отладки юзерскриптов и расширений (не во всём успешно, есть ошибки, не отлавливаемые отладчиками). Итого, проще юзерскрипт отлаживать в готовом виде, даже если он в большом файле. Как вариант, можно сам скрипт разбить на модули, изменитв архитектуру решения, превратив в несколько функциональных блоков со слабой связью. До Fx6 это хуже поддержано на уровне пользовательских событий.

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

Аналогом можно считать вот это моё восстановление поддержки Firefox 3.6 и Iceweasel. Я уже подзабыл, что не работает в 3.6 и какие совместимые коды приходилось писать. Однако, при отладке в браузере относительно легко ищется, что не работает. Если бы проект был разобран на файлы, это бы не помогло в отладке таких случаев.

Сборка проекта полезна, если он обфусцируется или сжимается для каких-то целей. Но в этом случае наличие сборщика не упростило бы работу с проектом. Итого, проект в VCS представлял бы собой тот же 1 файл + ещё вспомогательные для сборки и сопровождения и ухудшил бы порог вхождения потенциального участника.

Насчёт ситуации с разработчиками userjs я не в курсе.

А я общался с некоторыми по другим скриптам и наблюдал историю правок юзерскриптов, в том числе на Гитхабе. Везде разработчикам удобнее находиться в рамках своей системы, внутри своего скрипта. Даже когда я достигал совместимости своих скриптов с другими, ответных действий других разработчиков можно было не дождаться. Как кому удобно, тот так и делает. Это следствие неразвитости культуры совместных разработок, конечно.

Для этого нужно написать скрипт, импортирующий текущую версию в СКВ: потому что пока разработчик создаёт изменение вы запросто можете не раз обновить скрипт на userjs. Или вносить ваши изменения туда самому.

Такой ситуации совместной разработки попросту не возникает. Например, года 2 назад был проект, похожий на мой в плане сбора многих фич в юзерскрипте, и, насколько помню, только под Хром. Он пожил месяцев 5, а до этого разработчик патчил его на Гитхабе довольно часто раз 3-7 дней. Была у меня мысль включиться? Нет, потому что мне нужен был кроссбраузерный скрипт, потому что у того разработчика была своя система разработки. Так примерно и сейчас. Даже если кто-то посмотрит на мой код, не захочет участвовать. А новых скриптов на userscript.org появляется мало.

Я постепенно упрощаю структуру проекта — вот это может быть полезнее для потенциального подключения разработчиков, да и то мало реально.

Наблюдая и учавствуя в разработке некоторых проектов, в том числе крупных вроде vim практически никогда не видел, чтобы кто‐то о чём‐то договаривался перед созданием запроса на слияние. Изредка запрашивают мнение разработчиков и пользователей о некотором планируемом изменении, ещё реже всё же договариваются: последнее нужно только для крупных изменений. Никаких сложностей — вы просто делаете изменение и запрашиваете слияние. И такое возможно именно благодаря СКВ.

Я бы тоже не договаривался. Но вот что получается. Изменил я кое что в d3.js. Захотел сделать пулл-реквест. Склонировал я там d3.js, в Гитхабе. А он там, оказывается разобранный. Для проектирования, может быть, хорошо. Но нигде не написано, что за сборщик используется и как с проектом работать. Работать с репозиторием оказалось затрууднительно, нужно спрашивать разработчика или догадываться самому.

По мере приведения структуры проекта в порядок это можно попробовать. Даже сейчас скрипт наполовину упорядочен. Но в том историческом виде, что был — это было бы бесполезно. Всё равно, скрипт будет без сборки на данном этапе, разве что была бы польза от сборки и упаковки стилей (ZenComment), которая сейчас делается периодически вручную.

А что значит сборщик? Это grunt.js удобнее всего + nodeJS (у себя) для него. Сразу — увеличенный порог вхождения для стороннего разработчика.

[@ZyXI]

Сборка проекта полезна, если он обфусцируется или сжимается для каких-то целей. Но в этом случае наличие сборщика не упростило бы работу с проектом. Итого, проект в VCS представлял бы собой тот же 1 файл + ещё вспомогательные для сборки и сопровождения и ухудшил бы порог вхождения потенциального участника.

Вообще‐то изначальным предложением было использование «сборщика» только для копирования скрипта на userjs.org. Предложение разбить на файлы появилось после того, как я узнал размер. Обфускация, конечно, увеличила бы порог вхождения, но наличие репозитория — нет.

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

1. Возможности проводить автоматическое тестирование перед push’ем (невозможность чего в git попутно является одной из основных претензий к нему), фиксацией изменений или любым (mercurial, в git набор hook’ов меньше) другим вашим действием.
2. Возможность узнать, что изменилось с последнего релиза. Комментарии в файле — это хорошо, пока вы не забываете их делать. Забыть написать комментарий к изменению затруднительно, а намеренно делать их невразумительными я просто не буду.
3. «Бесплатное» получение двух лишних резервных копий (на удалённом сервере и в .hg).
4. Устойчивость к ошибкам и лёгкость восстановления из ситуаций вроде «я там случайно что‐то удалил». Правда «… случайно …» мне ещё не пригождалось, а «… намеренно …» — не раз.
5. Лёгкость обновления на других компьютерах. Кстати, а для userjs разве нет какой‐нибудь программы для автоматизации сего действия?

Отдельно bug tracker bitbucket используется в качестве продвинутого TODO.

UserJS я, правда, не пишу. Но пунктов 3, 4 и 5 оказалось достаточно, чтобы я помещал в репозиторий всё, чем я планирую длительно пользоваться. В частности, настройки, включая /etc; причём настройки все в закрытых репозиториях. Мелкие скрипты, старые userJS (новые, как я сказал, я не пишу) там же.

/etc+mercurial, кстати, имеет один несомненный плюс — у меня есть ветка с настройками /etc по‐умолчанию, обновляющаяся полуавтоматически при обновлении пакетов, ветка с собственными настройками и возможность использования mercurial для того, чтобы emerge не беспокоил меня конфликтами на пустом месте. Надо об этом как‐нибудь написать статью.

Я постепенно упрощаю структуру проекта — вот это может быть полезнее для потенциального подключения разработчиков, да и то мало реально.

Это прежде всего полезно для вас самих. Если бы я завершил refactoring того проекта с файлом на много‐много строк я бы не так опасался его трогать, хотя он всё также остался бы одним файлом с кодом.

Я бы тоже не договаривался. Но вот что получается. Изменил я кое что в d3.js. Захотел сделать пулл-реквест. Склонировал я там d3.js, в Гитхабе. А он там, оказывается разобранный. Для проектирования, может быть, хорошо. Но нигде не написано, что за сборщик используется и как с проектом работать. Работать с репозиторием оказалось затрууднительно, нужно спрашивать разработчика или догадываться самому.

Здесь не договариваться нужно. Это типичный проект на одного разработчика (или небольшую команду фиксированного состава), здесь нужны README (и, возможно, CONTRIBUTING) в корне с описанием того, как произвести сборку (во втором файле — что ещё надо знать другому разработчику). В таком случае логично спросить, написать README и отправить PR с ним. Но «спросить, как осуществляется сборка» и «договориться о том, что вы внесёте некоторые изменения» — это разные вещи.

<hr />

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

Спасибо за объяснение ситуации с userjs; я не думал, что всё так плохо.

[@spmbt]

> Лёгкость обновления на других компьютерах. Кстати, а для userjs разве нет какой‐нибудь программы для автоматизации сего действия?
Есть режим автообновления или ручного обновления в Fx, Кнопка «Обновить расширения» в Хроме — с этим довольно всё в порядке.

В случае с юзерскриптом на хостинге у меня получается попроще, без автотестирования. Но все версии хранятся на хостинге как «бесплатная» копия кроме копии на своём компьютере. Есть и диффы, но проще пользоваться диффом (Winmerge) иногда на своём компе. А для пользователей есть система проверки обновлений (в том числе авто — открываешь страницу, а скрипт написал, что нового на хостинге) и сообщений о содержании новых версий. Конечно, полезна и лёгкость обновления в других браузерах и на компьютерах, хотя чаще я обновляю копированием файла.