[Framework-Team] Re: Re: Release roadmap for 3.0

Martin Aspeli optilude at gmx.net
Thu May 11 19:05:32 UTC 2006


On Thu, 11 May 2006 17:34:33 +0100, Alec Mitchell  
<apm13 at columbia.edu> wrote:

> Actually I think an early PLIP freeze and an initial PLIP review is a
> very good idea.  It will encourage developers to fully form and
> document their ideas before going off half-cocked with an
> implementation.  It will allow you guys to have a peek into the
> implementation ideas, offer some guidance in that area (probably not
> formally as the FT, but it's likely that some of you will be
> interested/disgusted enough in some proposals that you may want to
> offer some advice), and possibly veto some proposals that don't make
> much sense from a high-level perspective before too much time has been
> sunk into their implementation.  IIRC, there was a PLIP freeze for
> 2.5, and though our phone meetings often went a bit off track during
> that period, it was valuable IMO.  This may also accomplish some of
> the goals that Martin seems to be concerned with.

I think such a procecss would go a long way towards giving the rest of the  
community some transparency and direction, and will probably even act as  
encouragement for people to Get Things Done (tm).

> P.S.  I think Hanno makes an important point in another post that the
> members of the FT should not have to be people concerned with the
> details of the "future" of plone in the way that Martin and limi so
> clearly are.

Mmm.... I just like to voice my opinion. :)

> I, personally, think that those things tend to work
> themselves out in a number of different ways without the need for
> rigid structures or formal bodies(either from semi-formal declarations
> at sprints (a la limi), or via individual encouragement of existing
> projects, or with funding from from an organization which needs a
> particular feature, or even just through the persistent work of a
> motivated developer).

I think to a large extent, this is true, and there is a real danger of  
choking creativity by imposing too much structure. In fact, I think Plone  
does this balance very well.

Where I think we are in danger of under-delivering, is to the people who  
are peripheral contributors, possibly with a lot of knowledge, skill  
and/or time to share, who need some guidance and some direction. A lot of  
the new sprinters from Norway, for example, would fall into that category.  
When they ask, I'd like to work on this, is it a good idea, should I spend  
my time on this? ... what do we say to them ... and who says it? Or one  
step further up, someone wants to sponsor the community (think Goldegg) -  
where do I put my money? We need a unified response to something like  
that, that ensures they don't just throw their money away, and that they  
get tangible results. And nine times out of ten, that means having their  
software adopted into the core or as a "blessed" add-on product, with  
support from the wider community.

So, my reasoning went ... if the framework team are the ones who will make  
the short-term decision on whether any code produced through either  
volunteerism or philanthropy or direct investment, isn't it a bit  
dangerous to stay completely out of those kinds of debates? And would we  
be able to be objective, even if we tried?

Martin


-- 
"You can just adapt yourself out of it..." // Archipelago sprint 26/04/2006




More information about the Framework-Team mailing list