Translations of this page?:

Outline for future technical documentation

This document is intended as a starting point for a better technical documentation of the Feng Office project. For now I'm collecting suggestions for intended chapters, trying to learn from examples by others, gathering best-practice examples.

Please consider this a work in progress, currently no more than a brain-dump. Don't expect to find polished and usable documentation here yet; but you are welcome to add to the documentation and improve it! I'd also welcome more suggestions and criticism. I'd suggest comments should be inserted using signatures so we can follow the discussions - max wolf 2009-04-14 16:02

Style Guide for technical documentation

firstly, let's try to set some standards for how to do code writing within this wiki.

  • links to howtos about good technical documentation (cp. phpDocumentor Guide to Creating Fantastic Documentation
  • How to spell Names, how to create and where to store screenshots, how to format the documentation. What needs to be documented, how, and where? What's better left to the forums, what should rather be posted to Feng Office?
  • wiki standard text blocks and disclaimers
  • asset collection: Logo (don't forget the Hi-res version for magazine print;), typeface, basic “Corporate Identity” design style info.
  • copyright notes for technical documentation

History & Community & miscellaneous

some of this is featured on the start page, briefly, but perhaps could be elaborated upon a little more. — max wolf 2009-04-14 16:10

  • How did the project come to be? (perhaps a little interview with the developers similar to the project of the Month Interview at SourceForge.)
  • what Feng Office is based on, and what the developers' vision is.
  • what is the developer team like?
  • how can I participate?

Getting Started - prerequisites for development work on Feng Office

It may not be entirely desirable to open up development of Feng Office for the masses, as it may lead to chaotic branching which could detract the core team from doing their work. On the other hand if this is so then that should be mentioned. I leave that up to discussion. Either way I believe it would form a great quick-start entry point for new developers.

  • Before you write your own extensions. how to discuss a wanted extension before you start; how to submit bugs and feature requests
  • what is your development environment like? what IDE to use? devs - what do you use? What would you recommend (a newbie)?
  • how to connect to the subversion sources? what is on sourceforge, what is elsewhere?
  • Debugging Feng Office how do you do it?
  • Clean Coding - what makes a good extension? How to release a patch or plugin. What do you need to do to have your extension included in the next release.
  • Documentation template (cp. here )
  • Where to find help

Code Examples

learning by example. What other examples would you like to see? Anything you have already prepared but just needs a little rework??

  • Hello World Application
  • Database access
  • using templates
  • an overview page widget
  • I18N - a concise localisation guide

Work in Progress

To a certain amount this doubles the announcements sections and some other areas of the Forum, other parts of this would better be kept in a bug tracker. However this could make sense as it basically would summarize the 'authoritative view' as seen by the core development team.

  • Features demanded and in production. what do you currently work on?
  • bug tracker / open issues. / you dont really use Sourceforges bug tracker, do you? There's hardly any activity there. Anything else then?
  • Road map. I remember having read on the forums that you'd like to write one-if you find the time. Really, I think a public roadmap is pretty important for the general audience to judge the aliveness of a project
  • dev log. or is there another place for that already?

Reference

This is probably the most important part. We could at least have JavaDoc Style documentation (Automatic documentation) see DOXYGEN, JavaDoc etc. (Comparison of Documentation Generators)

Other Sources

external documentation for tools and libraries used in the project.

  • documentation of the EXTJS Javascript framework
  • documentation of FCK Editor
  • documentatin of the mail application

Various Ideas for Documentation (non-technical)

doesn't belong into the developers' chapter but I'm collecting that here anyway so that i don't start too many construction sites.

. . . .. … to be continued.

Discussion

PLEASE NOTE: Comments to the wiki should only contain suggestions and questions that help us to improve the manual (and not the software). These comments will be deleted as soon as the information has been integrated into the manual.

Posts that do not contribute to the DOCUMENTATION of the project will be DELETED.

Ask QUESTIONS on the product here.
Report BUGS here.
Propose NEW FEATURES here.


fen, 2010-07-14 00:25

we are working on the OGOO, however we meet so many problems, espacilly about the speed. Does the AJAX slow down the system's speed? Can somebody help us? Thanks!

Marcos Saiz, 2010-07-14 10:09

This looks like a question for the Questions Forum Board

Enter your comment
 
developers_documentation_scrapbook.txt · Last modified: 2013-02-27 18:06 (external edit)
 
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 3.0 Unported


Terms of Service | Privacy and Security policies | Copyright © 2018 fengoffice.com