Re: [Framework-Team] framework team meeting notes
Hey- Congrats to all on landing plone.app.event. that is a really big deal that has been a long time in the making! -Jon On Oct 23, 2013 7:43 AM, Rok Garbas r...@garbas.si wrote: Quoting Nathan Van Gheem (2013-10-22 21:27:58) https://docs.google.com/document/d/1kAP7XtycVQSZDUh3SS9_NJ6r-XMfZ0bkpouc7qJse9g /edit?usp=sharing feel free to add info. sorry guys for not showing yesterday. we lost internet at jsmeetup we had yesterday and i couldnt get it work in resonable time. i'll get my votes in today and i'll write a separate email about widgets integration with coredev. -- Rok Garbas - http://www.garbas.si ___ Framework-Team mailing list framework-t...@lists.plone.org https://lists.plone.org/mailman/listinfo/plone-framework-team ___ Framework-Team mailing list framework-t...@lists.plone.org https://lists.plone.org/mailman/listinfo/plone-framework-team
Re: [Framework-Team] Plone roadmap
On Fri, Oct 22, 2010 at 12:07 AM, Martin Aspeli optilude+li...@gmail.com wrote: On 21 October 2010 22:55, Chris Calloway c...@unc.edu wrote: On 10/6/2010 2:17 PM, Jon Stahl wrote: We already have mass upload, via collective.uploadify. We seem to have at least some work on mass download, via http://plone.org/products/zipfiletransport I'm sure both could use refinement. And search/replace-all TTW. http://plone.org/products/goreplace Seems like all of these could benefit from some attention/love/polishing/PLIPing. These are all add-on products, not Plone. Plone already does these things via WebDAV. Taking WebDAV away means taking this function out of Plone and having to install products to get the function back, which leads to pain when products stop getting attention/love/polishing as they do. And these kinds of things are core to content management, not really add-on behavior. I think the point was that *if* we decide to (have to?) drop WebDAV support, we'd need to integrate these products or something like them into Plone proper as a replacement for functionality we currently support in the core. Exactly. :-) By PLIPing I meant writing a PLIP and doing the work necessary to polish these to the standard of quality necessary for inclusion in the core, if that is possible/superior to reimplementing from scratch. :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
On Wed, Oct 6, 2010 at 8:34 AM, Chris Calloway c...@unc.edu wrote: On 9/26/2010 11:42 PM, Alan Runyan wrote: Maybe think about killing WebDAV when we have these features: Offline editing, magical wysiwyg blobby editing controls. And mass upload/download:import/export of images/files/folders TTW. We already have mass upload, via collective.uploadify. We seem to have at least some work on mass download, via http://plone.org/products/zipfiletransport I'm sure both could use refinement. And search/replace-all TTW. http://plone.org/products/goreplace Seems like all of these could benefit from some attention/love/polishing/PLIPing. :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Three PLIPs ready for review
On Sat, Aug 28, 2010 at 7:41 AM, Eric Steele ems...@psu.edu wrote: On Aug 28, 2010, at 10:19 AM, Martin Aspeli wrote: Hi, The following are ready for review: https://dev.plone.org/plone/ticket/9472 - plone.app.registry https://dev.plone.org/plone/ticket/9473 - z3c.form https://dev.plone.org/plone/ticket/10856 - plone.testing I just want to comment that I am *very* impressed that we have reviewable PLIPs for 4.1 before 4.0 is formally out the door. Nice work, Martin! :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 5 - rough roadmap
On Wed, Mar 24, 2010 at 2:38 AM, Martin Aspeli optilude+li...@gmail.com wrote: Geir Bækholt wrote: On 23-03-2010 22.52, Alexander Limi wrote: +1 to xdv as long as it gets a decent new name. ;) YES! — And let's make sure to rename it soon, before it gets widespread mainstream acceptance If someone has a really great name, I'd consider it, but I think the ship may've sailed. Renaming now is likely to cause a lot of confusion. How about something very simple like Theme Builder? (collective.themebuilder). Short, says what it does, sounds approachable. We can pretty easily refer to it as Theme Builder (formerly XDV) for a little while. What I learned in the last year at Groundwire (formerly ONE/Northwest) is that changing the name of something is easier than you'd think, if the thing you're renaming is something people like and want to work with. :-) :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: A suggestion to egg on add-on product authors
On Thu, Mar 11, 2010 at 7:12 PM, Alexander Limi l...@plone.org wrote: On Thu, Mar 11, 2010 at 4:24 PM, Eric Steele ems...@psu.edu wrote: On Mar 11, 2010, at 8:00 PM, Eric Steele wrote: Thanks, Jon! I'll take care of this tonight. :) Eric On second thought, I'll hold off on this until we have installers available. Good move. Nothing is more frustrating to people than not having installers. :) Agreed, this is wise. :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] A suggestion to egg on add-on product authors
Bravo! Eric, can I suggest that you take the opportunity of the beta release to send out an email from The Release Manager to the wider Plone community in which you specifically remind add-on product developers to test and update their add-on products, provide a link to the upgrade docs (which already exist, right?) and celebrate the significant number of add-on products that are already Plone 4-compatible? Here's some rough-draft text to get you started -- I just think that you're the most authoritative (read: shame-inducing) messenger. ;-) This should probably go to developers, users, product-developers. Maybe even plone.org/news. best, jon = Plonistas- Plone 4 beta 1 is now out. It's the culmination of months of hard work by dozens of Plone developers -- what we'd originally envisioned as a boring release is now without question the most exciting release of Plone ever: faster, more beautiful and easier to use than ever before. Thanks to all of you who've made it happen! As we enter the beta stage of our release cycle, our focus shifts, splits and widens. We need everyone -- not just core developers and framework team members -- to start testing the beta in as many routine and not-so-routine ways as possible, to find and document bugs, and to join the core developers in making fixes. Fixing bugs is a great way to make your first contributions to the Plone core. Perhaps even more importantly, it is time to focus on testing and updating add-on products for Plone 4. Most products will require only minor changes (if any). We've quietly made a great start on this already -- Plone 4 already has more compatible products at the beginning of the beta process than any previous Plone release! But there is much more to do. If you're the author of a Plone add-on product, your to-do list for the Plone 4 beta cycle should include: 1) Test your product against Plone 4 2) Make any necessary changes -- see http://plone.org/documentation/manual/upgrade-guide/version/upgrading-plone-3-x-to-4.0/updating-add-on-products-for-plone-4.0 for a detailed overview of the handful of minor changes you need to make -- including tips for updating themes. 3) Tag a new release of your add-on product and upload it to Plone.org. Be sure to set its version compatibility so it shows in the search at http://plone.org/products?getCategories=getCompatibility=Plone+4! Kudos to the many folks who've *already* released Plone 4 compatible versions of their popular products, including: Steve PloneFormGen McMahon David Various Groundwire Products Glick David PDFPeek Brenneman Ralph Classifieds Jacobs Luca custommenu.factories Fabbri Espen SubSkins Moe-Nilssen Nathan PloneTrueGallery Van Gheem Niteoweb Roberto Various Themes Allende Malthe Collage Borch Manubu c2.transform.office Terada Wojciech collective.disqus Lichota G. qiPortletTagClouds Gozadinos ... and more -- see the full list at: http://plone.org/products?getCategories=getCompatibility=Plone+4 Thanks for being out ahead of the curve! If you're an everyday Plone user, you can help by installing Plone 4 beta 1, testing your favorite add-on products, and reporting bugs to the add-on products issue tracker at http://plone.org/products. If you're not already on it, the Add-on Product Developers list is a great place to discuss add-on product compatibility and updates. http://plone.org/support/forums/addons ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Notes from Joel on simplifying Plone
Hi FWT! Per a brief conversation in #plone-framework tonight, I remembered that back in October, while I was on sabbatical, I actually got around to interviewing Joel Burton about how he thinks Plone could most effectively be simplified for greater approachability. For what it's worth, here are my somewhat-cleaned-up notes from that 2-3 hour conversation. I hope it's helpful to you. I know that some of it is already a little bit out of date (woohoo!). best, jon - Since 2006, Plone has gotten vastly more powerful and flexible, but it has also become more complex and harder to approach for new site integrators. This is not a new observation. Most of the increased complexity stems from our past choices to adopt new technologies that we didn't build ourselves, without adequately considering how well they fit our average integrator's knowledge or skills. In many cases these new technologies offered considerable benefits, but also had significant missing features or confusing/awkward aspects that we failed to address. The good news it that there are fairly straightforward ways of addressing most of these issues. The result will be vastly increased satisfaction for the vast majority of our everyday site builders, and renewed energy and enthusiasm in the Plone community. Joel Burton and I spent a few hours talking about some of these issues, and came up with the following list of challenges and opportunities. 1) Viewlets and viewlet managers. While viewlets and viewlet managers provide some clear benefits to add-on product authors, they are very clumsy and confusing for more basic theming tasks. The biggest specific problem is that our current design doesn't allow us to move viewlets between viewlet managers without writing code and ZCML. This makes a complete through-the-web viewlet manager like GloWorm impossible to realize. We need to rethink the design of viewlets (in a backwards compatible way) so that a tool like GloWorm can move viewlets, create new viewlets and customize existing viewlets through-the-web, THEN dump the results to a disk-based product. We believe that this kind of workflow would transform average integrators' loathing of viewlets into love. 2) ZCML-wired page templates It is currently too difficult to override a default Plone template. We need to have a mainstream, best-practice way wire-by-name way to add new templates, override templates in themes (layers) and override things that are already overridden. Jbot is a good portion of the way there, we don't know if it can go all the way, but we certainly hope so. We need to move this type of solution to the front and center of our template customization story. 3) Product installation with buildout Buildout offers many benefits, but also presents a learning curve for new site integrators, especially w/r/t add-on product installation. Some specific challenges and ideas for improvement include: - There's no obvious, easy way to find out the name of an egg from the product listing on Plone.org. This is easy to fix in PSC. - The redundant need to add many products to both eggs and zcml is very, very confusing and frustrating to new users. With Plone 3.3, we finally have the capability to use autoinclude, but we have to aggressively get product authors to update their products to take advantage of this capability, or else sprint through the collective and do it for them. Let's get this done! - Right now, if buildout fails (e.g. because it can't download something), it often kills your existing site. That's not cool. Even some basic sanity checking (download all eggs before touching the existing install) would help a lot. - Buildout offers opaque and confusing error messages. This really needs to change, but we know it requires some pretty sophisticated attention. - The apache-style buildout.cfg file is inherently intimidating to new site developers. At first, they just want any easy way to install add-on products. We used to have that -- just unzip stuff into the Products folder. We need to bring back this idea: we envision a products.d folder where you can drop an egg, or a file named my.egg.cfg and it just works. This will also greatly increase our deb/rpm friendliness, since installing products via deb/rpm would just involve dropping those products in the folder. - Pinning does not currently lead to predictable, repeatable deployments. Pinning is also still very confusing. Even a good, commented-out example of pinning would help. We're not sure how it work work, but some approach to auto pinning would be excellent; people expect if they have the same buildout file and run it on their server, they'll get the same stuff. We need to come up with some way to bake a buildout (e.g. bin/buildout --generate-deployment-file) so we can guarantee that a buildout will always get the exact same code. 4) Product uninstallation While many more experienced developers don't often uninstall products, or
Re: [Framework-Team] Re: [Plone 4] Framework Team Mi nutes – Sept 16, 2009
On Tue, Sep 22, 2009 at 6:14 PM, Martin Aspeli optilude+li...@gmail.com wrote: Eric Steele wrote: #9263: Erik: Looks good. i18n:attributes=title be made implicit. Important to re-add owner. I don't know what that last comment means. If you mean we want the Owner role on the sharing tab by default then (a) I disagree (it shouldn't be necessary to delegate the Owner role and this is a very confusing concept, especially when we have a change ownership form as well) and (b) it's outside the scope of the PLIP. I'm missing some context here, but it is possible that it's actually Manager we need to re-add (we never had owner on there) -- I've certainly missed the ability to easily assign manager rights through the tab, since manager is not just the sum of view/edit/add. :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: [Plone 4] PLIP #9249 Add TinyMCE as the default visual editor
On Wed, Jul 29, 2009 at 12:34 AM, Wichert Akkermanwich...@wiggy.net wrote: The whole point of the agreement and the conservatory is that we have a solid legal basis. I would really like to see an informed legal opinion on the requirements for moving existing code to foundation ownership. Without that I fear we may be on dangerous ground and risk making the separate repository useless. Geir, if this is not territory that's been covered before, would you be willing to ping David Powsner about it? :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: [Plone 4] PLIP #9249 Add TinyMCE as the default visual editor
Absolutely. Getting the code into the Foundation's long-term conservancy is very much worth doing if it's not too terribly hard. I've not been through the process before of moving Collective code to the Foundation, but I know Jarn has done this, so perhaps Geir can enlighten us there on whether any additional steps are required other than making sure all contributors have signed the Contributor Agreement. :jon On Mon, Jul 27, 2009 at 1:01 PM, Alec Mitchellap...@columbia.edu wrote: I don't see much upside to renaming the package. On the other hand, the more core Plone code that's owned by the foundation the better, IMO. If Rob is willing to do the work to get all contributors to sign over their contributions, then it's probably worth pursuing. Alec On Mon, Jul 27, 2009 at 11:37 AM, Ross Pattersonm...@rpatterson.net wrote: Wichert Akkerman wich...@wiggy.net writes: On 7/27/09 1:38 PM, Rob Gietema wrote: Hi, I'm currently working on TinyMCE for Plone 4 and would like some feedback on two issues: 1) The current code base is located in the Collective. Since TinyMCE will be the default editor in Plone 4 should I move (copy) the code base to Plone SVN? -0 I see no reason to move it. 2) I'm currently using the Products namespace for the package. Would it be better to switch to the plone(.app) namespace for Plone 4 (and keep the Products.TinyMCE for Plone 3)? -1 There is no benefit to moving, and this will make it harder to maintain Plone 3 and 4 trees in parallel. I'm -1 to both of these, potential disruption for no benefit I can see. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIPs in Trac
Eric Steele wrote: I have little to add to what Hanno and Martin have stated so well here. To me, what shortcomings the Trac-based approach may have are trivial enough for me to largely overlook and can be covered through some further integration work by the plone.org team and/or better documentation of the process. I've been getting a sense of frustration from new folks we've let into the system looking to help but are getting shot down with that's a feature request. While that may be the case, I really don't want to see these potential contributors feeling dismissed. Can we come up with some strong documentation on where the leap from feature request to PLIP lies? Eric, We've long lacked a process for average Plone users to make feature requests. But no longer! :-) I hope I've managed to document feature request vs. PLIP reasonably well now at: http://plone.org/documentation/faq/suggest-a-feature-for-plone Please feel free to suggest any ways to make this clearer, or to adapt anything from there onto the dev.plone.org/plone wiki space as needed. best, jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] HTTP parameter polution
Andreas Jung wrote: Hi there, just read this article (in German) about a new attack pattern called HTTP parameter polution and they mention Plone: http://www.linux-community.de/Internal/Nachrichten/Webanwendungen-mit-HTTP-Parameter-Pollution-angreifen Anyone heard of this? http://seclists.org/bugtraq/2009/May/0165.html seems to be a good starting point. :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 2009: Going from here
Eric Steele wrote: Folks, A gentle prod since Steve wants to have something to vote on by Friday There seems to be general agreement on the hybrid team idea. Can we pare this down to a list of 7 people? We currently have responses of: available: Raphael (3), Ross (4), Matt (4) unavailable: Andi (3) I'd like to gently encourage Hanno to play a formal role on this new FWT. As the Plone trunk/future release manager and our most prolific contributor, I think it will be important for him to provide continuity between the Plone 4 release and Plone Future. I would also personally love to see Martin Aspeli and Laurence Rowe in the mix as well, since they have such deep understandings of our stack and are helping architect large chunks of the future. US$0.02, :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 3.3rc11 tagged and uploaded
Wichert Akkerman wrote: On 3/31/09 6:12 AM, Jon Stahl wrote: Wichert Akkerman wrote: I have tagged and uploaded Plone 3.3rc1. This is a first release candidate, so please everyone: test the hell out of it! If no critical bugs are found we will release this unmodified as 3.3 final in two weeks. If any changes are necessary we will make another release candidate and repeat the process. Should this be announced more broadly? Framework dev lists are pretty small and haven't seemed to create enough testing for some past releases (in my casual observations). Do you want feedback/testing from the larger world of plone-users? Yes, but I want to have installers ready before doing that. +100. Glad to hear that's in the works. :-) Plone 3.3 is shaping up really nicely. :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 3.3rc11 tagged and uploaded
Wichert Akkerman wrote: I have tagged and uploaded Plone 3.3rc1. This is a first release candidate, so please everyone: test the hell out of it! If no critical bugs are found we will release this unmodified as 3.3 final in two weeks. If any changes are necessary we will make another release candidate and repeat the process. Should this be announced more broadly? Framework dev lists are pretty small and haven't seemed to create enough testing for some past releases (in my casual observations). Do you want feedback/testing from the larger world of plone-users? If so, are there instructions for installing suitable for the average integrators on plone-users? Are there new binary installers? (http://plone.org/products/plone/releases/3.3 is still showing beta.) :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Unladen Swallow -- possibly worth keeping an eye on
Google's Python folks have started an effort to significantly speed up Python. http://code.google.com/p/unladen-swallow/ Should be interesting to keep an eye on. :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] concerns about our beta process
Wichert Akkerman wrote: Previously Jon Stahl wrote: I am a little concerned, though, that our beta process is not getting us the feedback we need. To but it briefly: there's no easy way to get the beta and try it out. I can't find any place to download it, or any documented instructions for getting it via buildout. http://plone.org/products/plone/releases/3.3, which seems the most logical place, offers no clue. That is simply because the installers have not yet been generated. I expect Steve and Sidnie to finish them soon. Ah, what a difference a day makes... nice work, y'all. I should remember that it always takes a few days between tag and installers ready. :-) best, jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] concerns about our beta process
Hi All- I saw in the topic on FWT that 3.3b1 is tagged... yahoo! Thanks to all of the folks who got code in there - it is really nice to see us making small feature releases so regularly! I am a little concerned, though, that our beta process is not getting us the feedback we need. To but it briefly: there's no easy way to get the beta and try it out. I can't find any place to download it, or any documented instructions for getting it via buildout. http://plone.org/products/plone/releases/3.3, which seems the most logical place, offers no clue. If we hope to have people outside the core developer team test our beta releases (and I assume we do), then we're going to have to make it easier to take our betas for a spin. Or at least mark the path more clearly. :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
RE: [Framework-Team] PLIP Community Imapacts
Ross Patterson m...@rpatterson.net writes: So far, much of the Plone 4 work has happened in narrower circles to free it up for prototyping, visioning, and imagining new approaches. This has been in part to isolate such a process from the paralysis that can come from discussion of edge cases or disagreements which are more proper and valuable at a later stage. I raised a concern that as we start presenting this work more publicly, we should think about communicating and setting expectations for the impact of the backwards incompatible changes FWIW, Joel Burton raised some concerns along these lines as well when I spoke to him a couple of weeks ago. We hashed around the idea (which I've also spoken of with Alex) of actually doing some sort of in-person focus group style event, where the P4 FWT could present some of the work-in-progress on Plone 4 (e.g. deliverance, dexterity, deco) to a small panel of selected community members (e.g. trusted typical integrator types) to get feedback not only on what we need to improve/document better but also how we should go about best explaining/framing the changes so they don't cause undue alarm. I would be willing to do some work to help organize such an event, and I would not at all be surprised if the Foundation were willing to provide some underwriting (e.g. buy some plane tickets) but of course it is the participation/leadership of the FWT that would be the key to making it happen. I could imagine this event, with fewer than 20 people, happening on the east coast USA sometime this summer (much depends on code readiness, I suppose). One might potentially define this as a spiritual successor to the 2008 PSPS event, but I would avoid using the terms strategic planning or summit to describe it. Maybe a Plone 4 Framing Workshop. ;-) $0.02, jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
RE: [Framework-Team] Re: PLIP Community Imapacts
East coast... summer... Ugh. :) East coast is significantly easier for the Europeans, both in travel time and intensity of jetlag. But all is open to discussion. They rallied to CA for the PSPS. :-) :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Hanno Schlichting Plone 4 release manager
Erik Rose wrote: The Plone 4.0 framework team is pleased to announce our recommendation of Hanno Schlichting as the 4.x release manager. Hanno is a Plone Foundation member and a prolific committer across diverse parts of the Plone codebase (http://www.ohloh.net/accounts/hannosch). We're confident that his perspective and dedication will drive the next generation of Plone to excellence. So congratulations to Hanno Schlichting on his nomination; we look forward to working with him on the next major release of Plone! Thanks, Eric FWT! A quick update from the PF board: Our next official meeting won't be until January 4th, but we've already taken a straw vote via email and there was *considerable* enthusiasm for Hanno (to put it mildly!). His formal confirmation as Release Manager will be the first item on our agenda when we reconvene after the holidays. best, jon Jon Stahl President, Plone Foundation ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
RE: [Framework-Team] Supported Plone Releases
-Original Message- From: [EMAIL PROTECTED] [mailto:framework-team- [EMAIL PROTECTED] On Behalf Of Wichert Akkerman Sent: Wednesday, December 10, 2008 12:53 PM To: framework-team@lists.plone.org Subject: Re: [Framework-Team] Supported Plone Releases Previously Jon Stahl wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:framework-team- [EMAIL PROTECTED] On Behalf Of Steve McMahon Sent: Wednesday, December 10, 2008 8:31 AM To: Framework Team Subject: Re: [Framework-Team] Supported Plone Releases Why bring this up on the framework team list? The framework team is not a governing body. Then, who is? I certainly think that if the framework team makes a decision on this, it would be widely respected and supported. I think that the PF Board would prefer not to make the decision, in order to continue the tradition of the board not governing development. And, I think the developer list is way too wide open. +1, I believe the board would vastly prefer not to set the precedent of making technical decisions about Plone. The Foundation protects and promotes; the community develops. :-) But this is not a technical decision at all. This is a decision about our ability and willpower to dedicate resources (skilled manpower) to accopmlish something. True enough. But I think there is a long-standing consensus that decisions regarding what software gets built and released should rest with the community, not the board. And the center of consensus in the community is the framework team, especially for decisions that require focused effort from a few highly skilled people. Like I said, I think the board is in generally in favor of this. But that's different from us deciding to continue making security fixes to 2.5.x. The community needs to decide to do that if feels it can/should. And I think the community will tend to follow the framework team's lead here. :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Kicking off Plone 4: Release Manager candidate
Tom Lazar wrote: On 28.10.2008, at 13:03, Alan Runyan wrote: +1 to Hanno/Martin being Plone 4 release manager/communicator same here! I couldn't possibly imagine two more qualified people. Three cheers for you both! :-) :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
RE: [Framework-Team] Re: PLIP 244: Portlet management improvements
-Original Message- From: [EMAIL PROTECTED] [mailto:framework-team- [EMAIL PROTECTED] On Behalf Of Danny Bloemendaal Sent: Friday, October 17, 2008 4:47 AM Cc: framework-team@lists.plone.org Team Subject: Re: [Framework-Team] Re: PLIP 244: Portlet management improvements On 17 okt 2008, at 01:29, Jon Stahl wrote: One other thought to contribute to this topic: Right now, the system renders all placeful portlets, then all group portlets, then all type portlets. Grouping is bad. Especially if you allow some form or ordering. No user wants to be bound by an arbriary technical reason for grouping. If a user wants to have portlets in a mixed order, that is pretty much impossible. Perhaps we can add a simple weight value to each portlet, then order portlets by weight, regardless of whether they are place, group or type portlets? There are some UI considerations, and maybe this is too invasive. But we get it a fair amount. Weight? Why that? Why not allow them to be mixed as the user wants? Why that grouping at all? It's a technical reason not a usability reason. Just allow them to be mixed and you are done. I even would like to suggest to have the option to mix them on a user bases with drag and drop and store the order in cookies or something like that. We have that here in our intranet together with collapsible support and that works really well. But that's another topic ;-). I think control of ordering should (mostly) be a site-admin task, except in the intranet situations you describe where it might be pushed to the user (along with other portlet control). Other than that, I think we're saying the same thing. :Jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
RE: [Framework-Team] Re: PLIP 244: Portlet management improvements
-Original Message- From: [EMAIL PROTECTED] [mailto:framework-team- [EMAIL PROTECTED] On Behalf Of Martin Aspeli Sent: Thursday, October 16, 2008 3:39 PM To: framework-team@lists.plone.org Subject: [Framework-Team] Re: PLIP 244: Portlet management improvements Wichert Akkerman wrote: Previously Martin Aspeli wrote: - Create a site wide portlet category for portlets that should show on all pages (unless blocked). Currently, people have to use contextual portlets at the root of the site for this, which gets cumbersome since if you block them in one folder, you need to re-add all portlets in subfolders. This feels like a workaround for the fact that you can not selectively block portlets. I used to think that way, I'm not so sure anymore. Speaking to people about this over the past few months, I've come to realise that our model of thinking that the site root is the parent of all content from which things like portlets can inherit if they need to be site-wide is not how people tend to think about it. I think to most people, the root is the front page and is just a page. You may want some portlets on the front page, or you may want some portlets that are global and show up (almost) everywhere. In our current model, the workaround is that you have to be careful to assign portlets to the root and then not block them unduly. This gets unnatural, especially if you have deep or complex content hierarchies. I would prefer a method where you can both block individual portlets and block only for the current object is, similar to how you propose a flag to only show a portlet in the current object. Right, we need that too. :) One other thought to contribute to this topic: Right now, the system renders all placeful portlets, then all group portlets, then all type portlets. If a user wants to have portlets in a mixed order, that is pretty much impossible. Perhaps we can add a simple weight value to each portlet, then order portlets by weight, regardless of whether they are place, group or type portlets? There are some UI considerations, and maybe this is too invasive. But we get it a fair amount. :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
RE: [Framework-Team] PLIP 323: Resource Registries Improvements
Matt Bowen took on the PSPS 2008 task champion FWT process improvements and now that the conference is over, he will have some free time, and has already told me Steve that he is interested in picking this back up. I'll try to draw Matt back into this conversation. ;-) best, jon -Original Message- From: [EMAIL PROTECTED] [mailto:framework-team- [EMAIL PROTECTED] On Behalf Of Andreas Zeidler Sent: Monday, October 13, 2008 9:03 AM To: Raphael Ritz Cc: Framework Team Subject: Re: [Framework-Team] PLIP 323: Resource Registries Improvements On Oct 9, 2008, at 6:54 AM, Raphael Ritz wrote: Wichert Akkerman wrote: The framework team desparately needs someone who coordinates things and keeps lists of PLIPs that are being reviewed. +1 I hope that the team can elect someone to take that role during their meeting this week. nobody was elected, but steve and john offered to help. we need to follow up on what has been discussed in the meeting, but i think we'll see a number of mails about this soon enough anyway, i.e. once everybody's back home and more or less recovered. Yup, I guess most of us consider Andy to be that one but I know he sees this differently. just to clarify this again, i won't be doing coordination work this time, which includes bookkeeping as well as poking the other team members etc. sorry. cheers, andi -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.1.6 released! -- http://plone.org/products/plone/ ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: who owns what, according to trac
Martin- Thanks for your comments; I will summarize and repost this to the dev list for further discussion. Maybe I will even move this list to the Plone Strategic Planning workspace at openplans so that we can edit it collaboratively without creating chaos. :jon Martin Aspeli wrote: Jon Stahl wrote: Scratching my own itch (thanks to Hanno for suggesting I look at the component owner list in trac), I pulled together this list of current component owners, sorted into owned and unowned. COMPONENTS WITH TRAC OWNERS Archetypes nouri I wonder how effectively Daniel can manage this, given that it's such a big piece of code. It'd be good to make sure we can form out bugs here to others as needed. Catalogwitsch Content Rules optilude Control Panel hannosch Image Blob Support witsch Installer (Mac OS X) smcmahon Installer (Unified)smcmahon Installer (Windows)dreamcatcher Intelligenttextmaurits Internationalization hannosch Javascript mj KSS (Ajax) ree Linkintegrity witsch Lockingjfroche Navigation/Folder listings optilude I really wish I could give this to someone else... I don't own this in any meaningful way, and I think I become a bottleneck. NuPlone Theme limi Limi is probably a bottleneck here. Unfortunately, we struggle to find people willing to own template/visual bugs. OpenID support davisagli Portlets optilude Search witsch Spelling Error hannosch Transforms hannosch Versioning alecm Visual Editor (Kupu) duncan WebDAV dreamcatcher This one tends to bottleneck, because not enough people know very much about WebDAV. COMPONENTS WITH NO TRAC OWNERS ATReferenceBrowserWidget Accessibility Calendar and time Content Types This one really should have an owner, since it's so fundamental. Discussions Documentation Infrastructure (kind of a broad area) Right, we should rationalise this away. Login and registration This one badly needs an owner. I think Wichert was looking after it, but realised he couldn't keep up. Mail MimetypesRegistry Permissions RSS RTL Upgrade/Migration Usability (also a pretty broad area) Users/Groups Ditto - I think Wichert gave up on this one. Visual and templates This one is huge, and used to be Limi's. Wiki support (Wicked) Workflow Working copy support (Iterate) MY QUESTIONS: Are there owned components where the owner is not active? Are there unowned components that are actually owned? Which unowned components are the most critical to get owners for? See above. Are there unnamed components that need owners? Are there unnamed components that have owners? Should I take this discussion out to the dev list? ;-) Please! If we can define what a component owner does, we can probably recruit some more. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] who owns what, according to trac
Scratching my own itch (thanks to Hanno for suggesting I look at the component owner list in trac), I pulled together this list of current component owners, sorted into owned and unowned. COMPONENTS WITH TRAC OWNERS Archetypes nouri Catalogwitsch Content Rules optilude Control Panel hannosch Image Blob Support witsch Installer (Mac OS X) smcmahon Installer (Unified)smcmahon Installer (Windows)dreamcatcher Intelligenttextmaurits Internationalization hannosch Javascript mj KSS (Ajax) ree Linkintegrity witsch Lockingjfroche Navigation/Folder listings optilude NuPlone Theme limi OpenID support davisagli Portlets optilude Search witsch Spelling Error hannosch Transforms hannosch Versioning alecm Visual Editor (Kupu) duncan WebDAV dreamcatcher COMPONENTS WITH NO TRAC OWNERS ATReferenceBrowserWidget Accessibility Calendar and time Content Types Discussions Documentation Infrastructure (kind of a broad area) Login and registration Mail MimetypesRegistry Permissions RSS RTL Upgrade/Migration Usability (also a pretty broad area) Users/Groups Visual and templates Wiki support (Wicked) Workflow Working copy support (Iterate) MY QUESTIONS: Are there owned components where the owner is not active? Are there unowned components that are actually owned? Which unowned components are the most critical to get owners for? Are there unnamed components that need owners? Are there unnamed components that have owners? Should I take this discussion out to the dev list? ;-) :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
RE: [Framework-Team] random thought: identify the components that lack owners
-Original Message- From: Wichert Akkerman [mailto:[EMAIL PROTECTED] On Behalf Of Wichert Akkerman Sent: Friday, September 26, 2008 12:03 AM To: Jon Stahl Cc: framework-team@lists.plone.org Subject: Re: [Framework-Team] random thought: identify the components that lack owners Previously Jon Stahl wrote: We were just chatting a bit here at ONE/Northwest global HQ and the following idea came up... Hanno pointed out to me a short while ago that a number of key core Plone components don't really have strong, active owners. e.g. Wicked, Users + Groups UI, etc. However, there's really no definitive list of these that we can use to recruit more talent. Could y'all put your heads together via email and draft up such a list, which we could then use to do some targeted recruiting? I'm wondering why this would be a task for the framework team? I'm open for suggestions about who else might take it on. I think we have a bit of a problem in that we have no formally-designated leadership team for the codebase of this project. The FWT seems like the closest thing we have in general, and on this topic, they (including you, Wichert) seem like the folks with the most relevant knowledge. :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] random thought: identify the components that lack owners
We were just chatting a bit here at ONE/Northwest global HQ and the following idea came up... Hanno pointed out to me a short while ago that a number of key core Plone components don't really have strong, active owners. e.g. Wicked, Users + Groups UI, etc. However, there's really no definitive list of these that we can use to recruit more talent. Could y'all put your heads together via email and draft up such a list, which we could then use to do some targeted recruiting? I have a feeling there is quite a bit of latent talent out there we could tap, if we could write down what needs to be pitched. I'd be willing to help, but lack the tech expertise to totally drive it. :jon -- Jon Stahl | Program Manager ONE/Northwest New tools and strategies for engaging people in protecting the environment www.onenw.org [EMAIL PROTECTED] 206-286-1235x15 http://blogs.onenw.org/jon Subscribe to ONEList, our email newsletter! Practical advice for effective online engagement http://www.onenw.org/full_signup ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Framework Team Meeting at Conference
I'd love to join you all, if you're willing to let an interested bystander horn in. ;-) :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: [Plone-developers] Plone 3.2 plans
Previously Martin Aspeli wrote: I think we're due a new features process. Perhaps we could start soliciting PLIPs for 3.3 and get the review process organised at the same time that we package up 3.2. I presume 3.2 won't have any PLIPs to review (well, maybe one or two package related ones) in any case. FWIW, Limi, Hanno I did some housekeeping in Trac last week that resulted in Feature Requests being separated from Bug Reports for the first time, now with a dedicated report of their own. I hope we can mine the Feature Requests report as a source for user-contributed ideas for improvements that might ultimately result in PLIPs. http://dev.plone.org/plone/report/21 :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
