[Framework-Team] Now what do we do?
optilude at gmx.net
Wed Aug 30 09:09:30 UTC 2006
On 8/30/06, Raphael Ritz <r.ritz at biologie.hu-berlin.de> wrote:
> Hi folks,
> first, with respect to the process: I agree with Martin that
> each of us should take responsibility for about three PLIPs.
> I also support the proposal to have a comment trail in the
> bundle. Let's agree on a common name for the file: I propose
> to call it: REVIEW-COMMENTS.txt (or stx?) and have it
> in plain text (or rather structured text?). Other suggeetions?
> Now, here is what's most appealing to me (i.e., which I offer to take
> responsibility for):
> - PLIP 112 - XML Import / Export
> - PLIP 148 - Move to CMF 2.1
> - PLIP 172 - Wiki syntax support for all content
+1 - up your alley.
furthermore I offer Martin to help review in detail
> - PLIP 119 - Contextual help
Please - I was beginning to think I may have taken on a bit much. ;) Let's
look at this together.
Other comments from me at the moment: I think
> - PLIP 8 - Versioning
> - PLIP 122 - Edit-in-place mode for all basic field types
> - PLIP 145 - Locking
> - PLIP 168 - integrate iterate for checkin/checkout/staging
> should be looked at in concert if possible because I'm afraid there
> might be some incompatiblities to deal with (at least Kapil told me
> once that he had problems in iterate with my locking approach)
Ah - could you take the lead on talking to Kapil about this? I'm guessing
you're the one who understands the locking work the best at this point.
CMFEditions, Iterate and your locking work from Norway would be things to be
incredibly proud of in 3.0. I'm quite sick of making the "Plone kinda
supports versioning/locking/staging, well, er..." argument. :)
In a similar vein, I think it'd be useful if we had one person who took a
look at the versioning, locking, and iterate bundles, since they are likely
to require some co-ordination.
Last but not least, I agree with what has been said about Bling/KSS/AZAX,
> namely that we should strive for an early decision and merger. Basically
> all UI improvements are stuck at the moment because it's not clear what
> to base an implementation upon (e.g., our locking stuff could benefit a
> from more responsiveness/asynchronous updates but the only AJAX part
> we've put in there up to now was implemented at the lowest possible
> level which I would not like to repeat).
I'll make this a priority. I doubt I can get anything together before the
weekend, but expect a detailed email from me then. :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Framework-Team