On Apr 29, 2009, at 7:29 PM, Howard Lewis Ship wrote:
On Wed, Apr 29, 2009 at 4:11 PM, Christian Edward Gruber
<christianedwardgru...@gmail.com> wrote:
...
project which could be versioned (or at least released) on a
different
cycle. This could keep (for any branch such as 5.0, 5.1) the docs
as fresh
as you wanted to release them.
This is how documentation is done today; it has the advantage that
docs are implicitly synchornized to the code (as long as
developers are dilligent about updating docs at the same time as code
changes). It has the downside of being
limited to just access by Tapestry committers.
It might be possible for a wiki to operate in the same way ... we
could have a Tapestry 5.1 space and, at the start of 5.2, we could
copy it to form the Tapestry 5.2 space. In this way,
the documentation for prior releases would be accurate (we could even
freeze the space), but would still be open to a community effort to
keep it up to date.
I'm not sure that docs are any less important to have commit rights
for than code. I think people should be submitting patches, or they
should be committers. Or maybe someone wants to be a committer with
focus on docs, to mediate the flow of community suggestions. I just
think that the difference between "published" and "contributed"
documentation is often quite high, and I think the information in
contributed docs should end up in the published docs ultimately (if
it's not redundant or irrelevant), I think having a little bit of a
gate on the documentation would be good.
Another option is to have an open repository where the docs live, and
can be manipulated - a set of community-oriented docs in a different
repo where more people can have commit rights. Then people can play
with docs, and people can move them into the "canonical" docs as
appropriate.
I'm still caffeine starved, so I may be over-thinking this.
Christian.
Christian Edward Gruber
christianedwardgru...@gmail.com
http://www.geekinasuit.com/
