Thanks for sharing this.  A few comments on your take-aways:

    * governance - the VUFind community could use a bit more structure and the 
application of project management

We formed the VuFind administration group last year largely to address this 
issue...  but the group hasn't been very active.  I definitely think we need to 
make an effort at next week's conference to discuss how we can improve this 
situation.  We have a lot of people doing great work on VuFind, but most 
loyalties are (understandably and appropriately) to local institutions first 
and the VuFind project second.  Since I work at the university that originated 
the software and have more time than most to view it at the project level, I've 
had a disproportionate influence on where the project has gone over the past 
year or so.  I'm pretty happy with how things have turned out so far, but I 
would welcome the addition of a bit more structure if we can find a way to 
ensure that others are able to contribute regularly without having an undue 
burden placed upon them.

    * patches - member-submitted patches need to be incorporated to the code to 
a greater degree; a couple of us felt our contributions were not accepted

I think the "ignored patch" situation dates back to the time that the VuFind 
project was temporarily between developers at Villanova.  The resulting period 
of slow activity allowed work to pile up, and by the time the backlog was 
examined, the software had moved on too far for certain old patches to apply.  
I feel that the situation has changed dramatically at this point -- I try to 
look at new patches as soon as I can, and I take the time to test patches and 
work with contributors to make them ready for inclusion in the trunk.  If there 
are still old unresolved patches that are important to people, please bring 
them to my attention.  I'll be happy to provide support in bringing them up to 
date for the latest version of the software.

I also really encourage complaining in public (i.e. on vufind-tech and 
vufind-general) if there are issues -- I think some of the early VuFind 
adopters dropped out of the public eye due to frustration with VuFind's 
temporary leadership vacuum.  However, things have changed a lot since then -- 
we have very active mailing lists, and I'm very interested in working with 
people to solve problems.  It helps if I know what the problems are, though!

    * authorities - a greater emphasis needs to be placed on integrating the 
profession's good work done in regards to named authorities

Agreed -- and something I've been working on (thanks largely to Ya'aqov Ziso, 
and with significant help from Ralph LeVan and members of the XC team).  I'll 
be presenting on our work so far at next week's conference, and additional 
collaborators are welcome!

    * local customizations - a possible solution to the "straying" issue may be 
the implementation of some sort of local code base, something Blacklight 
apparent has

I have been working on hooks throughout VuFind to make it easier to override or 
configure existing functionality without actually editing existing code: the 
"theme inheritance" mechanism, the record drivers, search objects, 
recommendations modules, even the way MARC import rules are set up.  Some of 
these things could probably stand to be documented better -- often the way of 
open source software.  I'm always open to adding new ways of customizing things 
in more places -- feel free to send me suggestions and requests.  I believe 
that Blacklight lets you create local overrides to any piece of the existing 
software thanks to the way the Rails environment is set up; VuFind's PHP 
environment isn't quite so structured, though evolution is always possible.  
However, no matter how clever you get, this is a situation where there is no 
magic bullet -- if the base code changes too much, the override code will 
break.  All any project can do is try to minimize disruptive changes and to !
 provide good hooks for customization.  Personally, I think just about the best 
thing anyone can do is learn to use change management software effectively -- 
no matter how well-designed the base software is, something like Git or 
Subversion will still make life easier when used appropriately.

    * "light" flavor - given the spectrum of programming skills available in 
libraries, some thought a VUFind "Light" may be in order

Perhaps the DEB package we've had since the 1.0 release qualifies as this -- 
installing it under Ubuntu is nearly a trivial process, so you can get the 
package up and running very quickly.  The only thing I can think of that would 
make this even easier would be some kind of GUI configuration tool to eliminate 
the need for editing ini files directly.  Not a high priority on my own to-do 
list right now...  but it might make a great project for some ambitious grad 
student somewhere.

    * repository - there is a need for a central place for the community to 
share local hacks, normalization routines, changes to the Solr indexer, etc.

We have a wiki (http://vufind.org/wiki/) and a JIRA instance 
(http://vufind.org/jira/) both open to the public...  not to mention the 
aforementioned mailing lists.  There should be an appropriate forum for sharing 
just about anything.  If you have suggestions on making this all more 
accessible, please share them!

Anyway, thanks again for taking the time to arrange this event -- it sounds 
like it was worth the effort.

- Demian

> -----Original Message-----
> From: Code for Libraries [mailto:[email protected]] On Behalf Of
> Eric Lease Morgan
> Sent: Friday, September 03, 2010 11:40 PM
> To: [email protected]
> Subject: Re: [CODE4LIB] vufind user's group meeting
> 
> An inaugural VUFind "Midwest" Users Group Meeting was held at Western
> Michigan University today, and I described my experiences there in the
> (fledgling) CRRA Blog. From the last paragraph:
> 
>   In summary, the meeting was definitely a success. Discussion was
>   thorough and focused. I believe we used our time wisely, and no
>   one went away thinking it had been wasted. I do not think the
>   group was representative of the whole VUFind community. We were
>   more skilled than most. We agreed that VUFINd was not broken, but
>   we did outline a number of ways it could be improved. We all
>   agreed that the implementation of VUFind in our institutions
>   represents a giant step forward compared to where we were at
>   least a few years ago.  oss++
> 
>   http://tinyurl.com/283n4kq
> 
> Any errors in interpretation are mine and mine alone.
> 
> P.S. "Thanks folks, it was both fun and useful."
> 
> --
> Eric Lease Morgan
> University of Notre Dame

Reply via email to