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

Tue Mar 20 11:48:10 EDT 2007

Hi,

On 3/20/07, Martijn Faassen <faassen at startifact.com> wrote:
> 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.

Yup, I know this and I read the code so I was just wondering how to
let others that didn't read the code to know....this is the main
reason of the proposal.

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

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.

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

I understand. That's why I pointed this things even before you guys
noticed and I would help on that part since I can't provide grok
extensions and internal grok understanding...I didn't go that deep
yet.
I think that this transition is also good to show how small and
componentized the result is.

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

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

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

Hehe, When I said *yell* I meant that this was the highest point of the phrase.

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

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

That's correct. You should keep in mind that not only new users will
use it but other developers would use it as well and making a good
marketing of how good the framework is and how easy (documented) it is
to extend.
By knowing where to plug and extend things would attract programmers
that would like to contribute code.

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

>
> I will add some issues to launchpad describing documents we need to
> write over time.

Cool!

Cheers,
Fernando

>
> Regards,
>
> Martijn
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev
>