[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
other.
> 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
approach.
Members do demonstrate a good sense of whether Plone timelines fit
with their personal workloads, and do speak up when things become
unrealistic.
More information about the Framework-Team
mailing list