[Framework-Team] Documentation for 4.1 PLIPs
Hi folks, We did a quite good job documenting the changes introduced by the 4.0 PLIPs. As a result, we have a great Plone 3 → 4 upgrade guide that helps people to port their add-ons to Plone 4, use blobs, etc. I'd like to continue doing things right also with Plone 4.1, so if you don't have written documeantation for your PLIP already, please do so. You can write it as a comment in the PLIP ticket in Trac and we will figure out later where to place it. Some questions you might want to answer: - Does this PLIP introduce a new feature, or rather does it change the way people should do things in Plone? - I maintain an add-on product. Which changes will my product require after this PLIP? Or, how can I use this new feature? (example: blobs) - I'm a site admin. How will this change they way I manage the site? (examples: email login, "Site Admin" role) - I'm a normal user. How will this change my experience? (examples: TinyMCE). Thanks! -- israel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Fwd: plone.app.discussion UI review
I'm not part of either of the teams but just a couple of comments. On 02/12/10 19:28, Timo Stollenwerk wrote: > Hi Plone UI team, > > I would like to discuss some UI related issues that were raised during > the PLIP review of plone.app.discussion (by eleddy and cah190). > > https://dev.plone.org/plone/ticket/9288 > >[...] > PLIP REVIEW: The delete button to the far right of the comment is > insanely confusing. I think this could use some UI review. > > QUESTION: See screenshot attached (pad-delete-button.png). I moved the > delete button away from the reply button for two reasons: 1) I wanted to > avoid clicking the delete button by accident if a user wants to reply. > 2) To make it more clear which comment is deleted when hitting the > button. I'm happy to hear any suggestions for improving the UI. > I agree with separating the Delete button from the Reply one. It's a wise decision. I'd replace the "Delete" button by a cross sign or a trashcan icon, with the title and alt attributes "Delete comment". -- israel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PloneConf2010 FWT Dinner
Hi! Count me in! Not very expensive place, please. -- israel 2010/10/28 Eric Steele > Let's plan on Friday night for a Framework Team dinner. FWT alumni are > invited, as well as whatever UI team members are here. I'd also like to have > Israel, as our de facto docs team leader, join us. > > Any suggestions on a location? > > Eric ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Improving the process -- PLIP UI and Documentation
On Sat, May 22, 2010 at 1:37 PM, Hanno Schlichting wrote: > On Sat, May 22, 2010 at 5:09 AM, Martin Aspeli > > > wrote: > > 2010/5/22 Eric Steele : > >> FWT! > >> > >> I want to introduce two additions to the PLIP process that I'd like us > to add into the Plone 4.1 process. > > > > +1 to both > > +1 as well +1 from my side too! :) -- israel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Documenting the process
2010/4/26 Hanno Schlichting > 2010/4/26 Israel Saeta Pérez : > > Any progress here? It would be very, very helpful for GSoC... :) > > Not much. I started by copying over the bits from various sources into > one place, so all we had written down somewhere is now at > http://dev.plone.org/plone/wiki/Development. The "core developer > manual" from plone.org is gone as well. > > The next step is to reorganize the information into one structure and > then update it. I'll continue to work on that :) > > Not much?! This is already a lot! Thank you very much for taking care of this, and of course don't hesitate to ask for help where you need it. :) One thing we can do to decide the structure is think about what info would we want to find when contributing to an external project. Imagine you want to contribute to Drupal or similar. Example: - I think I've found a bug. Where should I report it? (add-on products, documentation, plone-core, plone.org, translations...) - How do I set up a development instance? - I've found a bug in the code and have a proposed patch. How should I apply it? Do I have to request review and how? - I've written an add-on product and think it's so useful that it (or a slightly modified version) should be included with Plone. What's the process to ask for inclusion of a new feature? - I want to translate a product (either add-on or Plone itself). How do I do that? - I know how to do something and would like to write documentation about it. Where should I place the docs? - ... -- israel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Documenting the process
Hanno Schlichting wrote: > Hi. > > 2010/3/24 Israel Saeta Pérez : >> http://plone.org/documentation/manual/plone-core-developer-reference is the >> place for this kind of documentation. >> >> I'd prefer to keep all documentation in the same place instead of spreading >> it over plone.org and the Trac wiki. > > I talked briefly to Eric and Israel about this. I'll start working on > this over the weekend / next week and we'll move everything into the > Trac wiki to have all "development of Plone" information in one place. Any progress here? It would be very, very helpful for GSoC... :) -- israel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Documenting the process
Eric Steele wrote: I'm finding that I'm consistently wrong about how I think whole Plone thing works. Every assumption I had coming into this job has been met with some sort of "No, we have a process. It's just not documented". Let's fix that. I'm looking for some help in actually writing down the process of how a major release of Plone comes together. Rough list of necessary parts would be: * Choosing a FWT * Choosing a release manager * The role of the FWT * The role of the Release Manager * PLIP review process * By what standards is a PLIP judged? * By what standards is a PLIP implementation judged? * Creating the release Suggestions for missing sections? Anyone willing to help me write this? I'm willing to help on this for sure! Just mail me directly or ping me on IRC if you need quick help since I don't read this mailing list too often. http://plone.org/documentation/manual/plone-core-developer-reference is the place for this kind of documentation. I'd prefer to keep all documentation in the same place instead of spreading it over plone.org and the Trac wiki. Why are you using the Trac wiki instead? Permissions issues? -- israel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP 10359 for Plone 4.1 - Convert control panels to use z3c.form
Hanno Schlichting wrote: Hi there, I've written a new PLIP that I'll hope to submit for Plone 4.1 "Convert control panels to use z3c.form" available at http://dev.plone.org/plone/ticket/10359. I'll start the work on the PLIP shortly, so if anyone sees any major problems with it or has other suggestions, I'd welcome any early feedback. I'm glad you're moving this forward - I had a quite hard time dealing with zope.formlib in the control panels recently. :S Does z3c.form include a more intelligent password field? See https://dev.plone.org/plone/ticket/9689 -- israel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone 4 - holidays are over :)
Hanno Schlichting wrote: 1.8 (2008-04-05) Added console command to the instance script, which is equivalent to fg but does not implicitly turn on debug mode but respects the zope.conf setting. [hannosch] One month later we changed it not to fork a process internally, so this is what we've been using for supervisord configurations for years. I've updated http://plone.org/documentation/manual/developer-manual/managing-projects-with-buildout/creating-a-buildout-for-your-project to reflect the availability of this command: """ Running: bin/instance console is equivalent to bin/instance fg, but does not implicitly turn on debug mode but respects the debug-mode setting in buildout.cfg. This can be useful to run Zope in non-development mode with daemon-control programs like supervisord. """ I hope it's ok. :) -- israel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP Community Imapacts
On Sat, Mar 14, 2009 at 6:07 PM, Ross Patterson wrote: > I guess what I'm proposing is either an additional documentation effort > or a further clarification or honing of the intention of documentation > efforts associated with PLIPs. Specifically, that some effort to > address community impact should be a part of documentation efforts. > > Just to collect feedback, is your comment that you don't think this > additional intention/focus doesn't bring additional value sufficient to > formally include it in the PLIP process? > No, I think I've understood you wrong and I was talking about a different thing. :S I agree with you on trying to open up the discussion about Plone 4 future features and changes to the community, but don't really understand yet how would you like to integrate that with the PLIP process. Sorry. -- israel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP Community Imapacts (was: Quick team meeting)
On Fri, Mar 13, 2009 at 7:16 PM, Ross Patterson wrote: > Ross Patterson 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. I proposed adding an explicit, formalized part > > of the PLIP procedure for community impact assessments. I'd love a > > better name, but the idea is a place to communicate to the various > > parts of Plone communities (developers, integrators, themers, users, > > etc.), "Here's what you need to know to update your code/skills. > > Here's where to find documentation." I offered to take the lead on > > this. > > One of the hopes I have for this is that many times when a PLIP > contributor goes to say "Here's where to find documentation", they'll > discover it doesn't yet exist and that these discoveries might be a part > of substantially improving Plone documentation. > > At any rate, I'd like to open this up for discussion on this thread. > We're already working on PLIPs' documentation and hope each Plone new version now comes with updated docs at plone.org reflecting improved and new features, so all the community will be able to benefit from them. :-) -- israel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #247 ready for review (I think)
On Sun, Jan 18, 2009 at 8:48 PM, Israel Saeta Pérez wrote: > On Sat, Jan 17, 2009 at 2:37 AM, Ethan Jucovy wrote: > >> >> Some of the things that people have said ought to be discussed about PLIP# >> 247 are: >> 1) impact on server startup time >> 2) implications for test environments >> 3) stabilizing and releasing a new version of z3c.autoinclude >> 4) debugging tools/APIs for z3c.autoinclude >> * 5) documentation and/or code generation templates to explain the entry >> point for plugin authors* >> >> I'll begin working on #3 immediately, since there's plenty I can do there >> while discussion is still happening. >> >> Please let me know if there's anything else I'll need to submit for the >> PLIP's review. >> > > I'm not a member of the Framework Team so this is not mandatory for the > PLIP's review, but as a member of the Documentation Team I would > appreciate number (5). > > Something like "Before, we did this to accomplish this task. Now, we can do > that.", as Wichert (?) suggested, so we would be able to find and update > affected docs easily. > > Thanks in advance! > The buildout manual has been updated (but updates are still private) to reflect this new feature: http://plone.org/documentation/tutorial/buildout/copy_of_creating-a-new-package See the new "Automate ZCML loading for your package section". I would appreciate any review input since I'm not sure I've got it right. Thanks! -- israel Documentation Team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #239 ready for review
On Sun, Jan 11, 2009 at 6:56 PM, Martin Aspeli wrote: > Hello team, > > I've just finished the base implementation of PLIP #239, adapterise the > ExtensibleIndexableObjectWrapper, for your review. > [...] > The bulk of the code is in a new package, plone.indexer. You can read its > doctest here: > http://dev.plone.org/plone/browser/plone.indexer/trunk/plone/indexer/README.txt > I've just wrote a short page in plone.org (still a private draft) to document this feature: http://plone.org/documentation/tutorial/using-portal_catalog/custom-indexing-strategies Would anybody mind quick-reviewing it? -- israel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #247 ready for review (I think)
On Sat, Jan 17, 2009 at 2:37 AM, Ethan Jucovy wrote: > > Some of the things that people have said ought to be discussed about PLIP > #247 are: > 1) impact on server startup time > 2) implications for test environments > 3) stabilizing and releasing a new version of z3c.autoinclude > 4) debugging tools/APIs for z3c.autoinclude > * 5) documentation and/or code generation templates to explain the entry > point for plugin authors* > > I'll begin working on #3 immediately, since there's plenty I can do there > while discussion is still happening. > > Please let me know if there's anything else I'll need to submit for the > PLIP's review. > I'm not a member of the Framework Team so this is not mandatory for the PLIP's review, but as a member of the Documentation Team I would appreciate number (5). Something like "Before, we did this to accomplish this task. Now, we can do that.", as Wichert (?) suggested, so we would be able to find and update affected docs easily. Thanks in advance! -- israel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #246 ready for review (pending review notes)
On Sat, Jan 17, 2009 at 10:44 PM, Andreas Zeidler wrote: > On Jan 17, 2009, at 4:37 PM, Andreas Zeidler wrote: > >> as a heads-up, the review bundle for PLIP 246 (View for rendering events >> as an iCalendar file) is ready for review. you can get it from >> https://svn.plone.org/svn/plone/review/plip246-ical-feed/ >> >> it does not yet contain any review notes (as i need to go afk now), but >> i'll add them tonight. >> > > the review notes are available now in the bundle's top-level `README.txt` > file. > For documentation purposes: Is there any change in the UI to reflect the new available option? -- israel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4 Framework Team Selection List
On Tue, Dec 16, 2008 at 6:37 PM, Steve McMahon wrote: > The Plone 4 Framework Team has been selected. Congratulations to: > Matthew Wilkes, David Glick, Calvin Hendryx-Parker, Laurence Rowe, > Martijn Pieters, Erik Rose, and Ross Patterson. As anyone who's been > following Plone development will immediately see, this is an awesome > team! > Huge congratulations to the new framework team! I'm sure you'll give your best. :-) -- israel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Fwd: Including a Documentation section in each PLIP
On Sat, Nov 15, 2008 at 6:01 PM, Wichert Akkerman wrote: >> > I would much rather see the equivalent of the what-is-new-in-python-x.y >> > documents: a thorough explanation of every change, its rationale, and >> > the inpact that has on both existing and new code. That would then be a >> > very useful starting point for the documentation team to update/extend >> > other documentation. >> > Israel Saeta wrote: >> If the documentation has to wait for version releases it will always >> be behind code, which leads (among other causes) to the actual state >> of some areas of the plone.org documentation: outdated. Of course the >> documentation team has great responsibility here, but trying to keep >> code as important as code will help. Wichert Akkerman wrote: > You misunderstood my point. What I want to see is for each PLIP to have > the equivalent of a section of the what-is-new-in-python-x.y documents. > That does not require waiting for a release. Uh yes you're right I've misunderstood you, my apologies. Maybe I'm behaving in a bit too defensive way here, sorry. I would be ok with any text explaining the impact of the PLIP in the way we develop with, customize, or manage Plone. Links to existing documentation that would become obsolete could be optional. Some trivial examples: - http://plone.org/products/plone/roadmap/238 Inline editing will be disabled by default. Update User Manual http://is.gd/7El5 . - http://plone.org/products/plone/roadmap/223 Theming resources based on base_properties.props will become deprecated in favour of zrt resources. -- Israel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Fwd: Including a Documentation section in each PLIP
On Sat, Nov 15, 2008 at 5:08 PM, Wichert Akkerman wrote: > Previously Martin Aspeli wrote: >> I do agree that documentation should be part of PLIPs. One simple thing >> would be to just have a free-text on the PLIP that identifies the >> documentation that is either required or extant for the PLIP, so that >> people who look at the PLIP later can find a pointer to where there's >> more documentation. > > I would much rather see the equivalent of the what-is-new-in-python-x.y > documents: a thorough explanation of every change, its rationale, and > the inpact that has on both existing and new code. That would then be a > very useful starting point for the documentation team to update/extend > other documentation. If the documentation has to wait for version releases it will always be behind code, which leads (among other causes) to the actual state of some areas of the plone.org documentation: outdated. Of course the documentation team has great responsibility here, but trying to keep code as important as code will help. IMO we should try to update at least the most general documentation (manuals and important tutorials) before each release. To avoid problems, we could start with 2 or 3 easy-to-document PLIPs and see if we can manage to get relevant docs updated timely. -- israel @plone-docs: read the whole thread at http://is.gd/7DTi . ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Fwd: Including a Documentation section in each PLIP
On Sat, Nov 15, 2008 at 2:15 PM, Martin Aspeli wrote: > I am not convinced that the Documentation Team at this point has enough > structure (both in terms of the actual corpus of documentation, and the team > itself) to facilitate this kind of process. There's been some very > encouraging movements on the doc list in the last few weeks, but like > Raphael, I'd be worried about this clogging up a process that's already > stretching the current team. > > I do agree that documentation should be part of PLIPs. One simple thing > would be to just have a free-text on the PLIP that identifies the > documentation that is either required or extant for the PLIP, so that people > who look at the PLIP later can find a pointer to where there's more > documentation. > > However, I think it's too much to ask at this point that the framework team > or PLIP authors go through all existing documentation looking for things > that may be outdated. We're likely moving towards splitting documentation into official and community parts, with the official one involving a continuous review process to ensure it's up to date and reliable. I agree with you: neither the PLIP submitter or the Framework Team can browse through *all* existing docs looking for obsolete practices, but we should try to document each new feature or change in at least one "authoritative" document, i.e. theming, archetypes or GS manuals. A documentation section with a few lines in each PLIP identifying changes in development, administering, customization or UI, maybe linking a example document that must be updated should be enough. Is this simple enough to start without clogging up the PLIP submit and review process? I hope so. -- Israel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Fwd: Including a Documentation section in each PLIP
On Sat, Nov 15, 2008 at 4:57 AM, Raphael Ritz wrote: > Steve McMahon wrote: >> >> Hi Framework Team, >> > > Hi Steve and Israel, > > first of all thanks for bringing this up. > > Just one personal comment from my side: > > I think I do understand where this is coming from > and I really appreciate the intention. > But (there's almost always a but in real life > isn't it ...) lets try to be realistic: > > First, I'm much in favor of having the PLIP process > as easy as possible. First and foremost we should > be interested in ideas and implementations I think. > Everything else should follow from there. > > Second, it is my understanding that much of what's > proposed here should be the responsibility of the > framework team. At least I usually try to point out > where I think documentation (be it new or an update) > is needed on an individual basis. > > Don't get me wrong but I seriously think that raising > the bar for submitting PLIPs or accepting them beyond > of what we require today already might be problematic. > > Others may disagree, of course, but I only want to stress > the fact that it is one thing to formulate wishful thinking > and another to value openness and accessibility. Dear Raphael, Thanks for your cents! :-) I don't mind who actually identifies documentation that would need to be updated, if the PLIP submitter or the Framework Team, but I'm convinced every new feature or change should be reflected into the existing documentation, which is IMO as important as code and features. If we don't document new features as we introduce them, we will end up with obsolete documentation, as is already happening. If we don't like raising the bar for submitting PLIPs, at least we should commit to (really) introduce documentation in the release checklist: http://plone.org/development/teams/framework/process/ I'm sure the Documentation Team will be happy to collaborate with the Framework Team to get things done timely. -- Israel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
