[Grok-dev] Re: Developers area in grok.zope.org

[Martijn Faassen]

Hey,

Fernando Correa Neto wrote:
> On 3/20/07, Martijn Faassen <faassen at startifact.com> wrote:
[snip]
>> Potential beginner task: If you (someone reading this post) are fairly
>> new to Grok (and who isn't; it's not that old yet :) and you think you
>> have a handle on how Grokkers work, please write it up!
> 
> I am all for this!!
> I would review some code and post it first in the list to hear someone
> else's opnion and from that create the document.

That would be excellent! I'm happy to help here: posting it to the list 
sounds like a good start.

[snip]
>> We have a loose band of Grok core developers (more or less the
>> sprinters, or at least those active on the mailing lists at any point in
>> time :). Two or three core developers tend to reach consensus for the
>> wider development of the Grok core. This works well enough for now, as
>> we know each other and can communicate well. I think this pattern will
>> last us for a while, with a fluctuating membership of the core group.
>>
>> Eventually we may have to go a bit more formal (but not overly formal)
>> and move to a model of proposals like we have in the Python, Zope and
>> Plone communities. We may also be a bit more formal in the way we reach
>> consensus. No hurry yet, though, I think. Too much process too early
>> means risking killing our momentum.
> 
> Agreed. I don't consider this formal but as you guys go thru this
> process, you wont have time and patience to do this even though you
> love it.
> Maybe people get interested by squeezing developers for information
> and will write about it and with the consensus of the developers,
> publish it.

I'd be very happy to support this process. We can collect the technical 
documents in Grok's 'doc' directory (after review on the list and some 
editing, perhaps), and also publish them on the website in a developer 
section.

>> What do you think would improve your understanding of the process?
> 
> We need a good use case for this. I would be interested in implement
> say a X feature.
>> From here we need to collect information on what part of grok is
> responsible for registering new components that address the requested
> feature.
> For a developer standing point, I think one would go and look at grok
> core and if something is not there yet, will need to bring it from
> zope3 and create all the necessary layers in grok to generalize it and
> make things possible.
> I myself believe this is the simplified process (correct me). So how
> to expose it in a way that newcomers can follow this pattern?

Yes, I think that this is the process, but one point needs to be made 
very explicit: Grok is about exposing Zope 3 features and patterns in a 
way that makes it easier for developers. We look for common patterns in 
typical Zope 3 designs and think about ways to make them quicker and 
easier. The 'quick and easy' bit is very important.

I think this typically involves some discussion (on the mailing list, 
irc, or during sprints), or prototype implementation on a branch or in 
an extension.

[snip]
>> > So why not have a area for DEVELOPERS so they see how to improve the
>> > code and follow a direction for this having a look at the entire
>> > process AND have they code from other projects working faster? IOW,
>> > how to plug things in grok.
>>
>> We definitely need some technical introduction. I also think we may need
>> some description of the contribution process (what to do if you want to
>> add a feature to grok?). Finally I think you're also asking about the
>> goals and philosophy of the Grok project, so that it becomes more clear
>> for new people to help move Grok forward.
> 
> Yes, the only thing that I see in the site right now is that it is
> easy and simplified and it uses on zope3's CA.

We need more text, clearly.

> I saw the Europython framework shootout and saw Philipp between Kevin
> Dangoor and Simon Willison and at some point Philipp pointed that he
> should not be able to do a wiki in 20 minutes because zope3 was not
> made for it and he would probably need to bring zope3 down in order to
> accomplish it.
> What you say about grok? ;). I know this is not about competition but
> grok will naturally deliver this.

Clearly Grok is not about winning these competitions, but Zope 3 not 
doing well in such a competition is a symptom of a broader problem. 
Hopefully we Grok we can do better in such a shootout in the future.

We saw a lack in Zope 3 in that it doesn't scale down for a longer time 
in the Zope 3 community, and Grok is trying to fix this. In fact I 
started the first serious work on Grok's design a few days before that 
EuroPython started. I had a day all by myself and wrote some texts, and 
then Philipp came in and I talked to him about it. Later we had a bit of 
a brainstorming session with Jim Fulton and others. After EuroPython I 
did some more thinking and writing, and at the DZUG conference I got to 
talk to Christian Theune about it, and he organized the first sprint. 
(we can use this for a history of grok document, Martijn's view :)

> Things I notice in both Django and TurboGears. They were made to be
> agile when developing new web applications. In grok, it could be truth
> not only for new webapplications but for the core extension as well.
> ...well, this is what I would like :D.

You mean we should be agile in how we develop Grok and its extensions 
themselves? Anyway, Grok is about agility in developing web apps too. I 
think we have a good infrastructure to make Grok easy to extend (with 
the grokkers), helped because Zope 3 itself has a great infrastructure 
for this (the component architecture).

[snip]
>> Thank you for this mail. I think it's pointing out a weakness in our
>> project communication that we'll work to improve. Of course, to improve
>> our communication we do need to have people writing. We're slowly
>> improving this; as you'll have noticed we now have a naming convention
>> document. :)  Don't expect an instantaneous result!
> 
> I don't expect any instantaneous result because I know how hard to
> write documentation is. I am up to help and maybe get things done in
> this area.

Your help would be much appreciated!

Regards,

Martijn