Skip to content

Confidential issues in private repositories

Thanks for giving us private issues.

However, it seems that in the implementation there happened some over-engineering, namely:

It is impossible to tag an issue as confidential if the repository is set to private.

I guess the reasoning behind this is, that in a private repository, only the team members can see the issues anyhow, so there is little point in restricting access to issues to team members again by marking them confidential.

However, I think that this reasoning is wrong.

A project might change its visibility depending on the needs of the team. E.g. I find it common practice to start my Open Source projects in a private repository (e.g. when I'm not sure whether i really want to persue the project on the long-run). Only when there is some substantial code (e.g. a working prototype), I switch the project to public.

However, switching the project to public will also make all the issues public, even if some of them were indeed confidential. One could then (after switching the project to public) go and tag all the confidential issues as such, but this obvisouly opens a race condition where people can see issues they are not supposed to see (however short that time frame is).

So i think that confidental issues and private projects are orthogonal concepts, and both should be settable independently.

This should also make the implementation simpler and more robust.