Repository navigation
[Discussion] GitHub labels definition in this project #17
Description
I think we should define how we will use labels in the project.
See the current list here: https://github.com/OpenAPITools/openapi-generator/issues/labels
What is the difference between bug and invalid ?
Is invalid for an issue that is not correct?
I also think we need to do the difference between something broken in the generator (for example a NullPointer when we run the code) and something that is wrong in the generated code (that is often only for a specific OpenAPI sepecification, and for one target language)
I also think we need a discussion type of issue.
Activity
wing328 commentedon May 13, 2018
To start with, I've cloned the labels using a script.
jimschubert commentedon May 13, 2018
I've only seen
invalidrefer to the issue being reported, and not to code. I don't particularly like the label, as it sounds too negative.I'd actually like to see generator labels separated into:
This way, I could easily filter for
c#,scala,kotlin, or something likeopenapi-generator-ignore. This would reduce the numbers of labels significantly. That is,client,server, andc#would be their own labels, soClient: C-SharpandServer: C-Sharpwould be searchable asclientc#andserverc#.For framework specifics, I could add a label search language specifics or search for all issues across languages for a given framework. As an example, I plan to add Spring support for Kotlin in the coming months, it would be nice to search Spring related issues in general so I don't duplicate efforts done for Java's implementation.
If we have the above options listed in the issue template, I could write a chrome extension to automatically apply these labels.
Other labels I think would be helpful:
bug verifiedcan't reproduceworkaround suggestedfeature requestawaiting user responseWe have many labels that are color coded and grouped by prefix (e.g.
Feature:), but I would find it helpful to be able to search these as that group. According to GitHub docs, there's still no way to search labels by "starts with" or "contains" operators.The above suggestions would help me, personally. One problem I had previously was that I had no way to track that issues were researched and/or verified. I spent a bit of time filtering issues and going through old issues to see if anything had changed.
There are also common labels such as
Good first issueto drive community contributions, which I think would be good to adopt.jmini commentedon May 13, 2018
I like the idea of splitting: language / generator type / framework
We should decide soon, because when we remove/rename labels it mess up with the existing labels.
jmini commentedon May 18, 2018
The more I work with label in this project, the more I consider that we should follow @jimschubert proposal for
language,generator type,framework.What is the added value to set
Kotlin: ClientandKotlin: Serveron an issue? On the other part, instead ofJava: ClientI think thatRest-assured(framework) would be great.Can we do the proposed change?
jmini commentedon Jun 11, 2018
From @jimschubert in #144 :
I agree, we should create such a label.
jimschubert commentedon Jun 20, 2018
I want to test the core team alias:
/cc @OpenAPITools/generator-core-team
jimschubert commentedon Jan 29, 2020
We've created a ton of labels, and I created the GitHub App auto-labeler to assist with labeling issues. I think this is good to close.
Try to improve overall spacing (OpenAPITools#17)
Swift5 Vapor 4 client library (#9625)
fix(kotlin-client): fix 4 pre-existing defects found while reviewing …