| 23 | | * Build up a long term community of people that cares and constantly improve |
| 24 | | boost documentation and tools. |
| 25 | | * Achieve an unified look and feel between docs and Boost resources, integrating them as |
| 26 | | much as possible. |
| 27 | | * Make it easier for users to navigate through the enormous amount of boost documentation. |
| 28 | | * Use latest version of standards and support old browsers. |
| 29 | | * Develop tools to automated common task, and to make life easier to boost authors. |
| 30 | | Docs writers should concentrate on generating content and not on figthing with tools. |
| 31 | | * Improve the docs tool chain, simplifying and integrating it lowering the barrier for people |
| 32 | | willing to help us. |
| 33 | | * Write docs, include rationales, use our own tools. If we want to improve boost docs, |
| 34 | | we should start by showcasing best practices in this project. |
| 35 | | * Generate Glue docs. Boost libraries doc are impressive to learn about how individual |
| 36 | | libraries work. However users are missing integration documentation, that sees boost |
| 37 | | as one tied library. How they do common task, which libraries are powerful when combined, |
| 38 | | real life examples; are important documentation we can not expect boost authors to provide. |
| 39 | | * Generate formal documentation that will became in a standard proposal for managing |
| 40 | | Boost docs. |
| 41 | | * Offer our help to translate docs to the new format, do not wait for authors to do this |
| 42 | | themselves. |
| 43 | | * Offer a place where not C++ experts can help the Boost community. In general the tasks |
| 44 | | we do here does not involve template metaprogramming or others complex C++ machinery. |
| 45 | | Dessigners, artists, teachers, web experts, Python programmers and Boost users are very |
| 46 | | welcome along our lines. |
| 47 | | * Include nice looking logos and diagrams. Although Boost libraries are so great that |
| 48 | | they do not need any marketting at all, lets face it: people are attracted like flies to catchy |
| 49 | | names and fancy pictures. |
| 50 | | * Work to make doc tools boost-agnostic. We believe that they are useful beyond the boost |
| 51 | | community, and would welcome anyone who wishes to use, extend or support them. |
| 52 | | * Enjoy our work. If we are not having fun while improving boost docs something |
| 53 | | has gone terribly wrong. |
| | 23 | * Build up a long term community of people that cares and constantly improve |
| | 24 | boost documentation and tools. |
| | 25 | |
| | 26 | * Achieve an unified look and feel between docs and Boost resources, integrating them as |
| | 27 | much as possible. |
| | 28 | |
| | 29 | * Quality documentation |
| | 30 | [[Br]][[Br]] |
| | 31 | * Make it easier for users to navigate through the enormous amount of |
| | 32 | boost documentation. |
| | 33 | [[Br]][[Br]] |
| | 34 | * Use latest version of standards and support old browsers. |
| | 35 | [[Br]][[Br]] |
| | 36 | * Generate Glue docs. Boost libraries doc are impressive to learn about how |
| | 37 | individual libraries work. However users are missing integration documentation, |
| | 38 | that sees boost as one tied library. How they do common task, which libraries |
| | 39 | are powerful when combined, real life examples; are important documentation we |
| | 40 | can not expect boost authors to provide. |
| | 41 | [[Br]][[Br]] |
| | 42 | * Build a boost version of the SGI documentation allowing us to have a consistent |
| | 43 | and complete documentation of modern C++. |
| | 44 | [[Br]][[Br]] |
| | 45 | * Include nice looking logos and diagrams. Although Boost libraries are so great |
| | 46 | that they do not need any marketting at all, lets face it: people are attracted |
| | 47 | like flies to catchy names and fancy pictures. |
| | 48 | |
| | 49 | * Documentation tools and support |
| | 50 | [[Br]][[Br]] |
| | 51 | * Improve the docs tool chain, simplifying and integrating it lowering the barrier |
| | 52 | for people willing to help us. |
| | 53 | [[Br]][[Br]] |
| | 54 | * Develop tools to automate common task, and to make life easier to boost authors. |
| | 55 | Docs writers should concentrate on generating content and not on figthing with tools. |
| | 56 | [[Br]][[Br]] |
| | 57 | * Work to make doc tools boost-agnostic. We believe that they are useful beyond |
| | 58 | the boost community, and would welcome anyone who wishes to use, extend or |
| | 59 | support them. |
| | 60 | |
| | 61 | * Generate formal documents about C++ documentation best practices. |
| | 62 | |
| | 63 | * Offer our help to libraries authors. This include translations, proof-reading, |
| | 64 | proposing examples and tutorials for their libraries and helping them with the |
| | 65 | docs tool chain. |
| | 66 | |
| | 67 | * Offer a place where not C++ experts can help the Boost community. In general the |
| | 68 | tasks we do here does not involve template metaprogramming or others complex C++ |
| | 69 | machinery. Dessigners, artists, teachers, web experts, Python programmers and Boost |
| | 70 | users are very welcome along our lines. |
| | 71 | |
| | 72 | * Write docs, include rationales, use our own tools. If we want to improve boost docs, |
| | 73 | we should start by showcasing best practices in this project. |
| | 74 | |
| | 75 | * Enjoy our work. If we are not having fun while improving boost docs something |
| | 76 | has gone terribly wrong. |
