Re: Sprint: clean up Plone day [was: A few suggestions]

On Nov 27, 2008, at 4:47 PM, Graham Perrin wrote:
>> we could float the idea of a "clean up Plone day". A sprint  
>> dedicated to
>> reimplementing old features in the new ways.
>
> You have floated the idea :) and I like it, very much.

FWIW, there is already quite a bit of consensus among Plone core  
developers that we'd like Plone 4 to be leaner, simpler, and more  
unified in how it does things.  There are even serious efforts under  
way.  For instance, Hanno has been ripping obsolete / unnecessary bits  
out on trunk, Dexterity is coming along as a way to build content  
types that is more modular and flexible than Archetypes, and I know  
various people are brainstorming ways to simplify our rendering model  
so we don't have to think in terms of viewlets or portlets or page  
templates in different contexts.  (Among other things.)  These are  
mostly still exploratory and may or may not make it into Plone 4  
depending on the decisions of the Plone 4 framework team, but I offer  
these examples as evidence that the core developers are aware of and  
trying to solve the problems.  I spent a lot of time at the Plone  
conference talking to people about Plone 4, and I have a lot of  
optimism that we can make it simpler for developers, integrators, and  
end users alike.

There's some careful planning that needs to go into any effort to  
simplify by updating old implementations to use new approaches,  
though.  For example, a lot of people agree that zope 3 browser views  
and browser resources and z3c.form are the future and we should move  
away from skin layers and formlib, but as things stand now that would  
actually result in losing a lot of important functionality,  
particularly in the TTW configurability area (form controller forms,  
the ability to customize non-template resources TTW, the ability to  
add/remove files from a layer without restarting, TTW-configurable  
caching...)  There are ways that support for these sorts of things can  
be added for the new approaches, but before the code is written (or at  
least before it is merged, but I imagine that those doing the work  
would like feedback before they go to the trouble) we need to agree on  
a roadmap for what should happen and make sure that our new approach  
really is better.  (This is just one example; there are plenty of  
other areas of the code also in need of review.  User/group management  
and commenting, anyone?)  I say all this not to discourage anyone who  
has energy to carry forward the areas in need of work, but simply as  
fair warning. :)

I'm starting to ramble, so let me just end with two suggestions:

1. If a "clean up Plone" sprint were organized, I think the most  
effective sprint at this stage would be a brainstorming session among  
core devs to identify more candidate areas for removal or  
reimplementation and a list of tasks needed to make that happen  
(rather than an actual coding sprint.  coding can happen anywhere and  
anytime once the roadmap is agreed upon)

2. If you know how to make Plone simpler, get involved!  Don't wait  
for a sprint.  Write up your ideas on the plone-developers list for  
discussion.  If there seems to be consensus, do the work to implement  
the changes and PLIP it for inclusion.  Plone belongs to all of us,  
and just as with the docs, the code only gets better when people  
volunteer their time and effort and make it happen.

> I assume that we can encourage greatest publicity/involvement  
> without risk
> to quality of code.

Improving our overall test coverage should probably be a goal  
alongside any reimplementation efforts.

> Already we have at least, amongst the PLIPs accepted for 3.3:
>
>> #241: Clean up auto-sort, auto-order code
>
> <http://plone.org/products/plone/releases/3.3>

I think Hanno already ripped this out on Archetypes trunk.


David Glick
Web Developer
ONE/Northwest

New tools and strategies for engaging people in protecting the  
environment

http://www.onenw.org
davidglick-PRw/[email protected]
work: (206) 286-1235 x32
mobile: (206) 679-3833

Subscribe to ONEList, our email newsletter!
Practical advice for effective online engagement
http://www.onenw.org/full_signup





-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/