I do agree on discussing issues specific to each sub-package in its own repository (with separate subscriptions), and using milestones moderately, so that we do not end with too many cross-references. Lately, It has been difficult to keep track of what was concerning the packages I’m working on, for instance, or in substance, where Whonix was heading to.
Some issues like Whonix usability vs security and the way to achieve the best compromise (implement options, help…) could have their own tickets, or be moved to the forum.
Cross-repository milestones are not supported currently, but we're already discussing that ability/possibility internally. It might be something we enable in the future, but I can't make any promises about that. Thanks for expressing interest in this, though -- I'll let the team know.
The Tor Project also uses trac. Looks like it has all features one requires. It’s not that bad. It comes with its own wiki and wiki markup, that I don’t like. I’d stick with mediawiki and use trac wiki only for trac roadmaps. I worry about about the added workload to keep trac up to date on whonix.org, but perhaps it’s not a big deal.
But if there is a more usable bug tracking system, I’d be open for that as well.
What’s the most usable, most awesome bug tracker you’ve seen and used in third party projects?
A place to discuss big picture issues? (At first we were unsure whether or not github or the dev forum was the best place, but maybe we should say "github only for the specific coding ToDos; dev forum for “how best to implement” and “community input needed”)
It doesn’t have to link to specific repositories. Devs would have to figure out that the whonixcheck trac component is related to https://github.com/Whonix/whonixcheck. Although that would be a nice feature.
A place where all sorts of ideas can be tracked. Specific todo’s for implementation. Realistic or not. If you want so, also research tasks that would if someone would work on them result in more tickets.
The forum could still be used for wider community input (similar to the tor-talk mailing list - just much more user friendly interface) and general direction discussions.
Not sure if github issues would still make sense then. Perhaps for minor pull requests or for redirecting users to trac.
I think trac can cope up much better with the flood of suggestions. For stuff a doocrat or (potential) sponsor is interested in, a keyword could be added to keep track of them. (And these keywords can be easily turned into lists of tickets that match the keyword, ex SponsorJ · Wiki · Legacy / Trac · GitLab)
Probably a similar rule as The Tor Project is using would make sense: only doocrats may change keywords [except maybe for very general keywords such as security or usability].
There are some “web 2.0” style programmer groupware products out there. I was impressed by: http://phabricator.org/
It’s ready for production. It’s in heavy development (I assume) with many features on the roadmap.
I worry that these “all-in-one” groupware products are overkill, but it might turn out that we love kanban boards (or whatever)! Another worry is that it does lots of things well enough, but trac does bug tracking perfectly. I don’t know.
The only way to know is to try them out. I suggest that we start with the easier-to-install one first
[quote=“JasonJAyalaP, post:10, topic:612”]There are some “web 2.0” style programmer groupware products out there. I was impressed by: http://phabricator.org/[/quote]
[quote=“Patrick, post:11, topic:612”]Looks also nice.
Apparently only projects can be tagged. Not individual tickets. So having a tag “easy” for new contributors or tag “usability” is not so intuitive. But one could create a tag or project “easy”. Because a ticket can be assigned to multiple projects, which is quite nice.
I had a look at Phabricator. As a developer-noob I might be using improper terminology in the following, or might just not have sufficiently familiarized myself with Phabricator, so set me right if either of those possibilities is the case.
It seems to be a developer-facing app, rather than a user-facing app. That is, what constitutes a “task” is what the developers decide is something to do. Before they decide, the thing is either a bug or a wished-for feature. After they decide it will be worked on, it’s all one thing: a task.
That distinction was brought home to me recently when I went to the bug-tracking site of a popular software package and logged what I thought was a bug. It was explained to me that it was actually the geekish way the software is supposed to work (using geek logic rather than human logic) and therefore not a bug, and the bug entry was therefore marked as closed. I considered arguing that the software’s behaviour was a desirable thing to change, but thought better of it, because, after all, I was on a bug-tracking site and my comment would be inappropriate in that context. It would probably be recommended that I state my case on a forum on another site where they have a subsection for feature requests. But the developers might not bother to ever look there. Hmmm.
So, what I would like to see is a tracking system that neatly keeps bugs and feature requests separate, but in which an entry can be conveniently moved from one category to the other. Can Phabricator do that, or am I overlooking the obvious?
