 |
 |
The problem is that the listserv is not good for brainstorming. Expecting any one person to have a fully baked solution (with hosting) before posting to the list is not going to happen. That's why I suggested an alternative discussion tool with the vote2promote feature. I also suggested the mentorship program as a way to get people to give back a little bit while also getting guidance. It's not going to happen overnight, but if anyone's interested in either being a mentor or mentee, sign up for the RailsBridge pre-conf. Again, it's not fully baked, but those who are interested can discuss it off list to brainstorm. -Shaun On 12/4/12 11:38 AM, Jonathan Rochkind wrote: > While I agree with ross in general about suggesting technical solutions > without suggesting how they are going to be maintained -- agree very > strongly -- and would further re-emphasize that it's improtant to > remember that ALL software installations are "living organisms" > (Ranganthan represent!), and need ongoing labor not just initial install > labor.... > > I don't agree with the conclusion that the _only_ way to do this is with > a "central organization" or "my organization which has shown > commitment through z" > > I think it IS possible to run things sustainably with volunteer > decentralized not-formal-organization labor. > > But my experience shows that it _isn't_ likely to work with ONE PERSON > volunteering. It IS more likely to work with an actual defined > collective, which feels collective responsibility for replacing > individual members when they leave and maintaining it's collective > persistence. > > Is that foolproof? No. But it doens't make it foolproof to incorporate > and have a 'central organization' (still need labor, paid or unpaid), or > to have an existing organization that commits to it (can always change > their mind, or not fulfill their commitments even without actually > changing their mind). There are plusses and minuses to both. > > I am a firm believer in code4lib's dentralized volunteer > community-not-organization nature. I may be becoming a minority, it > seems like everyone else wants code4lib to be Official? There are > plusses and minuses to both. > > But either way, I don't think "officiality" is EITHER neccesary NOR > sufficient to ensure sustainability of tech projects (or anything else). > > But i fully agree with rsinger that setting up a new tech project > _without_ thinking about ongoing sustainability is foolhardy, unless > it's just a toy you don't mind if it disappears when the originator > loses interest. > > On 12/4/2012 11:08 AM, Ross Singer wrote: >> Shaun, I think you missed my point. >> >> Our Drupal (and per Tom's reply, Wordpress -- ...and I'm going to >> take a stab in the dark and throw MediaWiki instance into the pile) >> is, for all intents and purposes, unmaintained because we have no in >> charge of maintaining it. Oregon State hosts it, but that's it. >> >> Every year, every year, somebody proposes we ditch the diebold-o-tron >> for "something else" (Drupal modules, mediawiki plugins, OCS, ... and >> most recently Easy Chair), yet nobody has ever bothered to do >> anything besides send an email of what we should use instead. >> Because that requires work and commitment. >> >> What I'm saying is, we don't have any central organization, and thus >> we have no real sustainable way to implement locally hosted services. >> The Drupal instance, the diebold-o-tron (and maybe Mediawiki) are >> legacies from when several of us ran a shared server in a colocation >> facility. We had skin in the game. And then our server got hacked >> because Drupal was unpatched (which sucked) and we realized we >> probably needed to take this a little more seriously. >> >> The problem was, though, when we moved to OSU for our hosting, we >> lost any power to do anything for ourselves and since we no longer >> had to (nor could) maintain anything, all impetus to do so was lost. >> >> To be clear, when we ran all these services on anvil, that wasn't >> sustainable either! We simply don't have the the organization or >> resources to effectively run this stuff by ourselves. That's why I'm >> really not interested in hearing about some x we can run for y if >> it's not backed up with "and my organization which has shown >> commitment through z will take on the task of doing all the work on >> this". >> >> -Ross. >> >> On Dec 4, 2012, at 10:41 AM, Shaun Ellis <[log in to unmask]> >> wrote: >> >>> Tom, can you post the plugin to Code4Lib's github so we can have a >>> crack at it? >>> >>> Ross, I'm not sure how many folks on this list were aware of the >>> Drupal upgrade troubles. Regardless, I don't think it's >>> constructive to put new ideas on halt until it gets done. Not >>> everyone's a Drupal developer, but they could contribute in other >>> ways. >>> >>> -Shaun >>> >>> On 12/4/12 10:27 AM, Tom Keays wrote: >>>> On Tue, Dec 4, 2012 at 9:53 AM, Ross Singer >>>> <[log in to unmask]> wrote: >>>> >>>>> Seriously, folks, if we can't even figure out how to upgrade >>>>> our Drupal instance to a version that was released this decade, >>>>> we shouldn't be discussing *new* implementations of *anything* >>>>> that we have to host ourselves. >>>>> >>>> >>>> Not being one to waste a perfectly good segue... >>>> >>>> The Code4Lib Journal runs on WordPress. This was a decision made >>>> by the editorial board at the time (2007) and by and large it was >>>> a good one. Over time, one of the board members offered his >>>> technical expertise to build a few custom plugins that would >>>> streamline the workflow for publishing the journal. Out of the >>>> "box", WordPress is designed to publish a string of individual >>>> articles, but we wanted to publish issues in a more traditional >>>> model, with all the issues published at one time and arranged in >>>> the issue is a specific order. We could (and have done) all this >>>> manually, but having the plugin has been a real boon for us. >>>> >>>> The Issue Manager plugin that he wrote provided the mechanism >>>> for: a) preventing articles from being published prematurely, b) >>>> identifying and arranging a set of final (pending) articles into >>>> an issue, and c) publishing that issue at the desired time. >>>> >>>> That person is no longer on the Journal editorial board and >>>> upkeep of the plugin has not been maintained since he left. We're >>>> now several WordPress releases behind, mainly because we delayed >>>> upgrading until we could test if doing so would break the >>>> plugins. We have now tested, and it did. I won't bore you with >>>> the details, but if we want to continue using the plugin to >>>> manage our workflow, we need help. >>>> >>>> Is there anybody out there with experience writing WordPress >>>> plugins that would be willing to work with me to diagnose what >>>> has changed in the WordPress codex that is causing the problems >>>> and maybe help me understand how to prevent this from happening >>>> again with future releases? >>>> >>>> Thanks, Tom Keays / [log in to unmask] >>>> >>> >>> -- Shaun D. Ellis Digital Library Interface Developer Firestone >>> Library, Princeton University voice: 609.258.1698 | >>> [log in to unmask] >> >> -- Shaun D. Ellis Digital Library Interface Developer Firestone Library, Princeton University voice: 609.258.1698 | [log in to unmask]