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. _______________________________________________ OPEN-ILS-DOCUMENTATION mailing list [email protected] http://list.georgialibraries.org/mailman/listinfo/open-ils-documentation
