Changes between Version 58 and Version 59 of PLATFORM_STANDARDS_GENERAL

Timestamp:

01/07/09 10:47:54 (16 years ago)

Author:

pav

Comment:

--

PLATFORM_STANDARDS_GENERAL

@@ -2 +2 @@
 = Tasks types =
 Currently we have five task types. Each task has different requirements for revision phases - Analysis, Design and Implementation.
- * Coding tasks
+ * '''Coding tasks'''
   * Description - This task type contains tasks which result should be added application functionality, code change/improvement.
   * [wiki:PLATFORM_STANDARDS_ANALYSIS Analysis] - Analysis of these tasks revision contains what are the requirements for the task, what are expected results, functionality/improvement requirements, how-to demos, implementation ideas.
@@ -8 +8 @@
   * Implementation - In the implementation section of the task's revision there should be a link to the change set of the commit where the modifications are done. Explanation of the changes should be provided. Write down the added functionalities or improvements that the tasks code bring to the project. Explain which part of source you've added/edited and how. The result of your work should be presentable in Analysis/How to Demo section.
   * Testing - In testing should be described how this task will be tested, here should be linked trac tickets, auto tests, test cases.
-  * Example - [wiki:BASE_BOUND_CONTROLS_R0]; [wiki:PRO_LIB_CORE_TUTORIAL_R0]
- * Bug Fix
+  * Coding task kinds
+   * '''external feature (visible from the user):'''
+    * analyzing 
+     * should have a specification, and a manual testing scenario 
+    * designing 
+     * write an automatic test or tests that verifies that your feature is working
+     * look at the related code
+     * decide what needs to be added
+     * if you add new library feature
+      * write use case tests for it 
+     * you may also write skeleton types (only declaration) and demos
+      * write an outline of your design. 
+    * implementing
+     * make all the designed things work.
+     * ensure that all tests pass.
+     * during the process, add more tests. 
+   * '''Researching about a technology or library'''
+    * analyzing: specify what needs to be researched
+     * what the research will solve
+     * what is needed to be solved (this is important) 
+    * designing
+     * you can try things, but do not pollute the main source (for example with libraries)
+     * if you need to use other libraries, do it in another project (or in another branch)
+     * if you don't need other libraries, you can do it in a research package, but you should make sure that you don't introduce warnings, failing tests, etc. 
+    * implementing
+     * you present the written results / conclusions of your research, demo codes, etc. 
+    * reviewers: 1-2 developers 
+   * '''implementing a new internal feature (a library or something, not directly visible)'''
+    * analyzing: what the library will provide
+    * designing: should include:
+     * use case tests
+     * samples
+     * demo (in some cases),
+     * design outline 
+    * implementing
+     * the library should be implemented
+     * enough tests should be written during the process 
+     * reviewers: 2 developers 
+   * '''Performing structure changes or refactoring.'''
+    * analyzing: what the issues are
+    * designing: understanding it, and providing an idea how to fix the issues
+    * implementing: fixing the issues
+    * reviewers: 1-2 developers 
+  * Examples: [wiki:BASE_BOUND_CONTROLS_R0]; [wiki:PRO_LIB_CORE_TUTORIAL_R0]
+  
+ * '''Bug Fix'''
   * Description - Bug fix type tasks are part of Unplanned tasks. These tasks consist of different kinds of unwanted application behavior - lack of functionality, wrong functionality, different errors. Bug tasks should be presented as "BUG_TASK_NAME"
   * [wiki:PLATFORM_STANDARDS_ANALYSIS Analysis] - Analysis of Bug Fixes should contain exact explanation of exactly happens / not happens (what's wrong). How to demo should contain steps to recreate to prove that the bug doesn't exist anymore. In this section links to tickets can be very useful
@@ -16 +60 @@
   * Testing - In testing should be described how bug task will be tested, here should be linked trac tickets, auto tests, test cases.
   * Example - none for now (will be added when such is available)
- * Document
+ * '''Document'''
   * Description - Document tasks require different documents as result. In most cases, these documents are auxiliary for other tasks. Commonly, the result of document tasks will be Wiki page, but may also be other document and may consist of text, diagrams, media files, spreadsheets, examples, etc.
   * [wiki:PLATFORM_STANDARDS_ANALYSIS Analysis] - Analysis section should contain document requirements (file format, dimensions, formatting), contents requirements. This section should also contain related tasks - tasks that depend on that one, tasks of which this task depends, similar tasks, etc.
@@ -22 +66 @@
   * Implementation - Implementation section as in other tasks should contain link to created documents and explanation how they were done. Because most of the tasks include more than one revision you must explain what's added/improved during the last revision. The results should be presentable in Analysis/How to Demo section.
   * Example - [wiki:PROCESS]
- * Setup
+ * '''Setup'''
   * Description - The result of this tasks are hardware/software setup of different computer appliances that will be used for executing all other tasks. These contain website, wiki, developer platform setup, etc.
   * [wiki:PLATFORM_STANDARDS_ANALYSIS Analysis] - Analysis answers the question what are the requirements for this appliance - hardware and software. For example, some of the community server hardware requirements are space and bandwidth, and software - running web server, security issues. Here should be also listed tasks that depend on that one. How to demo should point the address of the server/computer and presentation of some features.