The code4lib wiki is kind of a pain to use for this stuff, in part because MediaWiki isn't really suited for it. (I still think DokuWiki would work a lot better for Code4Lib in general. Anyone interested in volunteering to install/manage a dokuwiki install on code4lib.org? Assuming OSU would be okay with that).
But I think what you've identified is theoretically an appropriate use of Code4Lib community tools. I just worry that the tools we currently have aren't appropriate for the use you want to put them to! As far as your particular project (whose success I care about regardless of if it's using code4lib tools or not), I also worry that even with some communication and collaborative work taking place on the wiki, without strong management/facillitation, it's just going to be chaos and not result in anything useful. So I don't know if this plan gets you guys out of putting lots of time into it, if that's what you were hoping it would. But that's your team's business. :) Either way, yes, I think it is appropriate to use Code4Lib community tools for that project. But I'm not sure the tools we have available are appropriate for your project. Jonathan Emily Lynema wrote:
Many apologies for the cross-posting, but I wanted to make sure all the involved parties were fully represented. I have 2 questions that relate to the work of the ILS Discovery Interface Task Force [1], the work of the jangle community [2], and the code4lib community in general. 1. At the Discovery Interface Task Force breakout session at code4lib, there were many folks interested in moving beyond the abstract DLF recommendation document [3] to more detailed function specifications that could actually be implemented with specific technologies and metadata formats. While we'd love to be able to fully specify a single uniform API specification, those of us on the DLF group feel we lack the time, resources, nor expertise to do this without community input. The idea of providing a wiki where anyone could contribute ideas about implementing the recommended functionality (which would hopefully evolve into best practices over time) was well received at code4lib. However, DLF doesn't have an openly available wiki and may not be shepherding this work in the future. Code4lib.org *does* have an openly available wiki. At the same time, I see a lot of interest going into an API specification for jangle. I think these projects could work together on defining metadata formats and schemas that support the DLF functionality. But I don't know if the jangle specification will provide a direct mapping to the functions in the DLF recommendation. Jangle already has an open wiki hosted by Google Code (and a Drupal installation). In the spirit of democratic openness, I wanted to poll the community. Does it make sense to start a space on the code4lib.org wiki regarding implementation of the DLF recommendation? Is that an acceptable use of the wiki? Or does it make more sense to point to the jangle wiki as a place for discussion? 2. During the code4lib breakout session, we also discussed creating a wiki where library developers could share their past work to access data stored in the ILS (ex: I've written a function that retrieves live holdings in SirsiDynix, I've written a function that places a hold in Innovative, etc.). We would hope to move toward a point where the code could actually be posted and shared in an open source fashion (no one really knows about NDAs yet). Is this an acceptable use of the code4lib wiki? Google Code makes sense for posting code, but seems like overkill if all you need is a wiki. Please let me know if you have any input or suggestions. Thanks! -emily lynema [1] https://project.library.upenn.edu/confluence/display/ilsapi/Home [2] http://jangle.org - community-driven, open source project to create a uniform API specification across all ILS products as well as code for individual connectors for each individual ILS system to implement that API. Jangle could serve as a reference implementation / binding for the DLF recommendations, or the recommended DLF functions could be implemented on top of Jangle and its system connectors. [3] For the Feb. 15 draft, see Wiki: https://project.library.upenn.edu/confluence/display/ilsapi/Draft+Recommendation Word: http://tinyurl.com/2bzrje -- Emily Lynema Systems Librarian for Digital Projects Information Technology, NCSU Libraries 919-513-8031 [EMAIL PROTECTED]
-- Jonathan Rochkind Digital Services Software Engineer The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu
