[Framework-Team] Framework Team: ways of working: possibility of change

Graham Perrin G.J.Perrin at bton.ac.uk
Thu Dec 18 15:34:00 UTC 2008

On 18 Dec 2008, at 13:40, Helge Tesdal wrote:

> UI team:
> The team dealing with User Interfaces, Accessibility, XHTML, CSS and  
> ECMA/Javascript.
> Framework team:
> Responsible for feature evaluation and general guidance on  
> architectural decisions. The Framework Team reviews and suggests  
> features for inclusion in releases.

My initial reaction to the quotes from Helge: I recalled some past  
indication that for the Framework Team, things may be subject to change.

Raphael saved me the trouble of searching the list :)

On 18 Dec 2008, at 14:22, Raphael Ritz wrote:

> an expectation that the way in which the framework team is going to  
> work might change (and I stress this is an expectation by some at  
> this point - no clear cut decisions yet. And yes, that can be  
> criticized.).

No criticism from me.

To know that change may occur is sufficient.

> Rather than having team members with different domains of expertise  
> taking care of different aspects of PLIPs it has been suggested that  
> framework team members act more like editors of a scientific journal  
> meaning they can decide on acceptance if they feel comfortable with  
> the decision but they usually ask for advice from respected players  
> in the field. This can take any form in principle.
> Here, my expectation is that team members may choose to bring up  
> whatever they think needs to be considered - either on the dev list  
> or by actively approaching someone they trust. They take the  
> responsibility for the decision they make but they don't necessarily  
> do the work of reviewing and evaluating everything themselves.
> It is still not an easy task as people can fail to address the right  
> issues in the first place but I do have a strong trust in the  
> appointed team that they will do their best

I share that trust.

> also when it comes to UI evaluations

I share that trust.

> and improvements as well as to documentation matters.

My gut feeling is that *documentation* may be, occasionally, a thorny  
issue. Thorny within or without a PLIP context.

(I am neither criticising the past/present, nor predicting a future  
failure. Simply being realistic about the very different paces at  
which code and documentation change.)

I do not propose that Framework Team membership be reviewed with an  
additional focus on documentation.

It's enough that the relevant teams are in communication with each  

> Sure enough we don't know yet whether this will work as expected but  
> at least I do see a chance that this could even be better than  
> having one or two (usually very busy) UI experts on the team who are  
> expected to look at each and every PLIP with respect to UI issues.

Sharing the load, whether formally (in a Team structure or Team  
process) or informally (as we are doing now) strikes me as a fine  

Members do demonstrate a good sense of whether Plone timelines fit  
with their personal workloads, and do speak up when things become  

More information about the Framework-Team mailing list