Differences from version 4 to 7

@@ -1,20 +1,26 @@

-''NOTE: some of the formatting of this page is a little messed up because it was not written for wiki, to see it clean, click edit and copy the raw text and paste it into a text editor. -Will''
-!Documenting BW and bw.o Site Restructuring Proposal
-CONCEPT: I propose to undertake some leadership of enhancing the marketing of BW and expanding the developer base. This would be achieved through two non-trivial programs:
+!!Documenting BW and bw.o Site Restructuring Proposal
-1. Restructure bw.o
-2. Enhancing the documentation of BW to a highly reliable level, such that developers new to BW can easily build out a complex package utilizing all the core services of Liberty and the Kernel.
+^CONCEPT: I propose to undertake some leadership of enhancing the marketing of BW and expanding the developer base. This would be achieved through two non-trivial programs:
+#Restructure the bw.o site
+#Creating documentation for BW, such that developers, admins and end users can fully utilize all the core services of Liberty and the Kernel.
 I see the restructuring of bw.o as part of and necessary to enhancing the documentation of BW, as it is my observation that while there is much good documentation on the site, it is not easy to find, and the relationships between documents are not easy to grasp.
 Specifics of my bw.o site restructuring proposal follow this introduction.
-The Documenting of BW shall be taken up as a high profile project on bw.o and evangelized to the BW small but dedicated developer community. This means raising documenting BW to the level of a call to action. This project will have a clear road map, goals will be set, needs will be clearly defined and prioritized, update reports given, all done with the intent to encourage other developers in the BW ring to help out. As the ultimate goal of this project is to relieve pressure on the core BW developers, I am seeking your participation as evangelists of this project.
+__Using the "wiki method":__ The most important step to achieving good documentation by wiki not answering documentation type questions email or IRC. This "tough love" practice serves the developers well because they will only have to answer questions once, and as a courtesy in return for having questions answered the questioners should ((refactor)) the developer's (likely hurried) answers using the ((style guide)). This approach leaves proper documentation for the next person that comes along with the same question.
+Ultimately this kind of "user training" will relieve pressure on the core BW developers to do all the work.
+Having a coherrent decision making method for editorial purposes, and a well planned structure to the document, complete with a ((style guide)).
 The documentation road map will be a prioritized list of items to complete. Here is a preliminary proposed high level list of prioritized goals:

@@ -30,20 +36,18 @@

 Note: The current API documentation is excellent for highly skilled developers and those accustom to this type of documentation, but I propose that some simplified/structured documentation of the key APIs would go a long toward helping those new to BW. As an example see the way Google documents its APIs. This will probably naturally evolve from the package tutorials.
+!!Site Restructuring Summary
+CONCEPT: The main concept is to
+a) simplify the design and layout of bw.o - providing more white space and visual structure to the content.
+b)target content for the two basic types of visitors Developers and non-developers (end users and site administrators)
-!Site Restructuring Summary
-CONCEPT: The main concept is to simplify the features of bw.o and provide more structure to the valuable content there, clearly targeting it to the two basic types of CMS users, admins/designers and CMS developers. The restructured site could be thought to have three basic parts:
-* Admin/Site Designer Section (i.e. for people wanting to use BW but not write code)
+* Site administrators and end-users
 * Developer Section
-* Demo
 Each one of these would have its own landing page specifically to target its unique audience.
+In addition, a special section of ((Help Pages)), which are exported with all downloaded copies of bitweaver - targeted at end users.
 Support and Documentation could be thought of as fourth and fifth sections, and should each have their own landing pages. But I propose to basically structure the deeper content for these relative to Developers and Admins/Designers, so they are not really their own section.

@@ -365,7 +369,7 @@

 ''These are observations I am making as I am going through the site and organizing this [http://www.bitweaver.org/wiki/Documentation|Documentation] page. They are suggestions. -Will''
 These two would greatly reduce the cluttered look of the site:
-* Turn off starts from wiki pages
+* Turn off Stars from wiki pages
 * Display page change data only to registered users
 Turn off Comments on Wiki Pages - or make it a click to see them. Comments make them look unofficial and add clutter.
Page History
02 Aug 2006 (20:17 UTC)
mlpvolt: bravo - My 2 cents and more about documentation. More to follow.
Current • Source
View • Compare • Difference • Source
View • Compare • Difference • Source
View • Compare • Difference • Source
View • Compare • Difference • Source
View • Compare • Difference • Source
View • Compare • Difference • Source