All- As Nat has mentioned on -meta, it's time to start wrapping things up. In particular, I think the following "deadlines" should apply: 1. Any and all *new* RFC's should be submitted by Wednesday at the absolute latest (preferably sooner). 2. All existing RFC's should have their final "developing" versions posted by this Friday, Sep 22nd, at the latest. 3. All RFCs should be frozen by the following Wednesday, Sep 27th. The hard deadline is Sep 30th for frozen RFCs. I will make no efforts to enforce these "deadlines", however please consider that the sooner your frozen RFC is done, the sooner Larry will be able to evaluate it. He's making his decision in about 3 weeks, so the sooner the better. I will make a final dredge through this weekend and will post a list of those RFCs still in need of updating Monday (but you probably know who you are). When freezing your RFCs, please add a section up top called "NOTES ON FREEZE", under the ABSTRACT section. In this section, please include a brief little synopsis: a) what the general consensus was b) any specific highlights or issues to be resolved still c) any dependencies on other RFC's This section should be brief and honest. For an example, please see RFC 164. The intent here is to clarify key points, and avoid giving Larry RFCs that would have a top section that looked like this: =head1 NOTES ON FREEZE Everyone else hated this idea, but I really like it, so screw everybody, I'm freezing it anyways. If your idea was disliked overall, be honest with yourself and others. I've retracted 3 of mine personally already because they ended up being real stinkers, or superceded by better ideas. If you retract your idea, an optional "NOTES ON RETRACTION" section would be nice, since it could help ideas from being brought up again in the future. For an example of this, please see RFC 175. Final words: Let's try to avoid flooding the list with last-minute RFCs. Let's try to get the main ones out there that could affect the fundamental shape of the language. Other stuff can be added as we see fit later in Perl 6.0.1, 6.0.2, etc. And if you have a problem with an existing RFC, please don't submit a counter-RFC as your first course of action. Please try first contributing to existing discussions and reaching consensus, since that has worked quite effectively so far. Your sublist footstool, Nate