Talk:Contributing Patches

Handling patches in IssueZilla (Draft)

patches do have the Issue Type PATCH when get subbmitted in the Issue database.

In case a patch implements a FEATURE or ENHANCEMENT this issue type stays at type PATCH until:

• The patch has been committed to a child workspace (cws)

• and has been marked as fixed

• and has been verified by the QA person for that cws.

At the time the cws get QA approval, the issue needs to get the type FEATURE or ENHANCEMENT if such is implemented. Also it needs to get check if specification, Feature mail also have been completed.

Stats invalidated

Please note that a change of the issue type from PATCH to something else will invalidate our patch handling metrics. I strongly recommend not to change the handling before the statistics gathering accomodates the new workflow.

Comments

 I think it's better that the issue type is changed when the CWS is approved, not when the PATCH
 issue is verified.

 Changing it's type to ENHANCEMENT or FEATURE before the complete CWS is finished might lead to
 undesired results if the CWS goes back to engineering. The patch might or might not be the reason
 for CWS-QA failing, but terms and semantics (and statistics) become fuzzy if in such a case the
 issue is an ENHANCEMENT/FEATURE, but still needs patch-polishing.
 (FS)

Benefit from the change of type

I do not (yet) understand the benefit of the effort to change the type. Could someone explain where we have a significant advantage. OTH I see the additional burden and risk to forget the "correct" handling. This might lead to new stumbling blocks instead of removing these. Please let's make contributing patches and timely handling of patches easier. Patches are 3% of all issues (2100 of 65000); open patches are 1% of all open issues. Let's discuss this again when we are at a ratio of more than 10%. --stx12 10:53, 5 October 2006 (CEST)

An earlier blog entry has some thoughts on the topic. --stx12 11:37, 5 October 2006 (CEST)