whit <[EMAIL PROTECTED]> writes: > > A while ago, I started this reference manual > > http://plone.org/documentation/manual/plone-developer-reference > > > w00t! I'm not sure alan got your reference into the appropriate place, > but the intention was to put this and similar info into > plone.org/developers . And all of you should have access to extend and > edit this section of the website.
Indeed. That said, I think people naturally look for documentation in plone.org/documentation, and I think non-core developers would benefit from peaking in on how we do things. That's why I think the more documentation oriented (as opposed to overview-oriented) material belongs in /documentation instead of /development, with links going back and forth, of course. > > The intention was to make a single places for Plone core developers to > > find the information they need on how to contribute, and how they > > should be coding. The idea was to cover three things: > > > > 1. How do I contribute to Plone? How do I write a PLIP, make a review > > bundle, get access to svn etc. > > > > 2. How do I write Plone code? Things like unit testing, migrations, > > coding style etc. > this will be very important in the near term, since best practices of > the last 2 + years are going to be changing a bit. Yeah, that was kind of my plan too :) > If you guys are up to it, it's a definite need. I would encourage you > to also look at the process and technology you are documenting and think > "If I was a new developer, would this seem sensible and easy, or > overwhelming?" The answer to that question might be the ground for new > PLIPs (for instance, BrowserDefault and EIOW could both benefit from > using the CA rather than their old school component approach). Good point! Martin _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
