I kind of have a rule... you don't mess with someone else's code UNLESS your change is unquestionably and undeniablly a noteworthy improvement. You should not really feel a need for anyone else's approval... just be honest and truely self objective. While I think it is fine, even encouraged, to play with a known (read: someone else's working code) in the process of one's personal growth, you really shouldn't expect to be fawned over every single line modifcation, that primarily amounts to opinion (the result of awarding participation tropheys, I suspect).
Your time would best be spent creating something all of your own, addressing a topic that has yet to be explored. Being proficient at writing GF configs takes a little creativity, and a huge amount of personal commitment. Not only do you need a technical understanding of programming, you need to be comfortable devising your own debugging techniques (to say nothing about a reasonable foundation in analytical geometry). There is only one definitive source of documentation, and that is the code itself... try it... it either works or it doesn't.
The documentation that does exists, is terse, but correct for the most part. GF went through a pivotal change when VectorC was ported. It offered alternate coding paradigms, which that are for the most part, completely undocumented... The secrets are only revealed through the scrutinization of other's code, sweat, and a lot of frustration. Don't get me wrong, the implementation is generally elegant and consistent, and much can be extrapolated from the examples that do exist... BUT UNDERSTAND, NO ONE IS OUT THERE TO HOLD YOUR HAND... (it ain't gonna be ME anyway). I will be happy to address specific questions/problems as time permits... just don't expect any "attaboys"
That said, I anxiously await to see what you are capable of creating on your own, and prepared to be WOWed!
