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 <kco...@kcoyle.net
> <mailto:kco...@kcoyle.net>> 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
>      >> Ol-discuss@archive.org <mailto:Ol-discuss@archive.org>
>      >> http://mail.archive.org/cgi-bin/mailman/listinfo/ol-discuss
>      >> To unsubscribe from this mailing list, send email to
>      >> ol-discuss-unsubscr...@archive.org
>     <mailto:ol-discuss-unsubscr...@archive.org>
>      >>
>      >
>      >
>      > _______________________________________________
>      > Ol-discuss mailing list
>      > Ol-discuss@archive.org <mailto:Ol-discuss@archive.org>
>      > http://mail.archive.org/cgi-bin/mailman/listinfo/ol-discuss
>      > To unsubscribe from this mailing list, send email to
>     ol-discuss-unsubscr...@archive.org
>     <mailto:ol-discuss-unsubscr...@archive.org>
>      >
>
>     --
>     Karen Coyle
>     kco...@kcoyle.net <mailto:kco...@kcoyle.net> 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
>     Ol-discuss@archive.org <mailto:Ol-discuss@archive.org>
>     http://mail.archive.org/cgi-bin/mailman/listinfo/ol-discuss
>     To unsubscribe from this mailing list, send email to
>     ol-discuss-unsubscr...@archive.org
>     <mailto:ol-discuss-unsubscr...@archive.org>
>
>
>
>
> --
> -Tom Johnson

-- 
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
_______________________________________________
Ol-discuss mailing list
Ol-discuss@archive.org
http://mail.archive.org/cgi-bin/mailman/listinfo/ol-discuss
To unsubscribe from this mailing list, send email to 
ol-discuss-unsubscr...@archive.org

Reply via email to