2013-09-25 3 views
0

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

Таким образом, кто-нибудь знает о трещинах проблем, которые позволяют некоторым проблемам, таким как запросы функций, быть закрытыми, в то время как остальные общественности? Я сам изучил это сам, но лучший подход, который я придумал, состоит в том, что у меня две отдельные системы - публичные и частные - которые я вручную синхронизирую (т.е. публичных проблем -> частный вопрос трекер) - подход, описанный GitHub here , Неужели должно быть что-то умнее этого?

+0

У вас есть бюджет? –

+0

У меня возникли проблемы с согласованием «Открытого источника» и «Частных запросов функций». Контекст изменений кода должен оставаться закрытым, но реальный результат/функциональность могут быть доступны миру? – MattC

+0

@EduardLuca Да, бюджет существует, если существует подходящий инструмент – stephenfin

ответ

1
  • Assembla (с парой «Билеты» и «Поддержка» инструментов)
  • Mantis с
    • общественных/частных проектов - Общественный проект, доступный всем пользователям, частным доступны только для тех, кто явно добавил.
    • Публичные/частные заметки - частные заметки доступны для пользователей с определенным уровнем доступа к соответствующему проекту.
    • Публичные/частные проблемы. Частные проблемы доступны для пользователей с определенным уровнем доступа к соответствующему проекту.
+0

Mantis выглядит интересно. Основная проблема заключается в том, можно ли установить флаг public/private * для каждой проблемы *, а не * для каждого проекта * (в идеале разные подмножества проблем будут видны для разных пользователей в зависимости от уровней доступа). Я буду исследовать. – stephenfin

+1

@stephenfin - да, он может.Но не публичный/частный как таковой, а «видимый для которых ** группы пользователей **» AFAICR (работал с Mantis давным-давно) –

+0

Оказывается, когда вы ищете «группы» WRT-трекеров, вы найдете много продуктов с поддержкой. Bugzilla, например http://www.bugzilla.org/docs/tip/en/html/groups.html. Это, безусловно, правильный подход. Благодаря! – stephenfin

1

Если вы работаете над проектом с открытым исходным кодом, вы можете просто qualify для бесплатной подписки JIRA.

С JIRA у вас также может быть неограниченный Anonymous пользователей (только зрители).

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

+0

Jira также поддерживает группы (https://confluence.atlassian.com/display/JIRA/Managing+Groups), что означает, что этот ответ также верен. Увы, я могу только назначить один :(Спасибо, тем не менее – stephenfin

+0

Не беспокойтесь, я не делаю этого для репутации. Если это помогло вам или будущему посетителю, это мне достаточно! –

Смежные вопросы