[Grok-dev] Re: Developers area in grok.zope.org
faassen at startifact.com
Tue Mar 20 08:03:03 EDT 2007
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.
More information about the Grok-dev