[Framework-Team] Re: random thought: identify the components that lack owners

Tres Seaver tseaver at palladion.com
Fri Sep 26 19:04:37 UTC 2008

Hash: SHA1

Hanno Schlichting wrote:

> Tres Seaver wrote:
>> Hmm, as an outsider, the FWT's job (reviewing and accepting PLIPs) is to
>> do what a single BFDL would do in a project would have one.
> It might seem so from a certain point of view. That's however not how it
> has been intended and not quite what the current status is.
> Here's the current situation from my POV (German-style, as in: short and
> not meant to offend anyone, even if it sounds like it):
> In the early days we had two BDFL. One for code, one for UI. The one for
> code got busy growing his company and isn't involved in the core
> development anymore.
> We move on some years, get a terrible experience with the 2.1 release
> and we realize we need to do something. Folks sit down and create the
> framework team. It is intended to be a barrier for inclusion of bad and
> unfinished code into the core.

What about such code, or abandoned code, which is already in the core,
and which would therefore not be accepted today?

> The intended process of how growing Plone should work since the 2.1
> release up until now is officially:
> - Someone writes a PLIP.
> - The community at discusses and generates consensus on whether or not a
> PLIP should be accepted and if it should be included in the core.
> - The submitter writes the code needed and submits it to the framework
> team for a particular release.
> - The framework team decides about the technical merit of the
> implementation and if the goals outlined in the PLIP are met.
> - The release manager for a release is appointed by the foundation
> board. He has a final say in rejecting or overruling the recommendation
> made by the framework team.
> That's the official story so far. The framework team does not have a
> mandate to decide about the general merit of a PLIP, but only on the
> technical one. It is currently a peer-review team. It is only elected
> for one release at a time and doesn't have any mandate to care about the
> long-term roadmap of Plone.
> What we are missing indeed these days is a technical long-term roadmap
> and an authoritative team to set it.

I assumed from my outsider's viewpoint that the framework team had been
given that responsibility.

> Right now various core developers, including me, Martin and Wichert to
> name a few of the most craziest contributers, push some parts into a
> direction at times. I'm officially abusing the lack of an established
> process for Plone SVN trunk to change it to my personal will right now.
> That is easy in the short term but not a good idea in the mid or long term.
> I think we need to address this issue and have an official story for
> "Who inherits the role of Alan". History of open source projects have
> proven, that once a founder has stepped down from being a BDFL there is
> no way to go back to having a dictator again, so we need a team.
> But maybe this only my personal view of the current situation?

It seems to me that not having continuity of architectural vision across
releases, including the ability to remove broken / abandoned components,
is a really dangerous place for Plone to be.

- --
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Framework-Team mailing list