Greets, I was hobnobbing with Joe Schaefer on IRC while he perused the Lucy code base and he suggested that we adopt a convention used by the Apache HTTPD project: keep a to-do list in a "STATUS" file at the top level of trunk, alongside README and such.
https://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS Two other alternatives are to use JIRA milestones, or a wiki page. My preference, though, would be for the STATUS file, as I think it will be easiest to manage and will yield the most the most coherent and easily consumed presentation over time. The HTTPD folks use CTR (commit-then-review) for adding to their STATUS file on trunk, so any committer can add a TODO item. It's RTC (review-then-commit) for adding to STATUS on stable branches. That makes sense to me as a policy. I think we should expect a certain degree of courtesy from each other with regards to the addition of potentially controversial action items. My sense is that we've been doing pretty well at building consensus via the dev list before investing time working up patches; we don't to find ourselves working out differences of opinion about project direction or priorities over multiple commits to the STATUS file. In that spirit, here's a seed list of items I suspect no one will object to: * Port the Clownfish compiler to C. * Replace dependency on Parse::RecDescent within Clownfish::Parser with the Lemon parser generator. * Add Ruby and Python bindings. * Refactor away C89 idioms, since we have chosen the intersection of C99 and C++ as our C dialect. * Port most test files within trunk/perl/t/ to C. * Replace dependency on JSON::XS with ??? (LUCY-133). I should probably go open JIRA issues for those that don't have them to explain at greater length and to track progress. If this sounds like a good plan to people, I can go build an initial STATUS file for Lucy using the HTTPD example as a template. Marvin Humphrey
