don wrote
<blockquote>>
</blockquote>
I am truly eager to work with our ever-growing group of volunteers
and hope we all feel like we're part of a well-functioning team by
the time we're done with this project.
<<
i think the key to doing this is by creating enough documentation
artifacts that volunteers can quickly can get up to speed and become
productive developers (not to mention it assists in the process of
converting new users to developers). in this the openacs has been
lucky because in the past they could rely on the documentation
generated by aD. but as the openacs makes changes to the core
architecture, the onus of documentation falls upon us. this is why
private email discussions irk me so much, because it subverts the
process of documenting discussion on key issues, leaving the source
as the only documentation artifact. its also why i favor an email
list approach, because they offer the best means of examining the
development of a project in a consistent chronological fashion. i
think after the core is ported, all architecture changes should be
documented in some form of spec that discusses the problem, the
solution, the scope of both, and risk factors. this doesn't have to
be lengthy, a one page summary will do wonders. if we don't do this
than i have little doubt we will pay the price later. i've already
experienced this at my current job where i'm telecommuting around
the world, and now i'm paying the price.
