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

[Martijn Faassen]

Hey,

Let me go through this to try to understand what your goals are.

Fernando Correa Neto wrote:
> I was reviewing the grok site and since I know grok is still in early
> ages, there are few pages about the project...actually two pages: home
> and tutorial.

> I've seen in the last posts people are getting eager and eager to
> improve grok and pushing even more stuff into the core.

I'm very happy to see people's interest in contributing to Grok. Grok is 
pluggable: the mechanism to plug things into grok is to make a megrok.* 
package. Grok also has a core that can be extended. We need to weigh for 
each feature whether it makes sense to support it in the core, or 
whether it's better off as an extension. Some extensions may of course 
eventually make it into the core.

> Thinking of this I was wondering if we could have a "Developers Area"
> or "Groking Grok" or a "Grokers Area"...I don't know.

Where you want information on how to contribute to Grok? One thing it 
should contain is technical information.

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!

> Since in the mailing list things are going too fast between the
> discussion and the implementation, I wonder if there is a standard
> process for it or if it is good to have one process to improve grok.

Besides technical information, you're also asking for an understanding 
of the process.

Currently we do not have a formal process. Most major decisions 
concerning Grok were made at the two Grok sprints, where we had just 4 
or 5 people participating. Even when we were hacking in between, Grok 
was still small and the core group limited.

That was a good way to get started, but it's not going to sustain us on 
the long term. We're now in the process of transitioning to a model of 
public, mailing list/irc channel driven development. I think we should 
be careful we don't go too heavy in process overall now. Let's spell out 
what we have now.

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.

What do you think would improve your understanding of the process?

> I realize this due the last discussion  about JSON integration into
> the core and someone yelled that this is good to integrate because
> other USERS could migrate from TurboGears and use it right away.

That someone was me. :) I wasn't trying to *yell* this.

> 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.

> This would be good to expose the zope3 codebase behind grok as well.
> The code is often small and just tie things together so a experienced
> grok developer would introduce another  developers into the core and
> possibly make them love it just like users do.

I'm not sure I understand you well, but you'd like some introduction of 
the structure of the technical structure of the Grok project. I think 
this would be up, and ties very closely to the description on how 
grokkers work before.

> I am pretty sure some areas are going to be integrated soon like
> Viewlets and JSON so maybe it is a good opportunity to do this and
> future implementations like REST can follow the same pattern.

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 will add some issues to launchpad describing documents we need to 
write over time.

Regards,

Martijn