So I have decided I need a few more babies after putting my first OSS baby aka MDB2 to rest. Speaking of rest .. one of my new babies will be reSTed from the very beginning. The goal is to convert all of the various README type files in cvs.php.net into the reST format. This will enable us to render them to html and docbook while still keeping them plain text readable. For now I have used the Horde Text_reST package, which doesn't do everything one would hope for (I am having some issues with lists and there is also no docbook renderer). Hopefully the folks at eZ will come through with a fancy new parser/renderer one of these days. At least Derick said its on their agenda.

As part of this effort I just did my very first commit on php-src updating the CODING_STANDARDS to the rEST format. For a second I pondered pulling a "rider" and simply sticking in the guideline I am pretty sure we decided early on when exceptions were brought to PHP: No core extension should throw an exception by default for anything but constructor errors. When I brought up adding this to the CS a few people claimed this was never decided and so far I have been too lazy to dig through the archives to proof them wrong.

This brings me to one of the other two babies in the pipeline, which will probably not see the light of day before I return from Brazil, were I will be speaking at PHP Brasil and playing at the beach ultimate world championships, on December 19th. I am pondering of launching is an internals@ thread summary service. I think this could be an even more important addition to the PHP development process than the todo wiki I created about 2 years ago. The idea is that at this service I would summarize important threads, any decisions made. It would contain links to key postings and everything would be tagged to make it easy for people to more quickly find out if a topic was discussed before and if so what came out of the given discussion.

I am hoping that this will make life easier for new comers to not get slapped with "search the archive" type reply with little hope of really finding answers within the endless back and forth. It will also help prevent a tactic that has unfortunately worked too well for to long: People would just resubmit something for discussion often enough until the opposing people are either not around or too bored out of their minds to keep some feature out of cvs. So the ultimate goal is to make discussions more transparent and efficient. I am still not sure how to best approach this from a work perspective but also from how to present this information. If you have some ideas or comments please let me know.

The other project I am considering is taking over the DBAL part of Doctrine. Currently that nice DBAL, which heavily draws upon MDB2, is sitting a bit hidden underneath and only gets as much love as is needed for the ORM on top. Taking over the DBAL part will again give me an OSS coding outlet, plus it will free up Konsta to focus more on the ORM part. Of course it will also hopefully result in more people considering the Doctrine DBAL even if they do not care for an ORM.

I hope you'll consider contributing to Text_reST - at least in the form of bug reports, giving us a chance to improve the package.

Hey Chuck,

I was hoping that someone at Horde would say that. I actually mailed a link to this article as an FYI to both authors listed on the homepage of Text_reST on the Horde site. I will be sure to file bug reports (so far I noticed two bugs). One thing though, the Horde bug tracker seems to be focused on the Horde applications and not so much on individual packages, or am I missing something?