Private labels

Release notes

Problem to solve

As a development org, I want to be able to use a public issue tracker both for external collaboration with customers and for internal collaboration on software development. But also, as a developer and product manager, I want to be able see which customer requested specific issues, without leaking that information to other external parties. We may be comfortable developing in public, but we can't leak information about our customers, at least not without their permission. Today, there's no way to keep this information in public feature request or bug reports. You can paste obfuscated links, like Salesforce links, but that doesn't really convey the same information. Seeing actual customer names attached to a ticket, usually as a label, is far more effective.

Intended users

User experience goal

Proposal

Allow labels to be marked as private or confidential so that the existence of a label on an issue doesn't get seen by people outside the company.

Further details

Two things need elaboration.

1. What exactly is "private"? Semantically, I mean something is visible only within the company. But technically, that could mean "someone with Developer+ access to the project". Some companies may define it differently though. Maybe Guest or Reporter access is sufficient? Or maybe even just someone who is logged in? So, to be flexible, it might be worth allowing a team to define their own criteria for display of a label. GitLab already has a pattern of letting you pick multiple roles, multiple groups, and multiple individuals to have access to things (like pushing to a protected branch), so maybe re-use that pattern.
2. A simple checkbox applied to each customer label may be easy enough, but if you have tons of customers, it could be painful managing them all, and the consequences of creating a new label and forgetting to mark it private could be costly. Especially if you combine it with (1) above and allow some more complex pattern. A more flexible way is to allow pattern matching. In our case, we use the format of requester/<company>, which would be easily matched for all new labels we create. This way we could have one rule; set it and forget it.

Permissions and Security

Likely only Maintainer+ should be able to set/manage pattern matching rules, if they're complex rules. If they're simply checkbox style hide or make private actions, then Developer or even Reporter may be more appropriate.

Documentation

Availability & Testing

Available Tier

What does success look like, and how can we measure that?

Companies that were previously using private issue trackers would now be able to make them public, increasing collaboration and customer happiness.

What is the type of buyer?

Is this a cross-stage feature?

Links / references