Splitting Whonix/Whonix bug tracker

I think https://github.com/Whonix/Whonix/issues is just getting too crowded. We can’t discuss a whole distro in one tracker.

Just heard from someone who unsubscribed due to the flood of unrelated discussion.

What about discussing specific issues in the sub packages? Such as discussing whonixcheck stuff in https://github.com/Whonix/whonixcheck and so forth?

I guess cross repo mile stones and discussion will be more difficult. Dunno. But overall I think splitting sooner or later is inevitable.

What do you think?

Asked github support.

Can I have an issue from one repository, for example https://github.com/Whonix/uwt/issues/1

add to a milestone in another repository, for example


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.

[quote=“Patrick, post:2, topic:612”]Asked github support.

[quote]Can I have an issue from one repository, for example

add to a milestone in another repository, for example


Their answer:

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.

Not having a cross repo roadmap however is almost a deal breaker. Without it the tracker would not be useful for myself.

Now using the wiki for various roadmaps:

But I don’t think it is very practical.

Alternatively we could also consider installing bug web software on whonix.org. Suggestions welcome.

Using the wiki would be really impractical. I just had a quick look at issues/bugs tracking systems. May be something like http://trac.edgewall.org.

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?

Let’s clarify our needs:

A roadmap that links to the repos?

A bug tracker that links to multiple repos?

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.

Similar to:

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 https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorJ#Projecttickets.)

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:

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 :slight_smile:

Looks also nice.

Does it support tags and roadmaps?

There is an online demo:

Looking at the moment how to add tags to tickets.

Another contender (web 2.0-ish; self- or fully-hosted; libre; free):


I’m not partial to one over another, but I will be happy to install one when we come to a consensus.

[quote=“JasonJAyalaP, post:10, topic:612”]There are some “web 2.0” style programmer groupware products out there. I was impressed by:

[quote=“Patrick, post:11, topic:612”]Looks also nice.

Does it support tags and roadmaps?

There is an online demo:

Looking at the moment how to add tags to tickets.[/quote]
It does support (hash) tags apparently:

Supports projects:

In #phabricator on irc.freenode.net they told me, that https://showoff.phab.io runs a very old version, has no friendly relation to upstream.

https://phab-01.wmflabs.org is an alternative demo platform.

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.

They use tags to create milestones:

When phabricator works for mediawiki development and other big ones, I guess it should work for us as well.

Let’s lets go with phabricator.

@fortasse: Could you install it please?

It’s alive!


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?

I don’t think so. Adding all such tasks to a “bug” or “feature request” project is probably most you can do.

Perhaps look through more crowded installations of phabricator than the whonix one such as the phabricator’s own or or mediawiki’s one.

Consider joining irc.freenode.net #phabricator and/or to use their bug tracker to ask questions / leave feedback. Devs are active and helpful there.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]