Although I don't know if we could pull together a sufficiently
detailed product specification in time for a proposal submitted by
March 29, the biggest hole I'm seeing at the moment in our
hypothesized software map is the software for the documentation
We have three major tools that seem to be the most widely used so far:
-- LuaDoc (abandoned project) 
-- LDoc (successor to LuaDoc and mostly compatible with LuaDoc input) 
-- WebBook (PUC-RIO documentation tool) 
There seems to be consensus so far that we want to arrive at a
standardized input and ouput of documentation so that we might, for
1. Make a module of all modules' documentation that could be
separately downloaded and navigated;
2. A coresponding web site, web both the web site and the module
updated as needed by the CI process;
3. Conversion of the output reference format to a variety of formats
has also been mentioned as a requirement. Existing multiplatform
converters such as Pandoc  might play a role here.
The LDoc and WebBook inputs and outputs are incompatible. LDoc works
from documentation embedded in code comments, accepting either HTML or
Markdown for inline formatting, and outputs HTML+CSS to achieve a
sidebar table of contents plus a main content area that displays the
currently selected item's content. WebBook works from aggregated HTML
documents to produce a table of contents side bar in an HTML/CSS frame
with other frames that add some goodies, eg., java-script-based
search. Another difference is that WebBook enables a nested table of
contents while I've seen nothing but a plain list in LDoc. One major
drawback of WebBook is that because of its use of frames, annotation
by the user is difficult.
My sense is that we have agreement that we need a standard for
documentation and the means to implement it. But we have not discussed
thus far what that standard might be, how to implement it, and whether
the implementation might include conversion from LuaDoc, LDoc, or
WebBook. That is why I think we might have difficulty pulling together
a proposal before March 29.
On the other hand, if part of the project were to identify specific
product requirements, then a more general description of requirements
would be possible and we might then meet that deadline.
If we could, there are reasons to suspect that such a proposal might
be well received at Google if we emphasize:
-- Lua's under-publicized popularity;
-- The need for standardized documentation for Lua modules, in
conjunction with the Kepler Project's goal of package distribution.
-- The old Kepler project's web component modules (anything that
generates web pages is good for Google's business); and
-- The resulting opportunities for Google's products to process the
standardized documentation to better serve Lua users, e.g., syntax
highlighting, searching function definitions, etc.