(DOCU) Feature Request Workflow

STEP 1: SUBMISSION -- The feature requester opens a new bug in the project's bug tracker on Launchpad and describes his or her ideas in the bug description. The title should contain the prefix "(FR)" as first token and the "feature-request" tag should be assigned.

STEP 2: DISCUSSION -- The project developers discuss the feature request in the bug tracker. This discussion can also involve prototyping possible solutions and arguing about in which future version the feature shall be realized. The file names of the prototypes need to comply with the following naming scheme: prototype_<AUTHOR>_<VERSION>.<FILE-EXTENSION> (e.g. prototype_wettinger_2.xml or prototype_casciato_5.xml). In addition to the naming scheme, the file format of the prototypes should be one of the following: Balsamiq Mockups (preferred), Pencil or OpenOffice Draw.

STEP 3: DRAFTER ASSIGNMENT -- After reaching a consensus, the project team appoints a drafter, who will be responsible for creating a blueprint for this feature request. An approver, who will be responsible for the quality assurance of this feature, is elected and set as well.

STEP 4: BLUEPRINT CREATION -- The appointed drafter creates a new blueprint. He links it using the "Link a bug report" function to the feature request and sets its status to "Drafting".

STEP 5: DRAFTING -- The drafter incorporates the consensus of the discussion from the related feature request into the blueprint, and derives a specification from it. The specification should conform to our guideline ( https://blueprints.launchpad.net/revager/+spec/docu-specification-blueprint-guideline ). After finishing the blueprint draft, he sets its definition to "Review" and informs the approver.

STEP 6: DRAFT REVIEW -- The approver reviews and validates the blueprint, sets its definition to "Approved" and posts a short comment in the bug tracker. In case further discussion is needed, the approver sets the status to "Pending Approval" and the discussion continues in the bug tracker.

STEP 7: IMPLEMENTER ASSIGNMENT -- The team appoints an implementer (assignee of the blueprint), who will be responsible to realize the (now frozen) specification in the blueprint in a separate branch. The branch is created and the name of the branch is linked to the blueprint using "Link a related branch".

STEP 8: DETAILED DESIGN AND IMPLEMENTATION -- The implementer creates a new branch and links it to the blueprint using "Link a related branch". He might want to change the implementation status of the blueprint to reflect his current progress. Once the code is considered stable enough (including unit tests), he sets the implementation status to "Needs Code Review" and informs the approver.

STEP 9: CODE REVIEW -- The approver reviews the code. In case any problems with the code are spotted, the approver creates appropriate bug reports and links them to the blueprint. After the implementer has fixed all problems, the approver sets the implementation status to "Implemented".

STEP 10: TESTING -- The approver runs all available test suites and a system test, to verify that the new feature is working correctly. After this was successful, it sets proposes to merge the branch into the trunk.

STEP 11: MERGE -- The assignee of the feature request merges the corresponding branch into the trunk branch and sets the feature request's status to "Fix Committed".

STEP 12: DELIVERY -- Continue with our release workflow ( https://blueprints.launchpad.net/revager/+spec/docu-stable-releases-checklist ).