Changes between Version 34 and Version 35 of PLATFORM_STANDARDS_ANALYSIS

Timestamp:

01/25/09 22:40:50 (16 years ago)

Author:

boyan

Comment:

--

PLATFORM_STANDARDS_ANALYSIS

@@ -11 +11 @@
 The analysis of a task is written in a section of its wiki page called Analysis. When creating the task's page, use the TaskPageTemplate - it provides a backbone structure for the analysis, which consists of the following sections:
  * Overview - a brief description of the task (not more than a couple of sentences). In the first revision of the task, it should provide a brief overview of the whole task as well as what should be done in this revision. Otherwise, it should state what the current revision of the task is about. 
- * Task requirements - probably the most important section. It should include a list of requirements that the task must fulfill. These are used for reviewing the design and implementation phase so they should be chosen very carefully. It is recommended to write them as a bullet list. Make sure the requirements are fulfillable for the effort of the current revison of the task. When not sure, mark the less important requirements as optional.
+ * Task requirements - probably the most important section. It should include a list of requirements that the task must fulfill. These are used for reviewing the design and the implementation phases so they should be chosen very carefully. It is recommended to write them as a bullet list. Make sure the requirements are fulfillable for the effort of the current revison of the task. When not sure, mark the less important requirements as optional.
  * Task result - a short phrase or sentence of what the task result should be (for example "Source code"). If the results are more than one, it is recommended to list them as bullets.
  * Implementation idea - a brief description of how you would approach the task if you were to implement it. If you don't have a clear implementation idea, then you shouldn't write the analysis of this task.
- * Related - links to similar tasks and previous revisions of this task as well as useful external resources - all that might be helpful in the design or implementation phase.
+ * Related - links to similar tasks and previous revisions of this task as well as useful external resources - all that might be helpful in the design or the implementation phases.
  * How to demo - a step-by-step instruction of how to demonstrate the task on the sprint closing.
 
 When you write an analysis, you should:
+ * Remember the main guideline of this project: '''Work towards the goal! '''
  * Think well about the task and figure out what its aim is and how it can be reached.
  * Give as much as possible of the needed information for designing and implementing the task.
@@ -38 +39 @@
 
 There are subkinds of coding tasks with specific requirements for the analysis. These are:
- * '''External feature (visible from the user)''' - should provide a specification. A draft of a specification diagram is recommended. A task requirement is adding a manual testing scenario.
+ * '''External feature (visible from the user)''' - should provide a specification. A draft of a specification diagram is recommended.
  * '''Researching a technology or a library''' - should state what the new technology/library will solve and why it is needed.
  * '''Internal feature (not directly visible)''' - should state what the new feature will provide.
@@ -51 +52 @@
  * The team - ask someone that has done a previous revision or has more expirience in that area of the code.
 
-=== Bug Fix  ===
-The analysis of bug fixes should explain the problem - what it is, where it is and when it happens. The different sections should contain as follows:
-  * Overview - a brief explanation of the bug - what happens and in what circumstances; a link to the broken code should be provided if possible.
+=== Bug Fix ===
+The analysis of bug is filled when reporting the bug. It should contain:
+  * Overview - a description of the bug - what happens where and in what circumstances; a link to the broken code.
   * Task requirements - a list of requirements that if fulfilled will fix the bug, what the expected functionality is. Give details - the bug can be a result of misunderstanding the original task requirements.
   * Task result - in most cases, the result of these tasks will be fixed source code but may also contain diagrams, graphics, etc.
   * Implementation idea - suggest a fix if possible; if not - a general approach for fixing the bug.
-  * Related - a list of related tasks and tasks that depend on this bug (that have misfunctionality, lack of features, etc.), tests that break, use cases.
+  * Related - a list of related tasks and tasks that depend on this bug (that have misfunctionality, lack of features, etc.), tests that break, links to use cases.
   * How to demo - an instruction of how to prove the bug is fixed - usually explaining the bug, presenting the solution, running tests.
 
@@ -112 +113 @@
  * Score 3 (pass): The analysis is structured according to the standards but is too short and there's a lot more to be added.
  * Score 4 (pass): The analysis is structured according to the standards and provides enough information for the designer and implementer (useful links, good implementation idea, clear task requirements that are fulfillabe for the effort stated, etc.).
- * Score 5 (pass): The analysis is structured according to the standards and there's nothing more to be added - it's perfect in such a way that a person who is not quite familiar with the project can do well with the design and implementation.
+ * Score 5 (pass): The analysis is structured according to the standards and there's nothing more to be added - it's perfect in such a way that a person who is not quite familiar with the project can do well with the design and the implementation.
 
-All reviews should be motivated. A detailed comment about why an analysis fails is required. For a score of 3 a list of things that could be better should be provided. Comments are encouraged for higher scores as well. Non-integer scores are STRONGLY disencouraged. If you give an analysis a score of 3.5, then you probably have not reviewed it thoroughly enough and cannot clearly state whether the analysis is good or not. Once an analysis has been reviewed, it cannot be altered. If you think an analysis is wrong, you should request a super review. Currently all super reviews should be discussed with Milo. Make sure you are able to provide clear arguments of why the analysis is not good before you request a super review.
+All reviews should be motivated. A detailed comment about why an analysis fails is required. For a score of 3 a list of things that could be better should be provided. Comments are encouraged for higher scores as well. Non-integer scores are STRONGLY disencouraged. If you give an analysis a score of 3.5, then you probably have not reviewed it thoroughly enough and cannot clearly state whether it is good or not. Once an analysis has been reviewed, it cannot be altered. If you think it is wrong, you should request a super review. Currently all super reviews should be discussed with Milo. Make sure you are able to provide clear arguments of why the analysis is not good before you request a super review.
 
 = Comments =
-  ^Your comment here --developer-id@YYYY-MM-DD^
+  ^Your comment here --developer-id@YYYY-MM-DD