Рекомендации по установке и управлению проектом с открытым исходным кодом

Ответ 1

Я только начинаю в проектах сообщества, но я дам вам несколько советов по тому, что знаю.

Как настроить и автоматизировать один шаг submit-test-commit-generate API docs-push update для веб-сайта?

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

Вы не хотите изменять API до официального выпуска.

РЕДАКТИРОВАТЬ: Рабочая среда

Для PHP, в большинстве случаев, я либо редактирую непосредственно на сервере, либо тестирую его там, используя beta.example.com или аналогичный, прежде чем нажимать на example.com. Вы также можете настроить веб-среду на своем домашнем ПК (используя XAMPP для Windows или стандартную установку LAMP в Linux). Вы, вероятно, просто используете зеркало вашего репозитория здесь, так что вы бы сделали svn commit или в зависимости от того, что подходит для VCS или DVCS, которые вы выберете.

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

Я много не делал с API, так как я никогда не создавал библиотеку, но просто выполнял быстрый поиск, я нашел http://www.phpdoc.org/. Это похоже на зрелый проект, поэтому это может быть отправной точкой.

Что касается создания релизов, я обычно создаю script, который включает только файлы, которые являются частью дистрибутива (он будет отфильтровывать любые файлы VCS и все, что вы не хотите в распределенном файле), Вы можете написать script вокруг find в linux (это то, что я делаю большую часть времени), или могут быть другие лучшие варианты.

Как обрабатывать (технически) представления от других пользователей? Как я могу гарантировать, что эти материалы должны быть одобрены до их интеграции?

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

Каковы некоторые подводные камни, которых можно избежать с точки зрения сообщества проекта? Я бы предпочел, чтобы он был как можно более дружелюбным и полезным, без большой драмы.

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

Ответ 2

Одно небольшое предложение, которое хорошо сработало для меня: начните использовать множественные местоимения от первого лица, а не особые. То есть говорить о "мы" и "нас", а не "я" и "я". Он поощряет других людей участвовать, когда они чувствуют себя частью команды, а не когда они чувствуют, что они вносят свой вклад в самовозвеличивание.

Ответ 3

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

Итак, чтобы получить пользователей, вы должны рассмотреть

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

Если у вас есть все это, и люди начинают отправлять исправления, вы можете использовать инструмент патча, чтобы применить их к своему источнику. В зависимости от вашей системы управления версиями вы можете использовать патч GNU, инструмент diff/patch, который поставляется с вашим контролем версий или, возможно, даже инструментом GUI, который поможет вам в этом. У SVN нет инструмента патча (пока), но 'svn diff' создаст файл патча, который вы затем можете применить с помощью инструмента исправления GNU, или, если вы используете TortoiseSVN, перетащите файл патча в рабочую копию и TortoiseMerge применит его для вас.

И о том, как лучше всего общаться с сообществом:

• ответьте на вопросы вовремя, не ждите более двух-трех дней, чтобы ответить на вопросы.
• старайтесь быть хорошими, даже с расстроенными и злыми людьми. Только если они продолжают беспокоиться, скажите им (по-прежнему, если это возможно), в другом месте.
• всегда следует обсуждать проект в списке рассылки. Вы не хотите повторять одни и те же обсуждения снова и снова - если у вас есть список рассылки, просто укажите пользователей в архивы, прежде чем обсуждение начнется снова и снова.

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

Ответ 4

Я хотел бы добавить, что вы должны сделать так просто, насколько это возможно для ваших пользователей, чтобы все это запустило и изменило код - эти "опытные пользователи" могут быть "преобразованы" в разработчиков или, по крайней мере, тех, кто отправляет более мелкие заплаты.

Ответ 5

Не пытайтесь делать все сами - для проектов с открытым исходным кодом существует несколько хостинг-провайдеров, которые решают большинство проблем. Я рекомендую код или код Google.

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

Если вам действительно нужен описанный один шаг, вам нужен сервер сборки. Я использую TeamCity, который я настроил, чтобы следить за любыми изменениями в svn и trigger build/test всякий раз, когда что-то проверяется. Сервер сборки, как правило, может выполнять любые шаги, которые вы ввели в сборку script.

Ответ 6

Прочитайте Git в качестве альтернативы SVN

• бесплатный общедоступный репозиторий/ошибка-трекер/wiki/fork-enabled community в Github (в котором размещаются symfony и PHPUnit среди других)
• "Как я могу обрабатывать (технически) представления от других пользователей? Как я могу гарантировать, что эти материалы должны быть одобрены до их интеграции?" - с помощью Git вытащите то, что вы/ваша ближайшая команда найдете наиболее интересным для основной ветки.

Согласованный API

• быть вдохновленным другим публичным API: s
• изменение только в основных версиях
• угадываемы

Интересно как для пользователей, так и для разработчиков

• Четкая цель (ваша дорожная карта - отлично)
• полезно, все остальное доступно
• прост в использовании, но все же нелегко - достаточно писать/поддерживать себя

Вы можете проверить либо Ant, либо Phing для создания своего проекта. Включите CodeSniffer в сборку, и вы сэкономите время на проверку основных ошибок/отличий в форматировании.

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

Ответ 7

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

Вы также должны планировать участие сообщества. Я бы рекомендовал прочитать Jono Bacon The Art of Community [http://www.artofcommunityonline.org/].

Ответ 8

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

• Для автоматизации построения и тестов скрипты можно выполнить с помощью ant, maven или phing для PHP проекты.

• Вам, вероятно, понадобится хост, чтобы вы могли демонтировать продукт. Для PHP это довольно легко найти.

• Вам нужен провайдер хостинга с открытым исходным кодом - особенно github (но также код google, исходная кузница и т.д.)., Github обеспечивает отслеживание ошибок, лицензии по умолчанию, блог и отличные механизмы для принятия изменений в сообществе. Построенный на git, он облегчает распределенные проекты.

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

Удачи!