neos team mailing list archive

[Johannes Wettinger <revager@xxxxxxxxxxxxxx>]

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 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.
+ 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. 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 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 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: 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 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: 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 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), sets the implementation status to "Needs Code Review".
+ 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. Therefore it sets the implementation status to "Needs Code Review". 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: 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 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 changes the implementation status of the blueprint to "Deployment" and the feature request's status as "Fix Committed".
+ 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 ).
+ STEP 12: 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