Geeklog Forums

How do I help on documentation for Geeklog 2? I was at the project resources/geeklog 2 wiki site and kept reading up on how important documentation is. I would dislike to rewrite what is written already and would like to know how (technical) a writing style is wanted... I've got broadband so downloading 100+ megs a day is a breeze in case its needed. I also work on Windows XP and know how to handle 2 or more Geeklog installations on my own machine. I don't know php all that well but I believe I can help document installation, configuration and user functions as needed in layman terminology. I also took up a quick study on clear english. How do I stay updated on helping Geeklog 2 create and maintain better documentation? Thanks

---

Victor B. Gonzalez -
http://aeonserv.com

Count me in on this as well. I am good at editing and formatting for consistency.

From what I've read, GL2 will be the backbone and all functionality will be done through modules. GL2 isn't far enough along to even release an API to the module developers so they can start work. User documentation like you want to do (installation, configuration, and user functions) normally comes much later because developers could totally change or scrap portions originally envisioned. I don't mean to discourage you, but if you start writing too early on some things you'll be faced with having to completely rewrite them and possibly multiple times. Documentation on areas like code functionality and API should be done early and then throughout. The areas you mention should be done later after they've been developed and gel more. Rather than jumping right into GL2, why don't you try your hand at improving some of the current documentation?? Maybe focus on some areas that would apply to both the 1.3.x series and GL2.

Good points. One note, we are using PHPDoc in the GL2 code so all API and code documentation will be done through it OR in the code itself. There shouldn't be any need for 3rd parties to expand on that documentation with the sole exception of any interfaces we may build (e.g. the module interface or any SOAP/XML interfaces).---The reason people blame things on previous generations is that there's only one other choice.

---

The reason people blame things on previous generations is that there's only one other choice.