637
edits
(formatting) |
DaveLawrence (talk | contribs) No edit summary |
||
Line 10: | Line 10: | ||
# The approver can set a- and leave the bug open, which means that the requirements/description need more work, or can set a- and close the bug as WONTFIX. RESOLVED WONTFIX is an indication that the project refuses the feature and will not accept it. | # The approver can set a- and leave the bug open, which means that the requirements/description need more work, or can set a- and close the bug as WONTFIX. RESOLVED WONTFIX is an indication that the project refuses the feature and will not accept it. | ||
# If the approver sets a+, the bug stays open until the feature is implemented, and then it can be resolved as FIXED. | # If the approver sets a+, the bug stays open until the feature is implemented, and then it can be resolved as FIXED. | ||
dkl comments: | |||
# Set a rfc keyword on the bug for easy searching when it is filed or afterwards during a bug triage. | |||
## maybe just put [RFC] in the summary? thoughts? | |||
# We should have a rfc-approval flag separate from the old approval flag currently used for checkins. | |||
# question: Should a separate bug be filed for the actual work or sufficient to just continue using the rfc bug? |
edits