Framework Team Now Soliciting PLIPS for Plone 4.3
Plone's new six-month fixed release cycle seeks to deliver substantial new versions of Plone twice annually on a schedule developers, integrators and end users can count on. With the first release on this schedule. 4.2, now soft-released, the framework team is looking for new PLIPs (Plone Improvement Proposals) to fill the upcoming scheduled releases in 2012 with useful new features and improvements.
PLIPs for the March 2012 release, 4.3, are being accepted from now through December - so if you have ideas for improving Plone, the door is open for you to get them considered for that release.
So how do you go about getting your ideas considered for 4.3?
A good place to start is understanding the PLIP process. You can read all about the process from start to finish by visiting the PLIP Process page.
Why should I care about PLIPs?
PLIPs are a method of allowing anyone to get their ideas considered for inclusion in Plone based on the merit of those ideas. Think of it as a democracy of thought - where if you can get people behind your ideas, those ideas / features / improvements can directly change the next version of Plone people download from Plone.org.
What kind of ideas make sense as PLIPs?
The Framework team also makes a report available of the current PLIPS which have been proposed, which is available to anyone by simply visiting this report page. Reviewing these is a good way to understand the format and level of specificity a PLIP is expected to provide to those reviewing it.
Hanno Schlichting has provided a starting list of items for 4.3 that have been cited by Framework team members as excellent examples that they are interested in getting underway immediately. Some of these are:
Use new HTML input types
As a reference http://diveintohtml5.org/forms.html. Specifically I'd like to use the email, url, search and numbers input types and add the "placeholder" and "required" attributes. If you don't know about the new input types read the introduction from the reference, the most important point being: "Which is to say, all of these features degrade gracefully in every browser. Even IE 6." All browsers treat input fields as "text" as before if they don't understand the new types.
Officially support Python 2.7
Currently we officially only support Python 2.6, whereas technically Python 2.7 works just fine. I think Python 2.7 has been around long enough now, so we can advertise its use. I'd like to suggest to switch to Python 2.7 for the installers and in our documentation, unless there's any specific concern for any specific platform. Python 2.7 is not yet available on all majors Linux distributions, so we should retain official support for Python 2.6 for the time being. But since Python 2.6 has moved to security-only support now, we should keep-up with the times.
I don't have the skills to work on this. But if anyone could please, please work on this and free us from KSS. I think it's close and it should give us a 50-100% speed improvement in actual browser rendering times as perceived by users. There's a whole lot of JS that we currently need to ship, that gets parsed and executed and contributes 50-100ms to page rendering times on the fastest and modern browsers - probably a lot more on older browsers. Whatever we do to improve requests/seconds with Chameleon or any other tricks is unimportant compared to reducing our JS weight.
(There are more suggested PLIPs from Hanno - which you can read by visiting here.)
The Framework team is beginning the process of reviewing and working on the PLIPs that will form the substance of our upcoming releases next year - and they are looking for people interested in both submitting and implementing. If you are interested in doing either, visit the links above or contact the Framework team about joining the effort.