We would like to have project specific quality gates. The project administrator should be able to modify the gate configuration (e.g. maximum number of allowed issues) for project only. It should not be able to modify all other quality gates.
Currently there is only a global privilege to administer quality gates.
Is it possible to implement feature to allow specific user or group to administrate specific quality gate?
Hi,
Iāve moved this thread to the āSuggest new featuresā category, because what you describe isnāt currently available. BTW, it is possible for a project administrator to choose from the existing quality gates. But itās not possible (and not actually likely) to create project-specific QGs. Why? Because we feel you should really be enforcing the same standards across the entire organization, which should be possible if you focus on New Code.
Ā
Ann
You are right, theoretically!
In real life I manage a server with two kinds of projects:
You may state that we can remove the limit for āmaximum issuesā. But the project administrator would like to reduce the maximum number every time it is possible. Over the time we expect to get fewer issues in ALL projects.
Because this maximum configuration I need project specific gates or similar option.
Hi,
This is actually the beauty (one of them!) of using New Code metrics. Letās say youāre watching the total number of Bugs. In my project itās 51, so my individual Quality Gate has been set to fail at Bugs > 51. So if I
This isnāt what you want to happen. So instead use āon New Codeā metrics. With a QG condition on Bugs on New Code > 0 then if I
Thatās why I say that with an āon New Codeā Quality Gate you really can apply the same criteria across all projects. And with this approach you will gradually reduce the outstanding technical debt in the normal course of doing business, assuming your developers donāt ignore existing issues in the code theyāre working on.
But okay, if this still doesnāt do it for you, your request is still listed as a suggested new feature. 
Ann
In theory you are right, again.
But there are situations where we have to live with one or two new issues, e.g. TODOs not fixable in current sprint. So, we accept some time a failed quality gate if the NEW ISSUES are uncritical.
Not having a TOTAL MAXIMUM the list may grow step by step.
Your feelings are your personal matter - do not try to enforce them on your users. Do not consider them as idiots unable to make own decisions.
In a big organization there are many kind of projects with various quality requirements and on different stages of development.
Hey Lukas,
Iām curious ā are the issues that you accept as non-critical (and thus, when they fail the Quality Gate, you ignore the Quality Gate failure) typically INFO level issues (like fixing TODOs)?
Iām asking because there might be Quality Gate conditions you can set to get around INFO level rules triggering Quality Gate failure, or perhaps an argument to be made that INFO level issues shouldnāt trigger Quality Gate conditions regarding issue count (since they are supposed to just be informative, no action is expected). I await your feedback before I invest into that argument. 
What happens when the list hits the total maximum? Is there suddenly time to bring that total down? How does a project administrator judge what the total maximum should be?
I think, I will never configure to ignore INFO issues at all. Instead it is always an individual decision.
From time to time we reduce the value for āmaximum number of issues/bugsā. I never want to increase the number again. Over the time I hope to reach ā0 issues and 0 bugsā.