[Bf-committers] Re: Bf-committers digest, Vol 1 #92 - 11 msgs

[Kiernan J Holland]

> For Python in Blender to really work, we need a strict Python board 
> =20
> acting as a watchdog & gatekeeper on the actual implementation. =20
> Preferably a mixed group of diehard coders and actual users of =20
> Blender's Python. At the Python discussion board I already did a 
> call =20=
> 
> for participation  a couple of months ago. I will repeat that call, 
> and =20=
> 
> also now here:
> 
> Anyone interested in maintaining and further improving Python in 
> =20
> Blender? I prefer to make this a seperate project at our =20
> projects.blender.org site. Not only for the current 2.2x Blenders, 
> but =20=
> 
> especially for the future, Python will play an increasingly 
> important =20=
> 
> role... so there's quite some work to do, and honour to gather in 
> this =20=
> 
> job! :-)
> 
> Thanks,
> 
> -Ton-

How about getting the code compiled across all platforms, 
drawing up some diagrams of the relationship of all the 
pieces of code, UML? or chicken-scratch on a napkin, 
then maybe someone could develop design documentation 
describing what what does. Everyone draws up diagrams 
of what they think should happen to the design, and everyone 
arrives at a goal design, and work toward that. 

Bugs are a result of differences in understanding,  if this codebase 
is well documented and described, with all blueprints well maintained and

with a complete understanding of how it can grow more easily, 
I think it will be easier for others to add onto it because they will 
be able to see and understand the intent of the design and that of the
designers. 

How should we determine who those designers should be? Some might say,
those 
who code the most on it should determine the design. This is a good
start. 
I don't suspect it will be done right immediately, because so many don't
understand the codebase. We should ave some scout out the codebase 
and determine good abstraction points, so that others can know what 
pieces can be seperated, then we could come together for a 
grand design meeting and determine which pieces need the most work and 
set up some long term goals for those pieces, I expect we could have one
of these 
meetings every 3 months or whatever seems realistic to individual
projects. 
We should also be able to determine after understanding the design of the

codebase, what code is the biggest bottleneck and eliminate those
bottlenecks 
early on if possible. The focus should be to eliminate as much problems
that 
will cause problems for the design later, now. 

Also to speed progress along, emailing back and forth can produce a 
lot of redundant responses, saying too little in a chat system doesn't 
reveal enough about the understandings one has, I would say a combination

of the two, talk in real-time about things everyone udnerstands, reveal 
personal understandings later in email. What is an optimal method of
interaction 
and can we organize these communications in a way that is the least
redundant 
and the most useful? 

Kiernan