[Grok-dev] Re: Organizing the further development effort

[Uli Fouquet]

Hello Grokkers,

On Fri, 2007-05-25 at 10:28 +0200, Philipp von Weitershausen wrote:

> Not a bad idea. Note that Google is paying two students to spend serious 
> time on Grok documentation. 

That's right. I am one of the students and this might be a good
opportunity to introduce myself in brief and say "hello" to all of you.

I am living in lovely "Rheinland" (the area around Cologne) in Germany,
currently doing my Ph.D. in cultural studies at the University of Bonn.
Nevertheless I got the permission from university to participate in the
Google Summer of Code and am quite excited about this chance to get in
touch with all those famous brains in the grok development team. It
would be really great, if I could help grok to become even more popular
among users, developers and also in companies and organizations.

My project's primary aim is to implement an improved admin-UI for grok
as well as improving the documentation. My mentor is Philipp von
Weitershausen. It is of course an honour for me to work with Philipp.

Please allow me to give you a short overview of what is planned from my
side. Comments, corrections and hints are very welcome.

Concerning the admin-UI:
------------------------

 * Features to implement (must):

    + Nice(er) looking GUI (the HTML/CSS stuff)

    + Possibility to manage application objects:

      - Add application objects (already possible, maybe some more
        information about the possible applications in advance?)

      - Remove application objects (even in case of 'broken objects'?)

      - Rename application objects

      - Introspection of application objects

    + Management of applications'/components' contents:

      - Possibility to "traverse"/browse contained objects

      - Display contained objects

      - Remove contained objects

      - Introspection of contained objects (depending on type/interface)

    + Interface for general tasks:

      - Start/stop/restart zope3 instance

      - Debugging information (trace-backs, etc.)

 * Features to implement (nice-to-have):

    (see above ;-)

Concerning documentation:
-------------------------

 * Reference:

    + Build a list of things to document (components, attributes, 
      decorators etc.) in a nearly automagic manner, incorporating
      existing doc-strings (partly done).

    + Check for consistent formatting.

    + Fill in the 'gaps' in the reference.

 * Tutorial:

    + Build a list of missing topics to cover.

    + Write text (maybe incorporating examples from various sources?)

    + Check compatibiliy of HTML version with most common browsers 
      at least FF/IE/Safari

The list of topics to cover in the tutorial unfortunately might become
endless. Here some restrictions might apply. From what I learned lately
on public grok-sessions with the local Zope user group, people are eager
to work with forms (formlib) and always try first to implement a nice
"framework" for their applications, say: they want breadcrumbs, logos
and navigational elements. Some even first ask for AJAX-support ;-)
Though IMHO these are not (at least currently) core elements of grok,
the tutorial might cover such things as well more in-depth. 

I am currently doing a rewrite of some talks I had the chance to give,
explaining formlib-forms with grok and some minor things yet not seen in
the tutorial. This might (partly) become obsolete, when a customization
of Stephan Richters cool new forms package should happen.

I might check in all the documentation and admin-UI-stuff into the
svn-repository (in a separate branch, of course) as soon as some
preliminaries have been checked.

> But we can't have enough docs...

That's right as well.

> > Maybe it would also be possible to outsource the docs writing so as to 
> > get a reasonable bang for the buck, say in India, Polen, Russia, or the 
> > Baltic states.

Well, as already said: Google pays us also for writing docs (although I
would love to do this project even without being paid). But anyway: the
more the better.

> The problem is that we need somebody who's familiar with Grok, and we 
> need decent English, which limits the set of people.

This indeed is a problem. I know that my English is very limited, but
more important from my point of view is the need for some folks really
experienced with grok to eliminate errors in respect of content. In the
end someone must read the stuff, who is able to identify lies. I am
personally very happy, that Philipp promised to have a look at my
documents/code/lies.

I hope this was not too off-topic, but Martijn told us students to make
noise. So, ehm, here you got some ;-)

Kind regards and many thanks to all developers, writers and
contributors, which let grok happen!

-- 
Uli