R3.0 Plan for October 2009
September began with discussions and analysis about possible changes to the main web sites and thoughts about how to improve REBOL's message, marketing, promotion, etc. There were many comments on it, and I still go back and re-read, re-consider some of them.
All of this still weighs heavily on my mind. To most of techies, building and modifying websites often seems like trivial work... until you are faced with the realization that REBOL.com consists of more than 10000 files and REBOL.net has more than 64000. Then, you start doing the math... "if we can handle reworking 10 files a day..." It soon begins to look like a huge task.
That's when I become truly grateful that the site was built using REBOL, because many of those files can be rapidly reprocessed, reformatted, split or joined, or otherwise converted into whatever we require. For example, the new R3 Docs were converted from the old R2 docs (750 pages) in about a day. Certainly, there's more to do, but every bit helps.
However, I weigh that effort against the other side of the spectrum, such as clicking off 10 Curecode tickets a day toward the completion of R3. Frankly, that usually wins out because the R3 project has gone on too long to let it slow down now... as we approach the finish line.
And, with that being said, a lot of September went into parse improvements. It began with a few minor changes, but soon it descended into a full rewrite, twice. But, a lot was accomplished, and parse is really looking good. It's a powerful tool now, isn't it?
Last month I also gave out the Project Plan link for you to look over. Some of you were alarmed at what was missing. But, I would not draw too many conclusions from it. That page is now editable, so if you've got the power (you must have an adequate R3 Chat rating), you can edit it.
Also, start thinking about what you can do to help on that list. For example, a few people were looking for multitasking (smart-threads) on the list. While the lower level design already exists, various remaining issues can be solved by some of the experts in our development community. For example, what is needed on Linux and OS X to build a nice, portable threading model (with per-thread local storage.) It exists, but needs definition... and not a whole lot of code either. Another issue is which mezzanine functions require cleanup to avoid shared memory situations.
Goals For October
They're about the same as they were for September. But, actually, those were stated in a much too general way (not clear and measurable.)