LaurentGoderre · August 29, 2015 14:06 · Oct 2, 2014 · Sep 30, 2014 · Sep 30, 2014 · Sep 30, 2014
diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -47,7 +47,9 @@ The core framework and the 24 remaining plugins and 7 polyfill need unit tests.
 
 TODO
 
-Note: Documentation i18n
+Note: 
+* Documentation i18n
+* Transifex
 
 ## Documentation
 

diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -46,6 +46,9 @@ The core framework and the 24 remaining plugins and 7 polyfill need unit tests.
 ## i18n Workflow
 
 TODO
+
 Note: Documentation i18n
 
-## Documentation
+## Documentation
+
+TODO
diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -39,10 +39,10 @@ To allow theme to customize the look of WET plugins and avoid duplication of sty
 
 ## Unit Testing
 
-### Background
-
 Unit tests is an essential part of any development project because it gives developers confidence that their work doesn't break any functionality. Currently in WET, code is tested using both a headless browser (PhantomJS) and virtualized browsers using SauceLabs. Unfortunately, the core and two third of plugins and almost all polyfills don't have test cases ([see issue #6070 for more details](https://github.com/wet-boew/wet-boew/issues/6070).
 
+The core framework and the 24 remaining plugins and 7 polyfill need unit tests. This will allow us to better deal with issues logged by users. Either the individual who logs the issue or a WET developer could create a test to prove or disprove the bug.
+
 ## i18n Workflow
 
 TODO

diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -39,7 +39,9 @@ To allow theme to customize the look of WET plugins and avoid duplication of sty
 
 ## Unit Testing
 
-TODO
+### Background
+
+Unit tests is an essential part of any development project because it gives developers confidence that their work doesn't break any functionality. Currently in WET, code is tested using both a headless browser (PhantomJS) and virtualized browsers using SauceLabs. Unfortunately, the core and two third of plugins and almost all polyfills don't have test cases ([see issue #6070 for more details](https://github.com/wet-boew/wet-boew/issues/6070).
 
 ## i18n Workflow
 

diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -43,4 +43,7 @@ TODO
 
 ## i18n Workflow
 
-TODO
+TODO
+Note: Documentation i18n
+
+## Documentation
diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -25,6 +25,7 @@ TODO
 
 * [ES6 Classes Example](http://h3manth.com/content/classes-javascript-es6)
 * [ES6 Classes Proposal](http://wiki.ecmascript.org/doku.php?id=harmony:classes)
+* [Traceur Project Page](https://github.com/google/traceur-compiler)
 
 ## Theme CSS Overrides
 

diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -16,15 +16,15 @@ TODO
 
 TODO
 
-[Base2 Example](http://ejohn.org/blog/simple-javascript-inheritance/)
-[Base2 Project Page](https://code.google.com/p/base2/)
+* [Base2 Example](http://ejohn.org/blog/simple-javascript-inheritance/)
+* [Base2 Project Page](https://code.google.com/p/base2/)
 
 #### ES6 Classes w/ Google Traceur
 
 TODO
 
-[ES6 Classes Example](http://h3manth.com/content/classes-javascript-es6)
-[ES6 Classes Proposal](http://wiki.ecmascript.org/doku.php?id=harmony:classes)
+* [ES6 Classes Example](http://h3manth.com/content/classes-javascript-es6)
+* [ES6 Classes Proposal](http://wiki.ecmascript.org/doku.php?id=harmony:classes)
 
 ## Theme CSS Overrides
 

diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -16,10 +16,16 @@ TODO
 
 TODO
 
+[Base2 Example](http://ejohn.org/blog/simple-javascript-inheritance/)
+[Base2 Project Page](https://code.google.com/p/base2/)
+
 #### ES6 Classes w/ Google Traceur
 
 TODO
 
+[ES6 Classes Example](http://h3manth.com/content/classes-javascript-es6)
+[ES6 Classes Proposal](http://wiki.ecmascript.org/doku.php?id=harmony:classes)
+
 ## Theme CSS Overrides
 
 ### Background

diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -4,7 +4,7 @@
 
 ### Background
 
-Currently in WET, there is a lot of duplication of code, particularly around plugin initialization and lifetime. Additionally, plugins are sealed in an anonymous scope to prevent conflicts but this approach makes it very difficult for implementers to override or customize plugins. To solve this problem, plugins need to switch to a more open architecture and duplicated code need to be regrouped and shared among plugins. This new structure also need a full unit test suite (see the [Unit Testing](#unit-test) section for more details). To acheive this goal, several options are available: Prototypal Inheritance (Native), Base2 Library, ES6 Classes w/ Google Traceur
+Currently in WET, there is a lot of duplication of code, particularly around plugin initialization and lifetime. Additionally, plugins are sealed in an anonymous scope to prevent conflicts but this approach makes it very difficult for implementers to override or customize plugins. To solve this problem, plugins need to switch to a more open architecture and duplicated code need to be regrouped and shared among plugins. This new structure also need a full unit test suite (see the [Unit Testing](#unit-testing) section for more details). To acheive this goal, several options are available: Prototypal Inheritance (Native), Base2 Library, ES6 Classes w/ Google Traceur
 
 ### Options
 

diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -4,7 +4,7 @@
 
 ### Background
 
-Currently in WET, there is a lot of duplication of code, particularly around plugin initialization and lifetime. Additionally, plugins are sealed in an anonymous scope to prevent conflicts but this approach makes it very difficult for implementers to override or customize plugins. To solve this problem, plugins need to switch to a more open architecture and duplicated code need to be regrouped and shared among plugins. This new structure also need a full unit test suite (currently missing). To acheive this goal, several options are available: Prototypal Inheritance (Native), Base2 Library, ES6 Classes w/ Google Traceur
+Currently in WET, there is a lot of duplication of code, particularly around plugin initialization and lifetime. Additionally, plugins are sealed in an anonymous scope to prevent conflicts but this approach makes it very difficult for implementers to override or customize plugins. To solve this problem, plugins need to switch to a more open architecture and duplicated code need to be regrouped and shared among plugins. This new structure also need a full unit test suite (see the [Unit Testing](#unit-test) section for more details). To acheive this goal, several options are available: Prototypal Inheritance (Native), Base2 Library, ES6 Classes w/ Google Traceur
 
 ### Options
 

diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -28,7 +28,7 @@ In version 4 of WET, themes were seperated into seperate repository to give them
 
 ### Implementation
 
-To allow theme to customize the look of WET plugins and avoid duplication of style, 
+To allow theme to customize the look of WET plugins and avoid duplication of style, themes need to compiled their SCSS styles to include WET core styles and Bootstrap styles and overrides. This would render the use of a wet-boew.css file obsolete and would introduce a markup change. Additionally, customizeable values need to be converted to SCSS variables and added to the `_variables.scss` file. This would allow theme to add an override for any of thes variables in their own variables files to customize the look of plugins.
 
 ## Unit Testing
 

diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -20,14 +20,16 @@ TODO
 
 TODO
 
-## CSS Parameterization
+## Theme CSS Overrides
 
 ### Background
 
 In version 4 of WET, themes were seperated into seperate repository to give theme more flexibility. The intent was also to make it easier to create new themes (the project generator-wet-boew-theme was created for this purpose). One of the current limitations for theme is that WET plugins can't easily be customized. Themes are stuck with colour choices from the WET theme. It was the intent from the start of the development for v4 to allow theme to customize the way WET plugins look.
 
 ### Implementation
 
+To allow theme to customize the look of WET plugins and avoid duplication of style, 
+
 ## Unit Testing
 
 TODO

diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -22,7 +22,11 @@ TODO
 
 ## CSS Parameterization
 
-In version 4 of WET, themes were seperated into seperate repository to give theme more flexibility. The intent was also to make it easier to create new themes (the project generator-wet-boew-theme was created for this purpose). One of the current limitations for theme is that WET plugins can't easily be customized. Themes are stuck with color choice from the WET theme.
+### Background
+
+In version 4 of WET, themes were seperated into seperate repository to give theme more flexibility. The intent was also to make it easier to create new themes (the project generator-wet-boew-theme was created for this purpose). One of the current limitations for theme is that WET plugins can't easily be customized. Themes are stuck with colour choices from the WET theme. It was the intent from the start of the development for v4 to allow theme to customize the way WET plugins look.
+
+### Implementation
 
 ## Unit Testing
 

diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -22,7 +22,7 @@ TODO
 
 ## CSS Parameterization
 
-TODO
+In version 4 of WET, themes were seperated into seperate repository to give theme more flexibility. The intent was also to make it easier to create new themes (the project generator-wet-boew-theme was created for this purpose). One of the current limitations for theme is that WET plugins can't easily be customized. Themes are stuck with color choice from the WET theme.
 
 ## Unit Testing
 

diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -10,12 +10,24 @@ Currently in WET, there is a lot of duplication of code, particularly around plu
 
 #### Prototypal Inheritance
 
+TODO
+
 #### Base2 Library
 
+TODO
+
 #### ES6 Classes w/ Google Traceur
 
+TODO
+
 ## CSS Parameterization
 
+TODO
+
 ## Unit Testing
 
-## i18n Workflow
+TODO
+
+## i18n Workflow
+
+TODO
diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -4,7 +4,15 @@
 
 ### Background
 
-Currently in WET, there is a lot of duplication of code, particularly around plugin initialization and lifetime. Additionally, plugins are sealed in an anonymous scope to prevent conflicts but this approach makes it very difficult for implementers to override or customize plugins. To solve this problem, plugins need to switch to a more open architecture and duplicated code need to be regrouped and shared among plugins. This new structure also need a full unit test suite (currently missing). To acheive this goal, several options are available: Prototype Inheritance (Native), Base2 Library, ES6 Classes w/ Google Traceur
+Currently in WET, there is a lot of duplication of code, particularly around plugin initialization and lifetime. Additionally, plugins are sealed in an anonymous scope to prevent conflicts but this approach makes it very difficult for implementers to override or customize plugins. To solve this problem, plugins need to switch to a more open architecture and duplicated code need to be regrouped and shared among plugins. This new structure also need a full unit test suite (currently missing). To acheive this goal, several options are available: Prototypal Inheritance (Native), Base2 Library, ES6 Classes w/ Google Traceur
+
+### Options
+
+#### Prototypal Inheritance
+
+#### Base2 Library
+
+#### ES6 Classes w/ Google Traceur
 
 ## CSS Parameterization
 

diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -4,7 +4,7 @@
 
 ### Background
 
-Currently in WET, there is a lot of duplication of code, particularly around plugin initialization and lifetime. Additionally, plugins are sealed in an anonymous scope to prevent conflicts but this approach makes it very difficult for implementers to override or customize plugins.
+Currently in WET, there is a lot of duplication of code, particularly around plugin initialization and lifetime. Additionally, plugins are sealed in an anonymous scope to prevent conflicts but this approach makes it very difficult for implementers to override or customize plugins. To solve this problem, plugins need to switch to a more open architecture and duplicated code need to be regrouped and shared among plugins. This new structure also need a full unit test suite (currently missing). To acheive this goal, several options are available: Prototype Inheritance (Native), Base2 Library, ES6 Classes w/ Google Traceur
 
 ## CSS Parameterization
 

diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -4,7 +4,7 @@
 
 ### Background
 
-Currently in WET, there is a lot of duplication of code, particularly around plugin initialization and lifetime. Additionally, plugins are sealed in an anonymous scope
+Currently in WET, there is a lot of duplication of code, particularly around plugin initialization and lifetime. Additionally, plugins are sealed in an anonymous scope to prevent conflicts but this approach makes it very difficult for implementers to override or customize plugins.
 
 ## CSS Parameterization
 

diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -2,6 +2,10 @@
 
 ## New Plugin Structure
 
+### Background
+
+Currently in WET, there is a lot of duplication of code, particularly around plugin initialization and lifetime. Additionally, plugins are sealed in an anonymous scope
+
 ## CSS Parameterization
 
 ## Unit Testing

diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -6,4 +6,4 @@
 
 ## Unit Testing
 
-## i18n
+## i18n Workflow
diff --git a/wet-nextsteps.md b/wet-nextsteps.md
@@ -0,0 +1,9 @@
+# Web Experience Toolkit - Next Steps
+
+## New Plugin Structure
+
+## CSS Parameterization
+
+## Unit Testing
+
+## i18n
No results found