Labels

The GitHub labels are designed help to classify issues. Every repository has their own guidelines for how labels should be used and general the name of the label is clear enough. There are some ambiguous cases and other information in this page.

The labels for c2go are divided into several categories (explained below), prefixed with a letter like a:. This is just to group label of the same category together. The actual letter prefix is not important but they are in somewhat of an order with the way you may think of them.

Required

Component (dark blue)

Please provide one or more components that this issue is related to:

• cli - Issues relating to the CLI.
• documentation - For existing or new documentation in the wiki, README or anywhere else.
• performance - Issues that do not provide new functionality but make existing features faster.
• syntax - The clang AST parser (ast package) or unsupported C syntax.
• testing - Anything related to the Travis CI or testing.
• transpiler - Anything related to the way Go code is generated from the clang AST.

Type (different colours)

The type of issue:

• bug - Must be a feature that is already said to be implemented, but is not functioning correctly. A bug is never a feature that is not implemented yet (since there will be so many of these).
• duplicate - Refers to an issue that has already been raised. A link to the original issues/PR should be added before it is closed.
• example - A provided link or source code to a complete working program that is not yet working with c2go. These can range from very simple to very complicated but act as milestones to keep development focused towards real programs being transpiled.
• improvement - Anything that would provide new or improve existing functionality.
• question - A question or discussion that does not require any code changes. Action items should be created as new issues to prevent a single issue from covering many different changes.
• refactor - Code changes (such as cleanup or restructuring) that do not generally provide any new functionality. This also includes changes to code documentation.
• won't fix - Issues do not require any action. It could be because the change was decided against or for some other reason.
• waiting for response - The issue cannot not proceed without clarifying a question or some other response is needed.

Optional

Size (shades of yellow)

small, medium and large.

The size can be used to indicate how much work is involved in solving this issue. In many cases the amount of work is unknown or hard to guess so there is no size assigned. However, if the solution is fairly clear, it is helpful to assign a size - especially if the size is small to help new people to find issues to start on.

Header (light blue)

ctype.h, math.h, stdio.h, etc.

If an issue is related to a function or some other element of a specific header files. For example, if there was a bug found with the cos() function it would be tagged as math.h. Or if a function like qsort() was not implemented it would also have it's header file tagged. Many bugs are not specific to a header file and so these tags are optional.