Re: [Framework-Team] Records of software events regarding PLIP process
Is this what you are looking for? I’m not 100% sure I understand https://github.com/plone/plone.app.event On March 17, 2014 at 2:39:10 AM, ekouz...@csd.auth.gr (ekouz...@csd.auth.gr) wrote: Hello guys. I am trying to better understand the Plip and review process of Plone. I found very useful the information provided online by the community but I wanted to ask if there is a repository where software events (including a timestamp) are available for me to explore. Thank you in advance for all your help. ___ 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-developers] Call for Plone 5 Framework Team Members
2 cents: being on the FWT was an amazing experience. If you are borderline or nervous, just make the jump and apply. I learned SO MUCH from working with the team and if you put just a small amount of effort in it will return itself 10 fold. No time for imposter syndrome… hope to see some new faces join in! Liz On Tuesday, June 25, 2013 at 12:57 PM, Ross Patterson wrote: > Hello Fellow Plone Developers, > > The current Plone Framework Team has decided that the next major Plone > release will be Plone 5 (instead of 4.4). So it's time for some fresh > blood on the Framework Team. We're seeking nominations for new members > to help get an awesome Plone 5 out the door sooner rather than later. > > The framework team's mission is to guide the ongoing technical work on > Plone in ways that promote code quality and that are aligned with the > community's interests. Specific framework team responsibilities include: > > * Conducting in-depth reviews of Plone improvement proposals (PLIPs) > * Encouraging contributors to submit needed PLIPs, and helping mentor > them through the process > * Meeting with the team for an hour every 2 weeks to work on moving > PLIPs through the process > > See http://plone.org/community/teams/framework for more information > about the framework team, and http://plone.org/community/processes/plips > for more about the procedure for considering proposed improvements. > > Framework team members are expected to have made significant (code or > non-code) contributions to Plone, to be familiar with current Plone code > and/or UI best practices, to have plenty of experience with buildout and > to possess a tolerance for awkward silence during conference > calls. You're probably a good candidate if: > > * You follow discussion on plone-developers or Plone core commits on > github > * You're already active reviewing Plone-related pull requests > * You have an opinion about the future of Plone, but are also someone > respected for your ability to carefully consider opinions different > from your own. > > If you or someone you know is interested in joining the team, please > send a nomination email to the framework team list > (framework-t...@lists.plone.org (mailto:framework-t...@lists.plone.org)). > Please include the name and email of > the nominee as well as a note detailing experience with Plone and some > reasons for wanting to join the team. Members will be selected by > current and emeritus team members. > > Thanks, > Ross Patterson > Plone Framework Team > > > -- > This SF.net (http://SF.net) email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > Plone-developers mailing list > plone-develop...@lists.sourceforge.net > (mailto:plone-develop...@lists.sourceforge.net) > https://lists.sourceforge.net/lists/listinfo/plone-developers > > ___ Framework-Team mailing list framework-t...@lists.plone.org https://lists.plone.org/mailman/listinfo/plone-framework-team
Re: [Framework-Team] [Plone-developers] Plone 5
On Saturday, June 15, 2013 at 7:53 AM, Thijs Jonkman wrote: > I really like most of what I'm reading, but I've got a few remarks on "Plone > 5's UI gets an extensive overhaul". > . > * Fewer CSS files makes finding and overriding easier > > I don't see how this would work. Fewer CSS files just means you have to > override more in one go. Which in turn means that you have more custom code > that you have to upgrade with new plone versions. In this pull request > (https://github.com/plone/plonetheme.sunburst/pull/10) we've actually split > up public.css in sunburst for better overriding. Also, is finding really an > issue? It's easy with most editors to find across multiple files, and tools > like firebug, directly point you to the right file and line. If we didn't have so much !@#$ css I think the way people deal with theming would dramatically change. I personally never override, and instead just make stronger selectors in my own css. This is the right way™... but I know that the use case and skills make people do otherwise. Like you say below, switching to a more modern framework will help immensely. I feel like people are still clamoring for the old school base_properties and we can recreate that "feeling" with different tools. Additionally, a modern theme to begin with should reduce the number of customizations. FYI, for Plone 5 you will not be required to switch to the new theme at all. This will be the OOB theme for new sites. > It should be easier to customize defaults. After a lot of talk on embracing > the future for plone javascript, we should do the same with css. Moving to > diazo and p.a.toolbar seperates the complete front-end, thus actually making > it very easy to do things the new way. We should move to using a framework > for the base of plone theming. We should start using a preprocessor (sass, > less,...) for css, using variables to give a flexible base to jumpstart the > theming process and keep your themes up to date. > > > I agree here 100%. We need some serious CSS vision and this is one place where we haven't had a lot of strong opinions step up (mine are mildly spicy). I'd love to see this thread turn into the type of discussion that occurred over javascript. If you (or anyone) thinks they have a grand vision for modernizing the Plone css framework, please raise your hand. Now is the time to plot, plan, argue, and agree! > * Deco.gs (http://Deco.gs) is replaced with a more commonly-used grid > system, responsive > > Is there a solid, grounded reason to leave deco.gs (http://deco.gs)? The last > few months I've been playing around with creating diazo css framework parent > themes*, which would make it easy to create child themes, using a lot of > predone rules to mold the content into what the css framework expects. This > has exposed me to a lot of grid systems and frankly I havent really seen > anything better than deco.gs (http://deco.gs). Most of them use row column > structures, like deco.gs (http://deco.gs), but none of them allow you to > shift around your content order as beautifully as deco.gs (http://deco.gs) > does. It is really easy to understand how deco works and it's actually really > easy to make it responsive. Just nullify the grid classes with a media query > and add a max width to the container (#visual-portal-wrapper). For me > currently the most sensible basis for a new plonetheme would be the PureCSS > framework with Deco.gs (http://Deco.gs). Officially: deco.gs has no maintenance outside of the plone community. The vision was never followed through and designers outside of plone don't use it. It's in our best long term interest to move to something thats maintained by a community smarter than we are. We need to think about people who hire external designers and what they work with. Personally: I haven't had the same experience. If I never see another negative margin again it will be too soon. I LOVE working with bootstrap and even 960. I'll trade the flexibility for something maintained and industry standard any day. > * https://github.com/TH-code/diazotheme.framework.plone, > https://github.com/TH-code/diazotheme.framework.bootstrap, > https://github.com/TH-code/diazotheme.framework.baseline, > https://github.com/TH-code/diazotheme.framework.amazium, > https://github.com/TH-code/diazotheme.framework.goldilocks, > https://github.com/TH-code/diazotheme.framework.kube, > https://github.com/TH-code/diazotheme.framework.purecss, > https://github.com/TH-code/diazotheme.bootswatch > > > It would be awesome if you updated these README's so that people knew what they did. I'm sure its great work so make sure to promote it well :) Liz > > > > On Fri, Jun 14, 2013 at 11:57 PM, Eric Steele (mailto:ericsteel...@gmail.com)> wrote: > > So, as you've likely noticed, we spent a lot time of talking about Plone 5 > > during the recent Plone Symposium Midwest. I think we'v
[Framework-Team] Support for pre-PSE sprint
Hello Lads, The board needs some official communication that the FWT supports the pre-PSE sprint as a strategic sprint. The pre-PSE sprint will be focused on on ripping out CMFFormController. Any objections to supporting funding this? Otherwise a +1 will suffice. Thank you for everything lovelies! Liz -- Elizabeth Leddy Sent with Sparrow (http://www.sparrowmailapp.com/?sig) ___ Framework-Team mailing list framework-t...@lists.plone.org https://lists.plone.org/mailman/listinfo/plone-framework-team
Re: [Framework-Team] Farewell
Thanks for everything Marcio! I totally understand! Liz -- Elizabeth Leddy Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Sunday, January 20, 2013 at 11:42 AM, David Glick (Plone) wrote: > Hi Marcio, > It's certainly understandable that planning the conference would take > considerable time and energy! I have appreciated your contributions to the > team and hope you'll consider participating again sometime in the future. > See you in Brazil, > David > > On 1/20/13 7:32 AM, Marcio Mazza wrote: > > Dear FWT members, > > > > Since the invitation to join the FWT, at the first day in Arnhem, some > > important changes happened to my priorities and to my use of time and > > energy. > > > > One of them is the fact that my city will host the next Plone Conference > > and I am one of the organizers of the effort. I have come to the conclusion > > that this will take a whole lot more work than I thought. That's a priority > > to me now: that we all have a great conference. For this and some other > > personal reasons I have to leave this team I just joined. > > > > I'd like to thank you for this short period together. I was greatly pleased > > to participate, even for a short time. > > > > Thank you all. Hope to see you here in Brazil in a few months. > > > > Marcio. > > > > > > > > ___ Framework-Team mailing list > > framework-t...@lists.plone.org (mailto:framework-t...@lists.plone.org) > > https://lists.plone.org/mailman/listinfo/plone-framework-team > ___ > Framework-Team mailing list > framework-t...@lists.plone.org (mailto: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.app.event ready for review due to...
YAY! Liz -- Elizabeth Leddy Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Wednesday, November 14, 2012 at 4:25 AM, Johannes Raggam wrote: > ... next week. > > i plan to finish the doc update and the implementation notes until mid > of next week (22nd nov) and give a notice about that when i'm done. > > best, > johannes > > > > > -- > programmatic web development > di(fh) johannes raggam / thet > python plone zope development > mail: off...@programmatic.pro (mailto:off...@programmatic.pro) > web: http://programmatic.pro > http://bluedynamics.com > ___ > Framework-Team mailing list > framework-t...@lists.plone.org (mailto: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] Diazo ZPT fragment support
I'm technically not on the FWT but -1 for doing this like a bug fix. I am in agreement with djay, but more importantly we have been very good about going "add-on first, core second". I can see this being a product bump (like tinymce is at the moment) for a good couple of months and then getting feedback on it. 2 cents, Liz -- Elizabeth Leddy Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Thursday, November 1, 2012 at 3:00 PM, Martin Aspeli wrote: > Guys, > > I'd really like some FWT input on > > https://github.com/plone/plone.app.theming/pull/10 > > It's ready to merge, but there seems to be different opinions about merit: > > * Laurence and I see it as an important way to solve a certain class > of problems, where Plone's markup isn't sufficient as a base to > deliver what the theme required, without having to resort to full-on > filesystem development. > > * Dylan is against the idea, believing most/all use cases can be > adequately solved in content space with a combination of existing > portlets, TinyMCE styles and add-on products > > * A number of people seem to be on the fence > > I'd like to merge this before it bitrots, and I think the > implementation is sound. However, I think it needs some FWT discussion > and approval first. > > Martin > ___ > Framework-Team mailing list > framework-t...@lists.plone.org (mailto: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
[Framework-Team] plone.app.multiligual
Just want to make sure the followup on this PLIP isn't missed in the next call: https://dev.plone.org/ticket/13091 Liz -- Elizabeth Leddy Sent with Sparrow (http://www.sparrowmailapp.com/?sig) ___ Framework-Team mailing list framework-t...@lists.plone.org https://lists.plone.org/mailman/listinfo/plone-framework-team
Re: [Framework-Team] Framework/Roadmap Team Dinner in Arnhem
Should we invite all the "potential" new framework team members as well? Liz -- Elizabeth Leddy Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Thursday, October 11, 2012 at 9:21 AM, Nathan Van Gheem wrote: > I'm in. > sent from my nexus 7 > On Oct 11, 2012 9:20 AM, "Ross Patterson" (mailto:m...@rpatterson.net)> wrote: > > Liz suggested "Café Brasserie Dudok Arnhem": > > > > http://www.dudok.nl/index.php?pageID=152 > > https://maps.google.com/maps?hl=en&safe=off&ie=UTF-8&q=Caf%C3%A9+Brasserie+Dudok+Arnhem&fb=1&hq=Caf%C3%A9+Brasserie+Dudok+Arnhem&cid=0,0,12972247205116795382&ei=knF2UKqoBabG0QXK44F4&ved=0CH0Q_BIwAA > > > > Unless someone else suggests something else or objects, I'd say we > > should just go for this one. > > > > So everyone who's coming, Framework Team members and alumni, Roadmap > > Team members and alumni, +1s, etc. please say so now so we can get a > > count for a reservation. > > > > Ross > > > > Ross Patterson mailto:m...@rpatterson.net)> writes: > > > > > On Wed, Oct 10, 2012 at 5:45 AM, Andreas Zeidler > > > mailto:wit...@plone.org)> wrote: > > >> On 10 Oct 2012, at 12:20, Ross Patterson > > >> mailto:m...@rpatterson.net)> wrote: > > >>> On Wed, Oct 10, 2012 at 3:06 AM, Martin Aspeli > > >>> mailto:optil...@gmail.com)> wrote: > > >>>> Works for me. Can we bring the Roadmap team too? > > >>> > > >>> Absolutely, that sounds to me like a great improvement to the > > >>> tradition of the annual FWT meeting. > > >> > > >> +1 > > >> > > >> btw, is the dinner only for current team members or can we come as well? > > >> :) > > > > > > Yeah, in past years it's been "...and alumni" I just forgot to say that. > > > > > > Ross > > > > ___ > > Framework-Team mailing list > > framework-t...@lists.plone.org (mailto:framework-t...@lists.plone.org) > > https://lists.plone.org/mailman/listinfo/plone-framework-team > ___ > Framework-Team mailing list > framework-t...@lists.plone.org (mailto: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-developers] Plone framework team meeting minutes, May 8
On May 8, 2012, at 4:36 PM, David Glick wrote: > On 5/8/12 3:34 PM, Dylan Jay wrote: >> Hi, >> >> I noticed https://dev.plone.org/ticket/10959 has now been dropped from >> your list. It's implemented but I need to know if its worth the effort >> in finishing the last remaining test failures. I've asked advice on if >> the FWT wants the implementation or not (see last comment 9 days ago). >> Is this the advice? >> BTW This PLIP has been open almost 2 years. I'd like see some kind of >> resolution to password validation in plone. >> >> > Hey Dylan. I'm sorry we've been dropping the ball on your PLIP since Ross > stepped down from being its champion. (In the case of today's meeting, we > accidentally overlooked a section of our spreadsheet which included this > PLIP.) > > I just familiarized myself with the code, past reviews and conversation, and > my personal feeling is that this is a good change and while there are > reasonable concerns raised in the reviews, we shouldn't let the perfect be > the enemy of the good. > > To touch on some of the specific items that were outstanding in the reviews: > * Yiorgis raised the issue of the initial generated password not necessarily > being compliant with the validation, but you pointed out that this is not a > problem because the user never sees the initial password. That makes sense to > me, so I think this concern is resolved. > * Yiorgis and Ross both raised concerns about whether the PAS API should be > extended (to support limits on password age, say, or to support providing > more specific help text for the password field on a registration form). I > agree these are ideas worth considering, but they are outside the scope of > this PLIP (which is just a tiny change in Plone to make use of the existing > PAS API), orthogonal to it, and should not be blockers. > * Ross said he hadn't tested to make sure the validation is applied during > the password reset process. Can you or someone else please verify that this > works? > * Ross mentioned a test failure in CMFPlone (testGeneratePassword). This > looks trivial to fix if it hasn't been already so we can handle it during > merge. > * Vincent brought up an i18n concern at > https://github.com/plone/plone.app.users/pull/2/files#L1R250 which looks > valid to me. Can you fix that? > * I think you still need to add an upgrade step to plone.app.upgrade to > install the plugin for upgraded sites. > For me, the test case and upgrade steps should definitely be handled. I'm more concerned about the documentation as a test case than anything (I can't find it anymore actually...). I *think* this should be in the community dev manual. Liz > Any opinions from the rest of you FWT folks? This seems like too much of an > easy win to me to let it drag out longer. > David > > > -- > David Glick > Web Developer > davidgl...@groundwire.org > 206.286.1235x32 > > Are you engaging? Find out! Use our free engagement benchmarking tool. > > http://groundwire.org/labs/engagement-strategy/diy-benchmarking-survey > > > ___ > 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-developers] PlonePAS portrait handling
On Apr 11, 2012, at 2:28 PM, Jens W. Klein wrote: > Products.PlonePAS handles every user data as some property on a > propertysheet, except the portrait photo. > > The portrait is stored at portal_memberdata - which is fine - but it is > not exposed on the property sheet nor is it fetched as such. > > In my opinion its a must to handle the portrait photo the same way as > all userdata. Exposing a photo from a different source - i.e. ldap, sql, > remember - means now to patch PlonePAS - and this is ugly and error-prone. > > I'd like to change PlonePAS in a way to support this, but before I start > I'd like to read your opinions. > > My proposed changes are: > > - add a new mutable propertysheet dealing with one property 'portrait' > and use current portal_memberdata storage > > - change the methods used to fetch, store and delete the portrait on > portal_membership and portal_memberdata to use the propertysheet. > > - add a traverser to the photo to support non-zodb data. I would like this but, how would this work? How does the PAS story fit in here? > > - add tests > > Code using the current API would not be affected. Supporting a different > data source for the photo would follow the usal PAS API. > > What do you think? > > Do we need a PLIP for this? I'm all for this idea. I feel like a plip would just help with the review process more than anything. I wouldn't mind deprecating the old way either and making a plip would help this happen. I doubt the FWT would say no to this and I know I have a project that could use this functionality. Liz > > regards Jens > -- > Klein & Partner KG, member of BlueDynamics Alliance > > > -- > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > ___ > Plone-developers mailing list > plone-develop...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plone-developers ___ Framework-Team mailing list framework-t...@lists.plone.org https://lists.plone.org/mailman/listinfo/plone-framework-team
[Framework-Team] Todays meeting
For everyone who wasn't at the meeting today, which was almost everyone, we decided to move from weekly to biweekly meetings again. In exchange, please do *1* plip review before the next call. There are plenty still on the chopping block. One of primary concern is the search ignoring accents plip - a couple of us will review it but we are plain old english speakers. Any ideas on multiligual plonistas who could jump in and help? Liz ___ Framework-Team mailing list framework-t...@lists.plone.org https://lists.plone.org/mailman/listinfo/plone-framework-team
[Framework-Team] Reviewing PLIPS sux0rs | Github growing pains
Yo FWT peeps - I just finished reviewing a plip, the first time not in svn and I think there are some things that to happen for me to actually review more plips and not be intensely frustrated. I suspect anyone who reviewed plips already would agree with some if not all of these. People won't do reviews if they are frustrated and/or it takes freaking forever. These complaints are mostly rooted in the new github setup. I know how *I* use github and I hear there are a lot of reasons why we don't use it differently for plip reviews. I am not qualified to make suggestions because my head spins with all the arguments back and forth, I was hoping to just complain and then have you guys tell me to either can it or maybe we can work out something resembling sanity. Forking Mad: People love forking! 1. When people fork, it means that I have to delete my src/Plone.CMFPlone folders and any other folder that's now elsewhere, then rerun the long arduous process of downloading that honkeriffic package. (Grr). We need a best practice here. Would branch the coredev buildout for each PLIP solve this problem? How can we get people to stay in the plone namespace on github? Can/should we require that namespace as part of the condition of getting into core? 2. I don't know where to find code commits for review in a sane way. Looking on the file system is nutty for large packages. I just spent 15 minutes trying to find a changeset by following forks, only to see that the only line added to the CMFCore was plone.packagename in yet another fork of someone else. (Grr) Documentation: 3. Documentation is confusing AGAIN. It is tradition to use README in gihub to provide documentation. Should we be encouraging that with PLIP updates and packages? I personally like it, but then we have yet another place to have documentation. Also, when people have forked or are hosting in their account instead of under plone, holy whoah the docs could disappear. And what about collective? Can we set on a standard for at least one place for all new documentation? (Moar Grr) Reviewing: 4. I personally want to comment line by line in the code and did on this last review. This is SO much easier than putting reports in the text reviews, but then the other code reviewers need to look in the same place. Can we all agree to switch to commenting on commits and lines in github at the source instead of the review.txt file? 5. Filing bugs. If we are in github and the package is forked, it seems like we should file the bug there. Or do we keep it in trac? I don't know what the current philosophy is. Maybe we just listen to the devs? I just want them to 1) get the bug and 2) fix it. Other: 6. Can we make directories in the plips to make autocomplete easier? Maybe having a directory for each plip that then has everything about that plip? My only concern is making sure the cfgs still run. The current directory layout makes my eyes bleed after so many plips. Suggestions: I think at minimum, we need to have the PLIP implementors help us by *clearly* listing *urls* to - All documentation, which should be at a url (should it always be in collective docs? should human docs go there and sphinx docs elsewhere? What about upgrade notes?) - Which bug tracker they want us to use (that or we tell them, but I don't think that will work) - A URL which directs us to all packages that have been changed. On our end, It would be nice to provide a guide that tells the implementors... - all docs of type x go here, all docs of type y go here, all plips require docs of type X & Y - fork/branch code like this - submit for review with the urls above in implementation notes (plipXXX-XXX.txt) This way we don't have a guessing game on both ends and additionally it get's way easier for people to add plips. I'm happy to do the legwork of documenting if I can get some consensus on where to put things and the best way to address these problems. Liz (eleddy) ___ Framework-Team mailing list framework-t...@lists.plone.org https://lists.plone.org/mailman/listinfo/plone-framework-team
[Framework-Team] Fwd: [Plone-developers] PLIP Deadlines
Hey Guys - Here is the info on the p.a.event ticket. I will attempt to take a look at this over break. Can anyone else put some eyes on it? Begin forwarded message: > From: Johannes Raggam > Subject: Re: [Plone-developers] PLIP Deadlines > Date: December 20, 2011 1:34:49 PM PST > To: Elizabeth Leddy > > Hi, > > i have created a document in plone.app.event, called README-FWT.rst, > which contains some information about the PLIP status. > > You can find it directly here: > https://github.com/collective/plone.app.event/blob/master/README-FWT.rst > > Can you please forward this message to Framework Team members? > I'm looking forward for feedback! > > If something doesn't work as expected, especially kickstarting the > buildout, please let me know. > > Thank you, > Hannes > ___ Framework-Team mailing list framework-t...@lists.plone.org https://lists.plone.org/mailman/listinfo/plone-framework-team
Re: [Framework-Team] BrowserID
On 7/20/11 12:25 PM, Alex Limi wrote: Was asked to put this on your radar by Mozilla: https://browserid.org/developers.html I believe it's a better solution than stuff like OpenID for the average user. Feedback (on both the approach, and whether we should add it to Plone) welcome! Like most things, I think this should be vetted as an addon first and see if people actually use it. I would also post this on the dev list as well for more/better feedback. Liz --- Begin Message --- On 7/20/11 12:25 PM, Alex Limi wrote: Was asked to put this on your radar by Mozilla: https://browserid.org/developers.html I believe it's a better solution than stuff like OpenID for the average user. Feedback (on both the approach, and whether we should add it to Plone) welcome! Like most things, I think this should be vetted as an addon first and see if people actually use it. I would post this on the dev list as well for more/better feedback. Liz --- End Message --- ___ Framework-Team mailing list framework-t...@lists.plone.org https://lists.plone.org/mailman/listinfo/plone-framework-team
