Лучшие практики для установки и управления проектом с открытым исходным кодом
Позже в этом году я хочу выпустить платформу PHP, что я продолжал работать как открытый исходный код. Я действительно использую управление исходным кодом (SVN), но это находится на чрезвычайно ограниченной основе. Я выучился самостоятельно, я разрабатываю один и не имею опыта работы с многочисленными командами. У меня есть некоторые идеи о том, что может помочь сделать проект успешным, но я нечеток в некоторых деталях. Так как это еще не выпущено, я хочу сделать все, что я могу для установки правильной инфраструктуры с начала. Что я должен знать, чтобы установить и управлять успешным проектом?
Некоторые идеи, что я должен сделать это успешным (вне маркетинга его):
- Хорошая документация и учебные руководства
- Автоматизированные модульные тесты и сборки для продвижения обновления веб-сайта
- Четкая дорожная карта
- Отслеживание ошибок интегрируется с управлением исходным кодом
- Руководство по стилю для хранения кода последовательным
- Форум для сообщества для получения поддержки совместно используйте идеи и т.д.
- Хороший пример приложения создается с платформой
- Блог для информирования сообщества
- Поддержание назад совместимости по мере возможности
Некоторые мои вопросы:
- Как я устанавливаю и автоматизирую один шаг submit-test-commit-generate обновление нажатия документов API процесса веб-сайта?Править: Муравей или Знаток были бы хорошими кандидатами на это? Если так, Вы знаете о каких-либо ресурсах для установки проекта PHP с помощью них?
- Как я обрабатываю (технически) представления от других пользователей? Как я могу удостовериться, чтобы те представления были утверждены прежде чем быть интегрированным?
- Что такое некоторые ловушки, которых можно избежать с точки зрения сообщества проекта? Я предпочел бы иметь его, являются максимально дружественными и полезными без большого количества драмы.
Я хотел бы учиться на Вашем опыте в любой из этих точек. Если Вы думаете, что я пропускаю что-либо большое, совместно используйте это также. Любые ресурсы (предпочтительно приспособленный к новичку), что Вы могли указать на меня к, будут также значительно цениться.
8 ответов
Я только начинаю работать над проектами сообщества, но дам вам несколько советов по что я знаю.
Как мне настроить и автоматизировать одноэтапный процесс отправки-тестирования-фиксации-генерации API docs-push-обновления для веб-сайта?
Я никогда не реализовывал его как один процесс. Вы можете просто иметь контрольный список и, возможно, даже создать несколько сценариев для выполнения определенных задач. Я никогда не работал с системой управления версиями, которая автоматизирует загрузку и делает это с помощью сценария. В большинстве случаев необходимо участие в каком-то веб-взаимодействии.
Вы не хотите продвигать изменения API до официального выпуска.
РЕДАКТИРОВАТЬ: Рабочая среда
Для PHP большую часть времени я либо редактирую прямо на сервере, либо тестирую его там, используя beta.example.com или аналогичный, прежде чем нажимать example.com. Вы также можете настроить веб-среду на своем домашнем ПК (используя XAMPP для Windows или стандартную установку LAMP в Linux). Вы, вероятно, просто использовали бы здесь зеркало своего репозитория, так что вы бы сделали svn commit , или в зависимости от того, что подходит для выбранной вами VCS или DVCS.
Самое интересное - протестировать это на разных версиях PHP. Я сам этого не делал, но вы, вероятно, могли бы использовать файл .htaccess для запуска другого двоичного файла PHP, чтобы проверить его. Я не совсем уверен, какой вариант для этого лучше всего.
Я не особо много работал с API, так как никогда не создавал библиотек, но просто выполнив быстрый поиск, я нашел http://www.phpdoc.org/ . Это похоже на зрелый проект, так что это может быть отправной точкой.
Что касается создания выпусков, я обычно создаю сценарий, который включает только те файлы, которые являются частью дистрибутива (он будет отфильтровывать любые файлы VCS и все, что вам не нужно в распространяемом файле). Вы можете написать сценарий для find в linux (что я делаю большую часть времени), или могут быть другие лучшие варианты.
Как мне обрабатывать (технически) материалы, отправленные другими пользователями? Как я могу гарантировать, что эти материалы должны быть одобрены перед интеграцией?
Это в основном обрабатывается системой отслеживания ошибок и ограниченным доступом в Системе контроля версий. Обычно вы и люди, которым вы разрешаете, можете принять участие в VCS. Другие пользователи могут отправлять исправления, но затем вы можете попросить кого-нибудь просмотреть исправление, протестировать исправление и зафиксировать. Вы можете разделить эти задачи на одну команду или назначить патч одному человеку, и они все сделают.
Каких подводных камней можно избежать с точки зрения проектного сообщества? Я бы предпочел, чтобы он был максимально дружелюбным и полезным, но без драматизма.
Я просто постараюсь сохранить как можно более позитивный настрой среди участников проекта и сообщества. Будут некоторые разногласия, и это оттолкнет некоторых людей, но пока у вас есть стабильный продукт, отвечающий потребностям большинства людей, я думаю, это все, чего можно ожидать.
Одно второстепенное предложение, которое сработало для меня: начните использовать местоимения первого лица множественного числа , а не единственного числа. То есть говорите о «мы» и «нас», а не о «я» и «меня». Это побуждает других людей участвовать, когда они чувствуют себя частью команды, а не когда они чувствуют, что вносят свой вклад в ваше собственное самовозвеличивание.
Я хотел бы добавить, что вы должны максимально упростить для ваших пользователей запуск всего этого и изменить код - эти "возможности пользователей можно «превратить» в разработчиков или, по крайней мере, в людей, которые присылают небольшие патчи.
Не пытайтесь делать все самостоятельно - для проектов с открытым исходным кодом есть несколько хостинг-провайдеров, которые решают большинство проблем. Я рекомендую codeplex или код Google.
Настройка сценариев сборки будет в определенной степени зависеть от того, какую платформу вы настраиваете, но в целом легко добавить в сценарий любой инструмент, который вы хотите, после того, как вы начнете использовать любой тип сценария сборки.
Если вам действительно нужен описанный вами одноэтапный процесс, вам понадобится сервер сборки. Я использую TeamCity, который я настроил для отслеживания любых изменений в svn и запуска сборки / тестирования всякий раз, когда что-то регистрируется. Сервер сборки обычно может выполнять любые шаги, которые вы вводите в сценарий сборки.
Прочтите Git как альтернативу бесплатному общедоступному репозиторию / системе отслеживания ошибок / вики / сообществу с поддержкой вилки SVN
- в Github (на котором, среди прочего, размещены symfony и PHPUnit )
- « Как мне обрабатывать (технически) материалы, отправленные другими пользователями? Как я могу убедиться, что эти материалы должны быть одобрены перед интеграцией? "- с помощью Git извлеките из основной ветки то, что вы / ваша ближайшая команда сочтете наиболее интересным.
Согласованный API
- вдохновитесь другим общедоступным API: s
- только изменения в основных версиях
- предположительно
Интересно как для пользователей, так и для разработчиков
- четкая цель (ваша дорожная карта - отлично)
- полезно, в отличие от всего остального
- легко использовать, но все же не достаточно легко писать / поддерживать самостоятельно
Вы можете использовать Ant или Phing для создания своего проекта. Включите в сборку CodeSniffer , и вы сэкономите время, проверяя основные ошибки / различия форматирования.
Это все технические советы, касающиеся мягкой части ...относиться к людям с уважением, проявлять большой интерес и быть чрезмерно взволнованными их вкладом и дать им почувствовать, что они не зря тратят свое время. Мне это понравится.
У вас есть отличный набор идей для начала. Возможно, вам придется начать с их обрезки! Спросите себя, что нужно для первого выпуска.
Для автоматизации сборки и тестирования сценарий может быть выполнен с помощью ant, maven или phing для проектов PHP.
Возможно, вам понадобится хост, чтобы вы могли продемонстрировать продукт. Для PHP это довольно легко найти.
Вам нужен хостинг-провайдер с открытым исходным кодом - особенно github (но также код Google, подделка исходного кода и т. Д.). Github предоставляет отслеживание ошибок, лицензии по умолчанию, блог и отличные механизмы для принятия изменений от сообщества. Построенный на основе git, он довольно хорошо упрощает распределенные проекты.
Хотя хорошо иметь одноэтапную сборку и установку на месте, автоматизация интеграции других изменений, вероятно, не важна (или нежелательна) с места в карьер.
Удачи!
Самое важное, что вам нужно сделать, - это привлечь пользователей. Без пользователей вы не получите никаких взносов и разработчиков, которые вам помогут. Потому что разработчики в первую очередь являются пользователями, а затем они решают расширить / исправить то, что используют, и могут стать участниками.
Таким образом, чтобы привлечь пользователей, вы должны рассмотреть
- описание того, что ваша структура делает в одном или двух предложениях в верхней части страницы вашего проекта
- упомянуть, как ваша структура может быть использована и для каких, каких ситуаций она наиболее пригодна. полезно для
- добавить много примеров того, как его использовать
- указать, является ли ваш фреймворк стабильным, бета или альфа. Это важно, потому что пользователь должен знать, что перед тем, как начать его использовать
- , также укажите, хотите ли вы продолжать улучшать его и продолжать работать над ним - большинство пользователей не хотят использовать заброшенный фреймворк (также имейте в виду, что Многие пользователи проверяют ваши коммиты, чтобы увидеть, действительно ли вы над этим работаете - если ваша последняя фиксация в репозитории была несколько месяцев назад, значит, вы на самом деле не работаете над этим, поэтому мошенничество невозможно)
Если у вас есть все это, и люди начинают отправлять исправления, вы можете использовать инструмент исправления, чтобы применить их к своему источнику.В зависимости от вашей системы управления версиями вы можете использовать патч GNU, инструмент сравнения / исправления, который поставляется с вашим контролем версий, или, возможно, даже инструмент с графическим интерфейсом, который поможет вам в этом. У SVN нет инструмента исправления (пока), но 'svn diff' создаст файл исправления, который затем можно применить с помощью инструмента исправления GNU, или, если вы используете TortoiseSVN, перетащите файл исправления правой кнопкой мыши в вашу рабочую копию и пусть TortoiseMerge применит его за вас.
И о том, как лучше всего общаться с сообществом:
- отвечайте на вопросы вовремя, не ждите более двух или трех дней, чтобы ответить на вопросы
- старайтесь вести себя хорошо, даже с расстроенными и рассерженными людьми. Только если они будут беспокоиться, посоветуйте им (по возможности, по-прежнему в хорошей форме) уйти в другое место
- , всегда оставляйте обсуждения проекта в списке рассылки. Вы не хотите повторять одни и те же обсуждения снова и снова - если у вас есть список рассылки, просто укажите пользователям архивы, прежде чем обсуждение начнется снова.
И вы должны посмотреть доклад » How Open Source Projects Survive Poisonous People (And You Can Too) »- это действительно хорошо и многое расскажет вам о том, как бороться не только с« ядовитыми людьми », но и со всеми людьми, вовлеченными в ваш проект.
Посмотрите книгу Карла Фогеля о производстве программного обеспечения с открытым исходным кодом. В ней, вероятно, есть все, о чем вы спрашивали.
Вам также следует составить план по привлечению сообщества. Я бы рекомендовал прочитать книгу Джоно Бэкона "Искусство сообщества" [http://www.artofcommunityonline.org/]].