← Back to team overview

neos team mailing list archive

[Blueprint docu-feature-request-workflow] (DOCU) Feature Request workflow

 

Blueprint changed by Johannes Wettinger:

Whiteboard changed:
  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. It should also be assigned the "feature-request" tag.
  
  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.
  
  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. This person is set in the "assigned to" field of this feature request. Also an approver, who will be responsible for the quality assurance of this feature, is elected and set.
  
  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".
  
  Step 5: Draft review
  The approver reviews and validates the blueprint and sets its definition to "Approved". In case further discussion is needed, the approver sets the status to "Pending-approval" and the discussion continues in the bug tracker.
  
  Step 6: Implementer assignment
- The team appoints an implementer, 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".
+ 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 7: 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), sets the implementation status to "Needs Code Review".
  
  Step 8: Code review
  The approver reviews the code. Therefore it sets the implementation status to "Pending-approval". In case any problems with the code are spotted, the approver creates appropiates bugs and links them to blueprint. After the implementer has fixed all problems, the team sets the implementation status to "Implemented".
  
  Step 9: 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 10: Merge
  The assignee of the feature request changes the implementation status of the blueprint to "Deployment" and the feature request's status as "fix committed".
  
  Step 11: Delivery
  Continue with our release workflow ( https://blueprints.launchpad.net/revager/+spec/docu-stable-releases-checklist ).

-- 
(DOCU) Feature Request workflow
https://blueprints.launchpad.net/revager/+spec/docu-feature-request-workflow