[OPEN-ILS-DOCUMENTATION] ***SPAM*** RE: [OPEN-ILS-DEV] ***SPAM*** Re: ***SPAM*** Re: Forming Teams by Topic

[Soulliere, Robert]

Thanks Jason for the explanation of how SVN could work for documentation. I can understand it and it is very helpful.

Replace "Equinox" with "Evergreen developers".  Equinox has the most
Evergreen developers at the moment, but we shouldn't equate Equinox
with Evergreen.  The community can find equally capable folks outside
of Equinox.  However, I can (and do volunteer to) field patches
related to documentation and documentation features (like
context-sensitive help), but I'd quickly push for letting such patch
submitters become commiters, since I'm a lazy developer. :-)  I also
don't want to take on the role of a documentation editor.

I wonder if we could expand  "Evergreen developers" to "Evergreen Community". I think of developers as the having the role of developing code. The DIG, group which may include some developers, would commit the documentation updates/patches without disturbing the core developers. Would that be plausible? My main point here is that Evergreen has developed extremely rapidly in the past few years with a very small group of extremely hard working core developers. It seems the role of the DIG is to come in and try to catch up in regards to documentation without being a burden on the developers. While it does seem that the documentation is done in the "wild" and there is a lot of content out there,  I would expect the DIG to develop  their own workflow plan to bring it all together in one "place". Once we determine a "place", I do believe it will all come together!

"Working
closely" in the open source world can include discussions like this in
public mailing lists, so I'm not particularly interested in any sort
of private huddling, and I don't have any particular insight here,
just opinions.  We're doing okay, just keep the momentum going.  Even
if someone were to massively fund Equinox or other Evergreen support
and development companies to  help out more with documentation, I
wouldn't want to see the volunteer and cosmopolitan nature of DIG
change.

Yes, keeping the discussion out in the open is good. I also think it will be important for the DIG group to work closely with the context sensitive documentation team in order to minimize the duplication of work since some content should be similar and if it is updated in on place, needs to be updated in the other. I suspect the context sensitive help team could conduct a lot of their discussion on this documentation list, no?


It could, but if it were to exist within the same source repository,
all this versioning would happen essentially for free, and you might
spend less time trying to "synchronize" versions of the documentation
with versions of the source code.  A "bug-fix" version would get an
appropriate copy of the documentation, and documentation folks may not
have to concern themselves with it at all (the bug being "documented"
in a change log).

I agree 100% with Jason here. The model he set out would make updates much easier. The change log in SVN and other version control systems is an extremely beneficial tool for development and documentation.

Thanks,
Robert

This E-mail contains privileged and confidential information intended
only for the individual or entity named in the message.  If the reader
of this message is not the intended recipient, or the agent responsible
to deliver it to the intended recipient, you are hereby notified that
any review, dissemination, distribution or copying of this communication
is prohibited.  If this communication was received in error, please
notify the sender by reply E-mail immediately, and delete and destroy
the original message.