IssueLifecycle - TypeCobolTeam/TypeCobol GitHub Wiki

The bug has been reproduced, but we may not know precisely how to reproduce it or why it happens.

Once the issue is commented with an as precise as possible description of the cause of the issue, the To Analyse label can be removed, and the To Test label must be added.

The issue already describes:

• a step-by-step description (use case) about how to reproduce the bug
• what is the expected behaviour in this use case
• what is instead the observed behaviour
• how to fix the bug For the bug to be fixed, source code that solves the issue must now be proposed, either via a team commit or via an external pull request.

Once this is done, the To Fix label can be removed. If unit tests ar not part of the solving commit, the To Test label must be added.

The source code already contains a bugfix for this issue. Now, we have to make sure the bug never happens anymore. For this:

• either unit tests must be written
• or in depth validation must happen All methods of reproducing the bug must be covered by unit tests.

Once this is done, the To Test label can be removed and the corresponding issue can be closed.

A bug issue can be closed in the following cases:

• the bug is properly fixed, with all way of reproducing the bug being covered by tests
• the bug could not be reproduced as described. In this case, the issue is closed with the Won't Do label.

A proposal can be either of the following:

• a user-proposed feature. When the feature description will be appropriate (ie. enough details) and the TypeCobol team has deemed this feature pertinent/useful, this issue will be changed from a proposal to an enhancement
• a general discussion about whatever topic needs it. It is too early to talk about a properly scoped feature implementation, even less a way of implementing it.

The feature described in the issue development has been deemed pertinent. The specific way to tackle the feature implementation has not beed studied. The workload has not been estimated.

The issue already describes how this feature should be implemented. Code must now be proposed, either via a team commit or via an external pull request.

The enhancement is already implemented. Now, we have to make sure it works as intended in all use cases. For this:

• either unit tests must be written
• or in depth validation must happen All use cases of the feature must be covered by test for the corresponding issue to be closed.

An enhancement issue can be closed in the following cases:

• the enhancement is properly implemented, with all uses cases being tested
• enhancing the application in the way described by the issue is not desirable anymore, either because project priorities have changed or because the application has changed enough to make the enhancement implementation too difficult for what it is worth. In this case, the issue is closed with the Won't Do label.