If it is possible for the git repo to accept pull requests, I would be interested in setting up a staging environment. I don't doubt that others share this interest. The cost to run this on AWS with a small amount of sample data would be manageable for a community effort.
On Apr 7, 2013, at 18:58, Karen Coyle <[email protected]> wrote: > > > On 4/7/13 6:31 PM, Tom Johnson wrote: >> That sounds wonderful. I'd be happy to help you sort out the questions >> about ISBNs, etc... >> >> If such definitions were available, would we be able to get them >> committed and running on the main site? > > I don't know that we can count on that, but obviously it would be ideal. > While volunteers have run bots against OL, I don't think anyone has made > changes to the basic displays. This is a question that we'll need to > take up because, AFAIK, there are no longer any UI developers on the > project. > > One thing that always frustrated me was not having a test version of OL > to work with. I was always used to doing changes on a test system, and > it makes me extremely nervous to work directly on a system in > production. I don't know how the UI changes were originally done - > whether there was a test system available. (The UI team was very > skillful and I suspect that the code in that area is fairly > sophisticated.) I think that Anand has his own test set-up. How does > that usually work in an open source project? Is there a test instance > for everyone, or are people expected to create their own? > > kc > >> >> >> On Sun, Apr 7, 2013 at 6:28 PM, Karen Coyle <[email protected] >> <mailto:[email protected]>> wrote: >> >> If I recall correctly, at one point I had created a short definition for >> each term on the edit page. I can't find it, but could re-create it. The >> idea was that someone editing could have a mouse-over explanation of the >> meaning of the term. I think this would be helpful, and obviously anyone >> not wanting to know could simply not mouse-over. (The OL director at >> that time was strongly against any "rules" for editing. I think there is >> a difference between a definition and rules, but I lost that battle.) >> >> Should I go ahead with this? It would have to be a wiki document for >> now, since we don't have a way to add it to the edit page, but at least >> it would be preparation for such a facility. >> >> There are, however, things I don't know, such as what the software does >> with, say, hyphens in ISBNs, but I could call out those questions and we >> could work on them. >> >> kc >> >> On 4/7/13 6:18 PM, John Rigdon wrote: >>> All good questions and thanks for taking the time to put this >> together. >>> I'm not prepared to comment on any of them now as I'm, brain-dead >> from >>> working on taxes all day, but I will chime in over the coming week. >>> >>> It occured to me in reading through this that I have been >> struggling with >>> "definitions of terms" and not really recognized the point til now. >>> Perhaps one of the first things we need to do is put together a >> glossary >>> of terms so we will all know we're talking about the same things. My >>> background is not is library science and although I've done extensive >>> research and work comfortably in 3 languages, and a half-dozen >> Computer >>> languages, I'm not sure I can give you an "elevator definition" >> of what a >>> "work" is vs. an "edition" and how these record "merges" are >> important or >>> implemented, etc. >>> >>> John Rigdon >>> >>> >>> >>>> Hi! I'm not sure how to reply to a thread made before I joined >> the list, >>>> so >>>> I'll have to start a new one. A bit of a wall-of-text, sorry! >>>> >>>> When reading the "Data consistency >>>> >> >> policy<http://www.mail-archive.com/ol-discuss%40archive.org/msg00814.html>" >>>> thread in the archives, I realised OL doesn't seem to have any >> guidelines >>>> at all, and some people were suggesting that should change. >> Strict rules >>>> are obviously a problem: both music and books have the tendency >> to find >>>> the holes in every single rule you can think of (we in >> MusicBrainz are >>>> quite proud our community of walking edge-case generators). But >> without >>>> having some idea of what's the desired state of data, it's hard >> to make >>>> any >>>> improvements on it. >>>> >>>> I'm the new guy here, but I also happen to be the "style leader" >> (that is, >>>> the guy in charge of the guideline processes) in MusicBrainz, so >> of course >>>> I felt the urge to try to reach a set of basic OL guidelines and >>>> documents. >>>> We have a fairly insane amount of them ( >> http://musicbrainz.org/doc/Style >>>> ) >>>> but something much more simple should do, at least in the >> beginning :) >>>> >>>> I've added >>>> >> >> http://openlibrary.org/community/guidelines<http://openlibrary.org/community/guidelines?m=edit> >>>> and >>>> listed some of the issues I can, from my MB experience, see as >> useful to >>>> settle. I'm fairly new here, so I expect some of these are >> settled issues >>>> - >>>> that's much better then, but they should still be put in writing >> so that >>>> future editors can see them. I'm also sure other people can >> think of more, >>>> so we should add them there. >>>> >>>> If people think the whole thing is stupid, feel free to shout at >> me - if >>>> you think it's useful, let's try to advance on this. At >> MusicBrainz we >>>> work >>>> based on consensus - hopefully that will also be possible here >> but if >>>> people would prefer voting, that's also a possibility. >>>> >>>> Some of the notes are proper guideline stuff (where there is a style >>>> decision to take). Some are more of a design question, but they >> should >>>> still be documented (and in some cases, maybe rethinked). Of >> course, a >>>> good >>>> few will require coding changes and thus might be wishful >> thinking as of >>>> now, but it seems more reasonable to decide what we'd *want*, >> even if it's >>>> not yet possible with the existing code, and then find ways to >> accommodate >>>> until that changes. It would also help give some pointers on >> things to >>>> work >>>> towards for the developer(s). >>>> >>>> Cheers, >>>> Nicolás >>>> _______________________________________________ >>>> Ol-discuss mailing list >>>> [email protected] <mailto:[email protected]> >>>> http://mail.archive.org/cgi-bin/mailman/listinfo/ol-discuss >>>> To unsubscribe from this mailing list, send email to >>>> [email protected] >> <mailto:[email protected]> >>>> >>> >>> >>> _______________________________________________ >>> Ol-discuss mailing list >>> [email protected] <mailto:[email protected]> >>> http://mail.archive.org/cgi-bin/mailman/listinfo/ol-discuss >>> To unsubscribe from this mailing list, send email to >> [email protected] >> <mailto:[email protected]> >>> >> >> -- >> Karen Coyle >> [email protected] <mailto:[email protected]> http://kcoyle.net >> ph: 1-510-540-7596 <tel:1-510-540-7596> >> m: 1-510-435-8234 <tel:1-510-435-8234> >> skype: kcoylenet >> _______________________________________________ >> Ol-discuss mailing list >> [email protected] <mailto:[email protected]> >> http://mail.archive.org/cgi-bin/mailman/listinfo/ol-discuss >> To unsubscribe from this mailing list, send email to >> [email protected] >> <mailto:[email protected]> >> >> >> >> >> -- >> -Tom Johnson > > -- > Karen Coyle > [email protected] http://kcoyle.net > ph: 1-510-540-7596 > m: 1-510-435-8234 > skype: kcoylenet > _______________________________________________ > Ol-tech mailing list > [email protected] > http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech > To unsubscribe from this mailing list, send email to > [email protected] _______________________________________________ Ol-tech mailing list [email protected] http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech To unsubscribe from this mailing list, send email to [email protected]
