ISFDB:Community Portal/Archive/Archive14

This is an archive page for the Community Portal. Please do not edit the contents. To start a new discussion, please click here.
This archive includes discussions from

Archive Quick Links
Archives of old discussions from the Community Portal.

---

1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10 · 11 · 12 · 13 · 14 · 15 · 16 · 17 · 18 · 19 · 20 · 21 · 22 · 23 · 24 · 25 · 26 · 27 · 28 · 29 · 30 · 31 · 32 · 33 · 34 · 35 · 36 · 37 · 38 · 39 · 40 · 41 · 42 · 43 · 44 · 45 · 46 · 47 · 48 · 49 · 50 · 51 · 52 · 53 · 54 · 55

---

Expanded archive listing

Podcasts on the magazine page

I have added a section for podcasts on the magazine page. Any other podcasts out there that we are treating as magazines. This also gave me a way to get the Clarkesworld podcasts into the system.--swfritter 18:59, 6 April 2009 (UTC)

Images larger than 600 pixels seem to be working now

I noticed this a few weeks ago, and uploaded one tonight Image:SSSNKJCHNN1990-067169863X.jpg. Images with one dimension larger then 600 pixels seem to be working now. I don't know if our software or a preference setting got changed.. but I thought I would point it out. I don't recall any announcement. Kevin 04:55, 7 April 2009 (UTC)

There's been no change. They've always been accepted and available for linking, but you get an error message that a thumbnail couldn't be created. In order to see the image from its wiki page you still have to click on the "Full Resolution" link. That doesn't affect your ability to link to it from the database. MHHutchins 05:47, 7 April 2009 (UTC)

AHhh In checking my preferences I must have updated mine under files and "Limit images on file description pages to:" to the 1280x1024 option sometime since last I looked (and now images smaller than that display at native resolution without the need for a thumbnail to be created) Thanks Kevin 06:16, 11 April 2009 (UTC)

Server slow-down or just me?

Has anyone else noticed how frustratingly slow the server has been for the past week? Or could it be my ISP? MHHutchins 19:42, 10 April 2009 (UTC)

It's been really slow for me most of today, and at times for quite a while. BLongley 20:18, 10 April 2009 (UTC)

It's been slow all week. It's worse at night (US Eastern), but it has been slow somewhat frequently in the early morning, too. --MartyD 00:39, 11 April 2009 (UTC)

Yes it has been slow all week. I was blaming my ISP but all other sites weren't affected. --Chris J 01:49, 11 April 2009 (UTC)

Apparently the hosting company noticed the problems too and bounced the system around 9pm-10pm EDT. Hopefully, it will feel better now! Ahasuerus 02:35, 11 April 2009 (UTC)

Did it burp in the process so that it's little tummy feels better? MHHutchins 03:26, 11 April 2009 (UTC)

Editor self-sufficiency checklist?

As more of our "new" editors are getting closer to self-sufficiency, I think back to the (relatively few) cases when we moderatorized someone and then found out that he wasn't familiar with some obscure quirk, er, I mean "feature" of the system. Most of the time it wasn't a big deal and a leisurely discussion on the Talk page sorted everything out. However, I recall a few cases when Bad Things (tm) could have happened if more experienced moderators hadn't intervened quickly.

I wonder if we could have a list of "known gotchas" that all moderators (and ideally editors) should be aware of, from the obvious "do not edit Titles in the Contents section unless you want to change ALL occurrences of the Title" to "do not create Pseudonym associations lightly since they can't be easily deleted" to "if you don't understand how UK prices worked 40 years ago, here is where to check". That way each prospective moderator could review the list and either confirm that he is aware of the issues or ask questions. Ahasuerus 03:39, 21 April 2009 (UTC)

Another one: Non-merged titles not deleted after removing them from a pub. These can be hard for a moderator to catch since there is a two step process and it is easy to forget your own.--swfritter 13:53, 21 April 2009 (UTC)

Wonderful idea. If you'll create the page, I'll add to the list as the ideas come to me. In the meantime, I'll be making notes. Thanks. MHHutchins 17:44, 21 April 2009 (UTC)

Unmerging of content titles losing page numbers is one recent gotcha I've seen. I never do that myself (I always add title/remove title/merge as necessary) so keep forgetting about it. BLongley 18:12, 21 April 2009 (UTC)

Recently discovered unmerge issue: The title of an entry in a pub can be wiped out and replaced by the pub name. I think this only happens if it is the first entry.--swfritter 21:36, 21 April 2009 (UTC)

Another result from unmerging pubs from content titles instead of vice versa (as Bill pointed out above.) I wish this function was removed as it can cause several unwanted results. A moderator looking at such a submission has no idea of what the acceptance might bring about, and not going back to make corrections. A non-mod editor would be even more unaware. MHHutchins 22:07, 21 April 2009 (UTC)

To expand on a couple of things already mentioned: choice of Canonical author when creating pseudonyms should also involve a check on whether there is a Canonical entry already - I spent too much time recently working on some chains where A was a variant of B who was a variant of C. It can be undone (maybe that should be one of the Mod skills?) but is hard work and not entirely satisfactory in the results. And secondly, UK prices of 40 years ago are simple compared with other Commonwealth countries, see Bluesman's recent discovery. I doubt that needs to be mastered before we use the blackjack though: when I figure out East Africa I'll be demanding Bureaucrat status at least. ;-) But knowing things like not needing a "£" prefix if the price is "x/y" format (i.e. shillings and pence, no pounds involved) might be desirable. Some fixes I've had to do recently on British magazines effectively brought them back down to the real price from entries that actually made them 20 times higher. :-/ BLongley 19:30, 21 April 2009 (UTC)

(fiddled the indents as this applies to the above comment) Prices in books published close to the time of decimalization (2/15/71), can have prices in both pre (5/-) and post (25p) schemes e.g. BSTSRLDSB51970.--Rtrace 22:12, 21 April 2009 (UTC)

And Australia and NZ decimalised earlier, and changed the number of shillings in the primary unit. E.g. One British pound stayed one British pound, but the Antipodean pounds became two dollars. The dual-pricing on those books has similar issues. The Irish Punt is another matter - there's 20 years where it stayed in step with the UK (although book prices don't illustrate that, introducing the problem of the halfpenny.) But I think we're getting beyond what we need mods to know. BLongley 18:48, 22 April 2009 (UTC)

Another thought: Double quotes are OK in Publication and Title titles, but not in Author records (use single quotes instead). Single quotes cause problems in Series titles under some obscure and hard-to-recreate circumstances. Ahasuerus 21:11, 21 April 2009 (UTC)

And another thing - various pieces of top-of-the-form pub data do not get updated automatically - editor title, coverart title, etc. Not data destructive so not critical.--swfritter 22:46, 21 April 2009 (UTC)

And let's not forget our perennial favorite: When editing a Publication record with no pre-existing Contents data, the first Title defaults to ANTHOLOGY. Ahasuerus 23:00, 21 April 2009 (UTC)

[unindent]When the title reference record is present in the contents section of some pub types (not all), don't overwrite it unless you're aware of the ramifications of your action. (Some editors will start adding content and overwrite this record.) MHHutchins 23:17, 21 April 2009 (UTC)

And how about having a basic understanding of the difference between a title record and a publication record? If I had a nickel... MHHutchins 23:17, 21 April 2009 (UTC)

And which title types are "containers" and which are "contents". (And the one that is sort-of in-between at the moment, CHAPTERBOOK .) And the great bafflement that is the "Editor" record. BLongley 18:34, 22 April 2009 (UTC)

Changing the Author's name (in Author Data) to a value that is shared with another Author record is a very bad idea since the software assumes that Author names are unique, so all data linked to the second record will become inaccessible. The way to fix it is to change the first record's name in Author Data to something else (e.g. by adding "1" or "- test") and then manipulating individual Title and Publication records. Author Merges should be approached very very carefully since they can destroy intricate webs of variant titles. Ahasuerus 18:24, 25 April 2009 (UTC)

If there is a "special character" in a field, Moderator screens will show the field as changed even when no changes to that field were made. Ahasuerus 16:19, 1 May 2009 (UTC)

PublishAmerica RULES!

Who says PublishAmerica doesn't produce winners! Just look look at the price of this "Jem"[1] in the after market. After reading the product description I ordered it right away! A future classic, order soon before the rare book dealers corner the market and drive the prices even higher!!!Kraang 02:17, 22 April 2009 (UTC)

I'm not buying until someone writes a review! I wonder if an ebook version is on the way.--swfritter 02:27, 22 April 2009 (UTC)

I wonder if "Tom Thorstenson" is also the dealer, or if not, whether this is an unpublished Philip K. Dick manuscript. My god, what idiot would pay $200+ for a paperback published by a vanity publisher? MHHutchins 04:47, 22 April 2009 (UTC)

His mother? Kevin 12:50, 22 April 2009 (UTC)

Helix Resurrected & missing issues added.

It's back. I also added data for the three issues that hadn't been entered. See this issue for the notes I put in the pubs that were resurrected]. This issue has the notes for the issues that were entered from a secondary source. Please note that the secondary source is also a webzine. An appropriate candidate for the transient verification flag. I will add more disclaimers to the magazine linker page tomorrow.--swfritter 20:47, 23 April 2009 (UTC)

Much appreciation for your efforts. Alas, I can think of a half-dozen more webzines that are just as worthy, or probably more so, than Helix: The Infinite Matrix, The Internet Review of Science Fiction, and Infinity Plus come to mind. (And those are just the ones beginning with "I"!) Thanks. MHHutchins 20:53, 23 April 2009 (UTC)

Too late for Galaxy Online!--swfritter 21:38, 23 April 2009 (UTC)

I think it wise that if you find that some of the material of e-publications have value that the data be entered as the author of one story wished. After all this db records the existence of material at one time, with no assurance that it will last forever. It does give the researcher the basic data to look for and there almost always is someone around who has stored the e-version. The DB therefore protects the actual existence record and others will find the material so recorded. Hopefully, such action will preclude a statement like Anne McCaffrey made that she could not remember what story inspired her 'Brain ship' Series. Thanks, Harry. --Dragoondelight 23:15, 23 April 2009 (UTC)

Nominating Kpulliam for moderatorship

Ref: Moderator Qualifications#Becoming a moderator for the nomination process.

Nomination statement

I nominate Kpulliam (talk • contribs) for moderatorship; he has accepted the nomination. Kevin has over 2,800 submissions and has a good working knowledge of all aspects of the database as demonstrated by his recent work on cleaning up reviews, e.g. see this Mummy! discussion, and has actively participated in Wiki discussions. I believe that he is qualified.

1. Support, as nominator. Ahasuerus 23:22, 25 April 2009 (UTC)
2. Support, as somebody that watched his edits today even more closely than usual. I'm sure we'll have differences over "variants for punctuation alone" or something, but he seems far more constructive than destructive, while still being quite inquisitive. BLongley 22:25, 26 April 2009 (UTC)
3. Support,of lately I've only moderated the easy submissions, but I still follow the different talk pages. Kevins submissions have covered most of the more complex areas of the database and I feel he is ready to be cut loose and go at it.Kraang 00:08, 27 April 2009 (UTC)
4. Neutral, reluctantly. Kevin has done some terrific work but seems a little too impulsive at times.--swfritter 16:49, 27 April 2009 (UTC)
5. Support, with the same reservations as Swfritter, but with the solid belief that the new role will moderate those impulses (no pun intended!) MHHutchins 17:28, 27 April 2009 (UTC)
   • Comment: I have to admit that I thought about this issue before nominating Kevin and almost added a line similar to Michael's to the nominating statement. I suspect that part of the problem is that we have a number of issues (and associated workarounds) that have been debated to death and are all too familiar to "first generation" moderators. Thus, when a relatively new contributor looks at one of these thorny areas and says "Oh, sure, I can fix this, no problem, give me a few minutes", we tend to be a little apprehensive. Ahasuerus 18:08, 27 April 2009 (UTC)
6. Support. Kevin has worked hard and has shown marked interest in the intricacies of the DB. His interest in the Other Sites usage stunned me. Though it presently does not appeal to me, it probably is an important adjunct of the DB that needs refinement. (hint) (wink) --Dragoondelight 11:58, 29 April 2009 (UTC)
7. Support. I haven't moderated that many of Kevin's submissions, but the ones I've looked at have been good. The discussions he's been involved show he has a sharp mind, learns quickly, and communicates well.--Rkihara 15:49, 29 April 2009 (UTC)

Outcome

Nomination is successful; moderator flag set on the account. Congratulations! :)

You may want to review Help:Screen:Moderator, which describes the Moderator page, and please don't hesitate to ask if in doubt! Ahasuerus 05:18, 1 May 2009 (UTC)

• Thank you all for your support and comments. I will still welcome comments about my edits and as such feedback will continue to be appreciated! - Now to see what all of the fuss is about.....Moderator Menu... Here I come! Kevin 05:39, 1 May 2009 (UTC)

Future Moderators

Aside. This council of elders needs to develop Bluesman, William H. and MartyD. If it continues to dither you may lose their interest. I do not know the status of RTrace or HolmesD, I am assuming they are not moderators, but both also need to be fast tracked. Thanks, Harry. --Dragoondelight 11:58, 29 April 2009 (UTC)

"Dither"??? As one of the 'potentials', I don't feel that anyone has been 'dithering' in the slightest. There will always be generalists and specialists, both of which this site needs and supports. Hell, Harry, you get support and I'm not sure just what you are! LOL!! Thanks for going to bat, but I think the 'elders' (have to laugh at that as I'm older than all of them) are doing just fine!! ~Bill, --Bluesman 05:20, 5 May 2009 (UTC)

My understanding of the rules is that as an editor you can nominate yourself or others. It is not necessary to be a moderator. Not all editors want to be moderators, so be sure to check the protocols under Moderator Qualifications#Becoming a moderator first.--Rkihara 20:28, 29 April 2009 (UTC)

There is no "Council of Elders". There are editors that communicate and those that don't. Some edit well without communicating well. Those might be supported into self-editing that requires moderator abilities, it makes them more productive and lessens the workload for the rest. I'd suggest Don Erikson as somebody heading that way - very active, few faults apart from some typos. You've mentioned Bluesman, Willem H, MartyD and Rtrace - all people that communicate and I hope we are supporting them. And you, although I notice you didn't add yourself to the list. HolmesD is a bit too quiet for my liking: no problems with his editing, but I can't see him being an active moderator. It's activity and communication that make a mod, as well as their edits: we've actually demoted several mods recently, even a bureaucrat. And several mods are specialists: it's not uncommon to see someone that knows all the magazine guidelines inside out that dithers over "tp or pb" for a book, and book specialists that couldn't be sure of the dimensions for a magazine. We're not looking for perfection in mods, and we're not trying to keep non-mod editors down. I'm glad to see editors looking at fellow editors as potential mods though. BLongley 22:07, 29 April 2009 (UTC)

Rest assured that we would love to see more editors become moderators. Not only does it make their lives easier, it also makes the moderators' lives easier and frees them/us up to do more work on data entry, data cleanup and, in some cases, scripting, robots, the backups and even walks in the park! :) If an active editor communicates well, he will eventually become familiar with all (or the vast majority of) policies and "gotchas" and his submissions will no longer require moderatorial review.

Having said, it can be hard to tell whether an editor is ready for self-sufficiency or not. He may be proficient at modifying publications and merging titles, but has he done some of the more obscure things, e.g. has he created nested series, unlinked variant titles or fixed "invisible" EDITOR records? It's almost like we need a test, which is pretty much what happened with Kevin (see the link to his Talk page above). Ahasuerus 22:28, 29 April 2009 (UTC)

Less like a test... more like a Journeyman's project. Another thing that has 'boosted' me in the last two weeks as far as truly digging in the DB is working on ISFDB:Authors_that_only_exist_due_to_reviews. My recommendation... Pick a letter (no not that really short one).. put an 'in progress' sign at the top of it, and do them all. Then go back through the list, and do them all again by finishing the publications they link to (If there is one unlinked / un-entered pub in a magazine, there are probably others... so do all the ones you skipped the first time). Each time through there will be some you just aren't sure what to do with, or how to proceed. That's ok... leave a note to yourself, and come back around again. I've been going back and forth in the J's now for quite some time and I'm no-where near done. Kevin 23:12, 29 April 2009 (UTC)

On this one mini-project, I've entered new pubs, edited old ones, changed review titles, changed review authors, fixed authors, fixed titles, renamed authors, discovered new authors, entered collections of fiction, non-fiction, I entered pubs that were out, then then deleted them from the system, read, and then re-read the 'Rules of acquisition', Discovered overlapping authors, disambiguated authors, researched like heck in the LOC, Worldcat, Amazon.com (US, British, French, and German), Google Books, Internet Archive, Wikipedia, etc. Entered non-english language originals, just so I could enter the English language variant, chased tangents, bugged verifiers (politely) entered 'real changes' (not just notes and covers) after asking first, bugged verifiers some more (still politely), started entering real changes with notes: If this is wrong we can change it back on wiki pages, learned more wiki code (to add highlighting for my notes... they were running together on the screen), seriously the list goes on and on. Pick a project.. something that will make you ask yourself again and again in the same (day, week, whatever) 'How do I do this' 'How do I want to do this' 'how has this been done before' and 'has this been done in different ways before' and you will be well on your way. Kevin 22:56, 29 April 2009 (UTC)

I would like to know what constitutes a 'real change'?? Every change is 'real' and I don't see anything that delineates between 'real' and the (implied) 'important' ones.... --Bluesman 05:29, 5 May 2009 (UTC)

Oh I definitely was not trying to imply that one type of change was more important than the other. To be clear, there are two types of changes, 'Additive', and 'Destructive'. Additive changes put more info into the DB (e.g. page count when empty, cover links when empty or broken, added notes, etc). Destructive changes require the removal of previously entered information (e.g. change in authors name, change in title, change in year, etc). What I was referring to above as 'real' were 'destructive' changes, where I was erasing some information already present, as opposed to simply adding more information. It's always easier (for me) to press the submit key with confidence to change someone elses verified work when the changes are additive and I have the book in front of me, than when they are destructive and I am working from secondary sources alone... so mentally I felt more 'trepidation' at submitting those changes. Thanks for keeping me honest! All changes are real (and welcome!, and worth doing!), but changes that erase information cause me more concern/worry than those that don't. Kevin 11:13, 6 May 2009 (UTC)

Perhaps "Additive" and "Deletive"? Destructive seems to indicate that any erasure is/could be bad. The DB is an evolving thing, and there is a great deal of 'data' from years past that needs to be altered/deleted for clarity, which I think the current 'bent' seems to prefer. So do I. And with the current band of editors being so easy to reach, issues on data get resolved very quickly. I see that the trend has been getting more aggressive in changing data on verified pubs from 'vanished' editors as well. A lot of this is we have access to more data. I remember well being totally afraid to add, never mind change anything (that was when I found out someone was actually watching LOL!!!). Those same watchers now give me the confidence to submit just about any change and learn from the 'fallout'. For the rest we have these pages. And with cyberspace, does anything truly disappear????? ;-) ~Bill, --Bluesman 00:38, 7 May 2009 (UTC)

The situation about changing verified pubs has occurred because the definition of "verified" has evolved over the years. It's like a butterfly you can never really pin down. Moments after you think it's captured, something else comes along to scare it away. I'm doing third and fourth passes at some of my books, but only when they're brought to my attention. I have too many projects going on to do a thorough pass of every book in my collection. MHHutchins 03:58, 7 May 2009 (UTC)

(Not Indented)I think Kevin's statement on what "Additive" and "Destructive" changes are makes very good, clear sense and should be incorporated into some stage of the "How To Instructions". If people, and most workers here do, give a quick thought to what can happen things should work better. No one else said it quite that way to me, except I especially like VBT, Very Bad Thing. Would two other categories be "Clarification" and "Declarative"? Thanks, Harry. --Dragoondelight 22:53, 6 May 2009 (UTC)

That's a very good point. I learned a great deal about the way the latest version of the software (the current version is "ISFDB-2", BTW) worked in May 2006 by testing it to destruction. In a way, it was harder to do than what Kevin describes above, since I had to figure out what software behavior was intentional and what "features" were actually bugs, but it was very educational. Ahasuerus 02:48, 30 April 2009 (UTC)

I'm glad you liked that Project, Kevin, it's one I started! It does lead to all sorts of interesting areas - have you encountered the reviewers that are reviewing under a pseudonym yet? I'm still not sure how to best deal with those. But it's obviously not a universally appealing one, and I'm happy to suggest or construct others, and "mentor" people if needed if it's an area I could work on myself anyway. "Publication Series" has a few open areas that could be worked on but will probably not take people across so many areas, but does teach people ISBN prefix ranges for publishers, Imprint versus Publisher information, printing numbers and ISBNs across changes of cover art, prices, format etc. There's a lot of projects that could be created: I'm slogging through some British magazines that need some improvement but could suggest other things that need doing - publisher information, finding the covers, distinguishing editors, etc. All could lead into exciting new research for somebody. Or a hard boring slog if it's not something you're interested in. But if people have an interest, we can find a project, I'm sure. BLongley 20:13, 30 April 2009 (UTC)

Well I read the 'rules' and as a document it reminds me of all constitutions that I have read. The real critical issue is that you (the group) need to develop a program that gives people a sense of where they stand. People want and need peer approval to go for the gold. What is readily found is the criteria of being a 'total' moderator, not a journeyman moderator. Editors see the DB by the attitude and commentary of moderators, much of which is expressed in the loftiness of truly well rounded individual effort. Unfortunately, people are not built that way. Without a program or schedule to show them the elements needed for success, they rely on the moderators to give them that boost. The problem is that they need more counselor guidance to attain a moderator role. It is clear from recent 'moderator' statements that the moderators do not desire more 'self approvers'. The moderators have made that clear, but have not clarified what exactly is needed. As a guideline, after a thousand or so points or whatever, a moderator needs to start a conversation with them to determine their goals and possible needs. Thanks, Harry. --Dragoondelight 23:40, 29 April 2009 (UTC)

We have tried "mentoring" in the past when a moderator (or two) and an editor were interested in the same area. They would split the workload and the moderator would explain the system's quirks to the editor until the later reached self-sufficiency. Swfritter, Rkihara and Davecat had particularly successful arrangements, I believe, and may be able to comment further. Ahasuerus 02:48, 30 April 2009 (UTC)

Mike Hutchins and I both worked with Davecat. I thought the process worked fairly well and think, at least at first, new editors should work primarily with one or two moderators. Rkihara came on board a few months after me and we both learned from each other by doing double verifications on pubs we owned in common. We both had some really good and really bad ideas and the communication normally resulted in the good ideas being more commonly used.--swfritter 21:03, 30 April 2009 (UTC)

I've tried the same set-up with other new editors, and have found that some are more receptive than others. It doesn't take long to figure out just how much help an editor needs . . . and how much he'll accept. MHHutchins 04:00, 7 May 2009 (UTC)

Personal aside. I am pushing this issue because I have realized that my ambition burned out. I would never feel at ease as a moderator and possibly that is why some 'drop' out. There may be just a 'tad' too much expected of prospective and active moderators. Having trained a great many people, I will state you need to actively and personally encourage workers to wish to 'fly'. You have to stand by and watch them smash themselves into the woodwork or dance in the wind. Give them the keys and let them develop skills. Thanks, Harry. --Dragoondelight 23:40, 29 April 2009 (UTC)

It is certainly true that self-sufficiency doesn't imply perfection. If it did, we would have no moderators left :) Ahasuerus 02:48, 30 April 2009 (UTC)

Second Aside. Sorry guys, but council of elders is the mildest thought I have had since first coming here. I actually think of the control group and participants as the 'club of anarchists'. I frequently wonder at how much sub-rosa is done by people. I think you real solution is the DB needs a larger group of interactive thought, not necessarily a completely trained cadre. If you get people to habitually interact with more numbers I think you will find less 'explorative' work done. Thanks, Harry. --Dragoondelight 23:40, 29 April 2009 (UTC)

I don't think there is much "sub-rosa" stuff, i.e. editors consciously trying to get around our established rules, happening. There are certainly different "styles", individual preferences and even different interpretations of the (sometimes confusing) Help pages and policies, but that's to be expected and we try to sort these cases out as they percolate to the surface. Occasionally, new editors have problems with the rules and either leave (I believe that Hayford Peirce left in part for this reason) or adapt and even thrive (David Siegel did in spite of having strong opinions on a number of topics.)

The "sub_rosa" event that came near to triggering my near departure from the isfdb concerned submissions from Shsilver who on his Talk page stated "Re-submitted the Helix information on the advice of another editor." Since this advice does not appear on his Talk page I can only assume it was given in a private email. It appeared to be an attempt to sneak the data in. I was so distracted by that issue that I wasn't really concentrating on the issues associated with his other submissions.--swfritter 18:29, 30 April 2009 (UTC)

It's hard to be sure what Steven Silver meant given his lapidary comments. Even if he was advised by another editor (who may not have been a moderator or a frequent contributor) via e-mail, given Steven's lack of prior experience with ISFDB, it may have been misinterpreted, so it may be premature to draw conclusions. (The first rule of The Cabal: There Is NO Cabal!) Ahasuerus 18:44, 30 April 2009 (UTC)

Remember that the notes on Rejected Edits might be considered communication too. But I've looked at mine from the 11th April and can't see how Steve Silver could have misinterpreted those, they were about Argentus rather than Helix. He might have misread "If there's enough evidence of first publication of fiction in Helix, then we can treat it like a Non-Genre magazine and do the relevant fiction only" suggestion that I posted in the ISFDB:Moderator_noticeboard#Shsilver_submissions talk maybe? That's all on public record though. I don't discuss edits via email and would discourage anyone from doing so. But this Wiki communication does make it bloody hard to find discussions at times - I think Bluesman and Mike Hutchins discussed the middle name/initial problem directly here, but I don't recall anything about Helix and am useless at Wiki-Searches. BLongley 19:57, 30 April 2009 (UTC)

Oh, and there is obviously no Cabal - it was retitled "Nightbreed". ;-) BLongley 19:57, 30 April 2009 (UTC)

The dates and times seem to support that explanation. Silver may have jumped the gun on an issue I obviously had volunteered to resolve. As far as Cabal's around here - it might sometimes appear that way because many of us have a good idea as to the thought processes of others. In addition, there are many discussions that get started on individual talk pages but don't get on to the main pages immediately.--swfritter 20:45, 30 April 2009 (UTC)

Overall, I think it's fair to say that different people develop editing and communications skills differently and their pace of progress can differ dramatically. Some of us, e.g. David Siegel and I, had a fairly extensive Wikipedia background when we (re-)joined the project, so using this Wiki was easy for us. Other editors had some kind of computer/IT background, which made it easier to master the fine art of data manipulation. Yet another group had no IT background but learned the ropes by creating tens of thousands of submissions (you know who you are!). Conversely, some editors had certain problems which made it harder for them to become self-sufficient, e.g. at one point Don had serious health issues, which made it harder for him to edit. Dave Sorgen, a retired programmer, learned the software quickly, but he spends much of his time traveling in remote areas, which makes it hard for him to stay current. We also had an active and well-meaning German editor at one point, but his English skills were limited.

And then there is the "churning" factor. Some editors are primarily interested in a specific area of the database and when they are done with it, their interest wanes. Other editors go on an editing spree when they find the ISFDB, but burn out quickly. Yet another group has to stop editing for family and other personal reasons. And then there are some who burn out after so many thousands of submissions. Which reminds me. Now that the backups have been mostly automated, I may take a day or two off to recharge my batteries... Ahasuerus 02:48, 30 April 2009 (UTC)

'Recharge Batteries'? Do I smell a whiff of Solder? - Hey Bill, I think Fixer or Dissembler has taken over Ahasuerus's login. What should we do? Kevin 03:52, 30 April 2009 (UTC)

I'll bet you $1,024 you can't prove anything! Ahasuerus 16:02, 30 April 2009 (UTC)

Move Electric Velocipede to Fanzines?

Seeing as how it has a Hugo Nomination in that category. There is already an empty link in fanzines.--swfritter 19:16, 28 April 2009 (UTC)

I think I entered a lot of the contents, but only from secondary sources. It seemed a significant title, but I have no preference for Fanzine or Magazine. Put it where you will. BLongley 20:32, 28 April 2009 (UTC)

I will probably place a common link in both places. Looks like a semi-prozine to me too but if the publisher says it's a fanzine . . . --swfritter 23:36, 28 April 2009 (UTC)

Service problems

It took 8 minutes for this page to come up, plus another 4 minutes to load the comment box. Is there anyone who can contact the website host to let them know there's a problem? This is too frustrating and too much a waste of time. This has happened so many times today that I've stayed away, only to come back and have the same problems. Funny thing though, right in the middle of all this, everything pops up just fine. But it's not long before it starts happening again. The problem must be on the host's end, because I have no problems connecting to other websites. MHHutchins 22:22, 28 April 2009 (UTC)

I have been noticing this problem for the past couple of weeks. Kevin 22:27, 28 April 2009 (UTC)

I have seen unhealthy delays over the last few weeks as well, but never as bad as 8 minutes. I'll ask Al to send our service provider an e-mail, but a cursory review doesn't find anything unusual, at least not at the moment. On average, our processor is 89% free and spends only 3% of the time waiting for the database, although I see significant spikes now and then. Unfortunately, both average and "spike" numbers can be misleading since we are running on a virtual machine, which may have problems of its own. I have neither the tools nor the expertise to analyze the issues, but one thing that I have noticed is that the system is often running the "Diff pubs" script and the login script. Since these scripts should be rarely executed during day to day operations, it may suggest that are we getting hammered by robots hitting every single link on the Web site. I'll mention this to Al too. Ahasuerus 02:28, 29 April 2009 (UTC)

Last night, shortly after 1:00 am (server time), it took more than twenty minutes between entering a submission and final approval. MHHutchins 19:13, 29 April 2009 (UTC)

I too, have noticed. Really slows you down. LOL. I have started playing pinochle between screens. Thanks, Harry. --Dragoondelight 19:21, 29 April 2009 (UTC)

I think I may have caught it red-handed. Wiki load times were up to 1 minute as of 3:20pm EDT, so I ran some basic diagnostics and it turns out that the system was spending almost all of its time waiting for the disk. Load times appeared to be fine on the database side, so either our virtual machine is misbehaving or the fact that our Wiki tables have grown a lot over the last year is causing us problems. Let me see if Al can get rid of the old versions of the most active Wiki pages (including this one), which helped the last time around. Ahasuerus 19:37, 29 April 2009 (UTC)

Let's hope that solves the problem. I'm getting too good at four-suite Spider Solitaire! MHHutchins 22:06, 29 April 2009 (UTC)

I had about 30-45 minutes of total unavailability just now, from about 1:12 AM until about 1:45 AM CDT (You can see the gap between my two approvals for Ceres Solution). I got actual Server Error 500 messages a couple of times, so it's not network related, its definitely on our box. Kevin 07:01, 3 May 2009 (UTC)

It was still pretty bad at 6:15 AM EDT or so. It got better around 6:45 in that it would eventually respond with only moderate delay. This just for page views, not storing. --MartyD 11:09, 3 May 2009 (UTC)

Well after it got good for 10 minutes last night it went out on me again. It was so far gone, that I didn't know if my post (about the problems) went through until I got up just now. Kevin 13:21, 3 May 2009 (UTC)

A few points:

1. No changes to the database have been made yet. We need to check whether the script to purge the old versions of Wiki pages -- which Al ran last year -- will still work with this version of the Wiki software.
2. When the backups run, the system typically slows down to a crawl. The main backup process runs at 4am EDT. Images are backed up between 5:10am-6:20am EDT, but let me change the time slice to 3:30am-4:40am EDT.
3. We run on a "virtual machine", so we don't have a full server to ourselves, which means that we may be indirectly affected by all kinds of other things happening on that physical server. If we were to upgrade to a dedicated server, it would be another $850/year.
4. Today was a particularly bad day. My monitoring service typically sends me 1-2 notifications of system unavailability every night, but today I received 3.

I think the prudent thing to do is to purge the old versions first and see if it helps. If it requires a new script, we may need Marty's help. Ahasuerus 15:49, 3 May 2009 (UTC)

Lady Churchill's Rosebud Wristlet wiki?

Looks like we've got all but the latest issue in the database but no wiki page for it. It has garnered some nomination votes in the semi-prozine category so seems appropriate to place a link in the magazine section although there is an empty link in the fanzine wiki.--swfritter 23:53, 28 April 2009 (UTC)

And that's my other admitted 'zine project. Again, I have no preference for fanzine or magazine. I just dumped the data from their website here. BLongley 17:54, 29 April 2009 (UTC)

I will probably put links in both places. I actually would be more likely to look in magazines for pubs that carry mostly fiction. Thanks!--swfritter 18:28, 29 April 2009 (UTC)

No problem, glad it helped. Maybe I should admit my unofficial Interzone project? Still fixing editor records, learning a lot about Brin1 along the way, adding months to years, fixing prices, etc. NOT adding publisher, correcting regular column names, adding [n] to Interiorart entries, adding Coverart URLs etc. Someone else can do that. Another of my "iterative improvement" projects that I tend to keep quiet lest someone "remind me" that I could do so much more. BLongley 22:22, 29 April 2009 (UTC)

I was glad to find the wristlets - saved me a lot of work; I finally have enough sense to look for non-wiki'd magazines before I start adding them. I have been slamming data from semi-prozines in much the same way. Better that they be in the system un-spiffed then not in the system at all.--swfritter 00:05, 30 April 2009 (UTC)

Software development resumed

As most of you know, Al has been mostly unavailable since the middle of last year. The rest of us have been unable to get a development system up and running, so all software changes and bug fixes had to be put on the back burner. Well, I am happy to report that MartyD was able to set up a development system (thank you, Marty!) and is ready to start making changes.

The current plan is as follows:

1. Do a minimal "proof of concept" change which will test the process -- see the Proposed changes to Series display section immediately below
2. Decide on the overall approach, i.e. "low hanging fruit" vs. "big ticket items"
3. Clean up our bug list and prioritize outstanding issues

As far as the overall approach goes, I don't think Marty will be in a position to undertake major tasks like creating an Award editor screen or replacing the "lexical match" logic for Serials just yet. We'll need to start small and fix the simple stuff first so that Marty could slowly expand his knowledge of the application.

I'd take a stab at prioritizing the bug list, but I seem to be coming down with something. I am sure we all have our pet peeves and priorities, so we will need to do a cost-benefit analysis soonish. Ahasuerus 22:31, 30 April 2009 (UTC)

I would look first at the Editor self-sufficiency checklist? section and fix anything that will remove a gotcha with minimum effort. A display only solution could be implemented for showing how many titles are merged - should be implemented in both the edit screen so the editor can see it and pub submission display where the moderator can see it. This might be a good place to start because it requires no database updates. Perhaps a database related update would be the capacity to remove a pseudonym assignment at the author biblio level. These might be good feet-wetting projects.--swfritter 00:00, 1 May 2009 (UTC)

Some quick wins would be putting the relevant publication tag/id, and/or title IDs on the Approval screens for the awkward edits where the mod doesn't know what's being unmerged from where or what's being removed from what. Finding out after approval is a bit late and can lead to a lot of fixing. BLongley 19:09, 1 May 2009 (UTC)

Another thing that should be fairly simple - didn't most of us agree that we'd prefer 0000-00-00 titles to go at the bottom rather than the top? BLongley 19:09, 1 May 2009 (UTC)

Ditto on the 0000-00-00 titles.--swfritter 21:23, 1 May 2009 (UTC)

Double ditto on the 0000-00-00 titles.Kevin 22:38, 1 May 2009 (UTC)

Not to disagree with that, but would you then want the same thing for pubs within a title? It would be a little odd to have 0000-00-00 titles at the bottom and 0000-00-00 pubs at the top. Of course, I'd rather see pubs sorted by catalog number AND first date of that catalog number, then have printings of that catalog number indented a la variants or series, but that's probably just me.... --MartyD 01:02, 2 May 2009 (UTC)

You caught me copy and pasting. While the word titles was used... I read the request as having to do with undated publications within a title. Thanks for keeping me straight! Kevin 01:24, 2 May 2009 (UTC)

I agree that both 0000-00-00 titles and pubs are best displayed at the bottom, but keep in mind that in the past we also discussed various complications related to Variant Titles, omnibus editions and imprints that are used by more than publisher. At one point we had an extensive discussion of this topic and agreed that we needed to add a "Printing" field to the Publication table which would help order numerous 0000-00-00 pubs published by the same publisher. However, that goes beyond "display only" changes, so we probably don't want to go there (yet).

Re: Marty's proposal to sort publication records based on the first appearance of each ISBN/Catalog ID and then use indentation if there is more than one pub that shares the same ISBN/Catalog ID, it may well be workable. If you could make this change on your home system and then upload a picture of a sample Title page (e.g. some Le Guin title with a dozen+ pubs), it may give everyone a better idea of what the end result will look like. Ahasuerus 02:31, 2 May 2009 (UTC)

Proposed changes to Series display

As far as the "proof of concept" project goes, I asked Marty to review the way Series are currently displayed. There have been numerous requests to change the display order so that "Series with short fiction only" and "Non-genre series" would be displayed. Here is what he found as far as the display order of Summary Bibliographies goes:

• SERIES: Fiction Series ("NC" -- has title types of Novel, Collection, Omnibus)
• WORKS: Novel
• WORKS: Collection
• WORKS: Omnibus
• WORKS: Serial
• SERIES: Editor Series ("E" -- has title types of Editor)
• WORKS: Editor
• SERIES: Anthology Series ("A" -- has title types of Anthology)
• WORKS: Anthology
• SERIES: Non-Fiction Series ("NF" -- has title types of Nonfiction)
• WORKS: Chapterbook [as we all know, these are partially broken]
• WORKS: Non-Fiction
• WORKS: Non-Genre
• WORKS: Cover Art
• WORKS: Back Cover Art [not fully implemented]
• WORKS: Interior Art
• [SERIES: Short Fiction Series ("Short" -- has title types of Shortfiction) ** currently commented out]
• WORKS: Short Fiction
• WORKS: Poem
• SERIES: Essay Series ("Essay" -- has title types of Essay)
• WORKS: Essay
• WORKS: Review
• WORKS: Interview

The software works its way down the list and if it finds anything eligible for display in a particular section, it also displays other Titles in that series. That's why Short Fiction Titles are displayed along with book length Titles at the top of the pages, but only if there are any book length Titles in that series. This behavior is certainly not perfect and sometimes results in empty series headers. I am sure we could come up with all kinds of ways to improve it, but I suggest that we limit our changes to something very straightforward and basic for now.

One simple solution is to redefine "Fiction Series" to include Non-Genre and Short Fiction Titles so that Non-Genre and Short Fiction series would appear at the top. Another solution is to re-enable the "Short Fiction Series" section so that all series that contain nothing but Short Fiction would appear after Interior Art and before the rest of Short Fiction. (Do we want to move the art sections below Short Fiction?)

I am sure Marty will be able to answer any questions that may arise <he said heading for the bed>. Ahasuerus 22:31, 30 April 2009 (UTC)

Here is what Henry Kuttner's bibliography will look like if we decide to display all fiction Series, including "Short Fiction only" Series, at the top of the page:

   *  Baldy
         o The Piper's Son (1945) [SF] with C. L. Moore
               + Variant Title: The Piper's Son (1945) [as by Lewis Padgett ]
               + Variant Title: The Piper's Son (1945) [as by Henry Kuttner ]
         o Three Blind Mice (1945) [SF] with C. L. Moore
               + Variant Title: Three Blind Mice (1945) [as by Lewis Padgett ]
               + Variant Title: Three Blind Mice (1945) [as by Henry Kuttner ]
         o The Lion and the Unicorn (1945) [SF] with C. L. Moore
               + Variant Title: The Lion and the Unicorn (1945) [as by Lewis Padgett ]
               + Variant Title: The Lion and the Unicorn (1945) [as by Henry Kuttner ]
         o Beggars in Velvet (1945) [SF] with C. L. Moore
               + Variant Title: Beggars in Velvet (1945) [as by Lewis Padgett ]
               + Variant Title: Beggars in Velvet (1945) [as by Henry Kuttner ]
         o Mutant (1953) [C] [as by Lewis Padgett ]
         o Humpty Dumpty (1953) [SF] with C. L. Moore
               + Variant Title: Humpty Dumpty (1953) [as by Lewis Padgett ]
               + Variant Title: Humpty Dumpty (1953) [as by Henry Kuttner ]

   * Elak
         o Thunder in the Dawn (1938) [SF]
               + Magazine/Anthology Appearances:
               + Thunder in the Dawn (Part 1 of 2) (1938)
               + Thunder in the Dawn (Part 2 of 2) (1938)
         o Spawn of Dagon (1938) [SF]
               + Variant Title: The Spawn of Dagon (1938)
         o Beyond the Phoenix (1938) [SF]
         o Dragon Moon (1941) [SF]

   * Gallegher
         o Time Locker (1943) [SF]
               + Variant Title: Time Locker (1943) [as by Henry Kuttner and C. L. Moore ]
               + Variant Title: Time Locker (1943) [as by Lewis Padgett ]
         o The World Is Mine (1943) [SF]
               + Variant Title: The World Is Mine (1943) [as by Henry Kuttner and C. L. Moore ]
               + Variant Title: The World Is Mine (1943) [as by Lewis Padgett ]
         o The Proud Robot (1943) [SF]
               + Variant Title: The Proud Robot (1943) [as by Henry Kuttner and C. L. Moore ]
               + Variant Title: The Proud Robot (1943) [as by Lewis Padgett ]
         o Gallegher Plus (1943) [SF]
               + Variant Title: Gallegher Plus (1943) [as by Henry Kuttner and C. L. Moore ]
               + Variant Title: Gallegher Plus (1943) [as by Lewis Padgett ]
         o Ex Machina (1948) [SF]
               + Variant Title: Ex Machina (1948) [as by Henry Kuttner and C. L. Moore ]
               + Variant Title: Ex Machina (1948) [as by Lewis Padgett ]
         o Robots Have No Tails (1952) [C]
               + Variant Title: The Proud Robot (1983) [as by Henry Kuttner and C. L. Moore ]
               + Variant Title: Robots Have No Tails (1952) [as by Lewis Padgett ]

   * Gerry Carlyle
         o Trouble on Titan (1947) [SF]

   * Hogben
         o 1 The Old Army Game (1941) [SF]
         o 2 Exit the Professor (1947) [SF] with C. L. Moore
               + Variant Title: Exit the Professor (1947) [as by Henry Kuttner ]
               + Variant Title: Exit the Professor (1947) [as by Lewis Padgett ]
         o 3 Pile of Trouble (1948) [SF]
         o 4 See You Later (1949) [SF] with C. L. Moore
               + Variant Title: See You Later (1949) [as by Lewis Padgett ]
               + Variant Title: See You Later (1949) [as by Henry Kuttner ]
         o 5 Cold War (1949) [SF]

   * Jirel of Joiry
         o Quest of the Starstone (1937) [SF] with C. L. Moore

   * Keeps
         o The Jungle / Clash by Night (1991) [O] with David Drake and C. L. Moore [as by Henry Kuttner and David Drake ]
         o 1 Clash by Night (1943) [SF] with C. L. Moore
               + Variant Title: Clash by Night (1943) [as by Lawrence O'Donnell ]
               + Variant Title: Clash by Night (1943) [as by Henry Kuttner ]
         o 2 Fury (1950) with C. L. Moore
               + Variant Title: Destination: Infinity (1958) [as by Henry Kuttner ]
               + Variant Title: Fury (1947) [as by Lawrence O'Donnell ]
               + Variant Title: Fury (1950) [as by Henry Kuttner ]
               + Magazine/Anthology Appearances:
               + Fury (Part 1 of 3) (1947) with C. L. Moore
               + Fury (Part 2 of 3) (1947) with C. L. Moore
               + Fury (Part 3 of 3) (1947) with C. L. Moore

   * Michael Leigh
         o The Salem Horror (1937) [SF]
         o The Black Kiss (1937) [SF] with Robert Bloch

   * Pete Manx
         o Roman Holiday (1939) [SF] with Arthur K. Barnes [as by Kelvin Kent ]
         o World's Pharaoh (1939) [SF] [as by Kelvin Kent ]
         o Science Is Golden (1940) [SF] with Arthur K. Barnes [as by Kelvin Kent ]
         o The Comedy of Eras (1940) [SF] [as by Kelvin Kent ]
         o Man About Time (1940) [SF] [as by Kelvin Kent ]
         o Hercules Muscles In (1941) [SF] [as by Kelvin Kent ]
         o Dames Is Poison (1942) [SF] [as by Kelvin Kent ]
         o Swing Your Lady (1944) [SF] [as by Kelvin Kent ]

   * Probability Zero
         o Blue Ice (1943) [SF]
         o Corpus Delicti (1943) [SF]

   * Tony Quade
         o Hollywood on the Moon (1938) [SF]
         o Doom World (1938) [SF]
         o The Star Parade (1938) [SF]

   * Tony Quade/Gerry Carlyle
         o The Energy Eaters (1939) [SF] with Arthur K. Barnes
         o The Seven Sleepers (1940) [SF] with Arthur K. Barnes
               + Variant Title: Almussen's Comet (1940) [as by Arthur K. Barnes ]

The good thing about this approach is that it will summarize all Series data at the top of the Summary page and help identify any problems with them, e.g. it turns out that we currently have two "Tony Quade" series. The bad thing is that it can make the top part of the page appear too busy with minor series like "Probability Zero" appearing before Novels. One obvious alternative would be to have a separate "Short Fiction only" Series section before the Short Fiction section. Which one do you prefer? Any other approaches that we should consider? Ahasuerus 16:14, 1 May 2009 (UTC)

I suggest choosing between (1) ALL series at the top or (2) adding Short Fiction Series and Non-Genre Series (if we want -- whether to have Non-Genre Series is a side issue) and making all of the post-Anthology series be "pure" -- series containing exclusively titles of that particular type. Either of these approaches avoids the "empty series" problem for mixed-title-type series. #1 will result in all series being displayed, but in a big group at the top with no logical ordering beyond name. #2 has a potential problem of mixed-title-type series not including Novel, Collection, Omnibus, or Anthology being omitted. Whether #2 is a practical problem, I haven't yet investigated. There is a third approach, which is inelegant from all sorts of points of views: (3) Each series group could be restricted to displaying series of titles of its type together with titles of any subsequent type on the page (but NOT series containing titles of preceding types). This would ensure all series are displayed somewhere. --MartyD 17:49, 1 May 2009 (UTC)

When you say "ALL Series", do you mean all types including Editor, Essay, etc? I don't think we would want them to appear along with regular fiction series since they are really different beasts. Ahasuerus 04:23, 2 May 2009 (UTC)

When I say "ALL" I do mean all. I am thinking not just about the missing Short Fiction series, but also the appearance of "empty" duplicates of previously displayed series. At the root is no enforcement of homogeneity of title types within a series. The Series sections are built by asking for all series where ANY title has the desired type (except for Fiction Series, which looks for N/C/O, all of the other series sections look for just one type). The bibliography display, however, also goes to great lengths to display Titles only once. So to avoid "empty" series, any series previously displayed in some other section would have to be eliminated just as is done with the titles. A very simple way to do that is to put all series up front and avoid trying to have type-specific Series sections, since type-specificity isn't guaranteed anyway. That's (1) above. Another way to do it is to filter out series that have been displayed already in some other section. That's (3) above. Another way to avoid the problem is to present only the container series with heterogenous title types and to restrict the other series displays to only series with homogenous title types. That's (2) above. There's a fourth choice, which is to throw SF into Fiction Series instead of giving it its own section; I've included it in this summary:

1. Single series section
• PRO: no empty series, no missing series, no location ambiguity, independent of title types, easy to implement, backward-compatible in the API
• CON: "pure" series intermingled with no organization, possible excessive up-front "clutter"

Homogenous-only series sections (for the later, non-container sections)

• PRO: no empty series, better location of "pure" series, less up-front "clutter", easy to implement
• CON: mixed-type non-container series omitted, location may not be obvious (one N + many SF will be in F Series, not SF series), not backward compatible in the API (or extensive API additions)

Series in first applicable section only

• PRO: no empty series, missing series unlikely, better location of "pure" series, less up-front "clutter", backward-compatible in the API
• CON: location display-order dependent and may not be obvious (one N + many SF in F Series, not SF Series; one SF + many Essay will be in SF Series), hard(er) to implement

Add SF to Fiction Series (instead of being its own section)

• PRO:missing series less likely, easy to implement, semi-backward-compatible in the API
• CON:empty series, poor location of "pure" SF series, medium up-front "clutter", does not work for Non-Genre

This assumes we really don't want titles duplicated in the display. Also note that all/any of this is simply changing the display, not the structure of the underlying data. Having written this, my opinion is that either #1 or #3 would be best, depending on which behavior people prefer. I like #2 the least, and #4 leaves something broken. #4 can also be incorporated into #3. --MartyD 12:05, 2 May 2009 (UTC)

There is another, relatively minor, issue that needs to be discussed. If we are to include Non-Genre novels in Fiction Series, then we will need to designate them accordingly. We currently use "[SF]" for Short Fiction, "[C]" for Collections, "[O]" for omnibuses and "[NF]" for Non-Fiction, so "[NG]" would seem logical for Non-Genre (unless it's too obscure.) Also, at least one user has asked to display "[N]" next to Novels, which are currently not marked since Novel is the default Title type when displaying series. Ahasuerus 16:36, 1 May 2009 (UTC)

Bump since Marty's edits were invisible earlier today due to, um, a not entirely successful experiment. I am still trying to absorb his comments since sentences like "no enforcement of homogeneity of title types within a series" make my CPU, er, I mean my brain hurt a bit. What can I say? Moral obsolescence may be setting in ... Ahasuerus 00:58, 3 May 2009 (UTC)

I must admit that after looking at the example I wonder why we have a "Tony Quade/Gerry Carlyle" series and separate "Tony Quade" and "Gerry Carlyle" series too without them being connected. BLongley 01:21, 3 May 2009 (UTC)

The reason that these series are currently not connected is that there is no easy way to see them. At this time, for a Series to be displayed at the top of its author's Summary Bibliography page, it has to have at least one Novel, Collection or Omnibus in it. If it doesn't -- and many magazine Series do not since they never get collected in a single volume, with reprints spread across numerous different collections and anthologies -- then its constituent short fiction Titles are displayed at the end of the Short Fiction section in no particular order. As a result, few editors get to see the whole picture, so duplicate, related, etc Series never get cleaned up, which is what you see in the Kuttner case. This is one of the major arguments for changing the display logic. Ahasuerus 02:29, 3 May 2009 (UTC)

And I'd quite like the series to be in date order by when they started rather than alphabetical. And I quite like Short Fiction and Long Fiction to show in the same series, but I'd want them separated by long/short category first rather than date. And probably keep the Omnibuses for an "Even Longer Fiction" subsection. BLongley 01:21, 3 May 2009 (UTC)

I'm not sure this is a good example to start with, it makes me head hurt. And we haven't even shown nested series yet. BLongley 01:21, 3 May 2009 (UTC)

Re: "no enforcement [yadda yadda]". What I'm really saying is the display is pretending there are "types" of series -- corresponding to the types of titles -- but it looks to me like any type of title can be included in any series, so the underlying database and code does not really support that concept (or does only to some degree, which is why there is odd behavior). --MartyD 01:54, 3 May 2009 (UTC)

That's exactly right. I remember Al making a comment about it. Ahasuerus 02:41, 3 May 2009 (UTC)

Short and Long Fiction already do show in the same series. See all three series under Henry Kuttner. What doesn't show up is a series with only Short Fiction. Short Fiction Series is not displayed because it ends up being a mess when there are mixed-title-type series, such as in Kuttner's case. And not having the Short Fiction Series causes the odd date mis-ordering you see at the end of his Short Fiction section (those out-of-order titles belong to a series and are not intended to be displayed where they appear). --MartyD 01:54, 3 May 2009 (UTC)

As for alternative sortings, etc., that's an interesting idea, but a different issue. Looks like we should start a Sorting Wish List somewhere. :-) --MartyD 01:54, 3 May 2009 (UTC)

Agree. This mini-project is just a "proof of concept", i.e. proof that we can modify software behavior [edit:] without Al's active participation and not have it explode in various spectacular and fascinating ways. That's why my original thought was to simply add "Short Fiction" and "Non-Genre" to the list of Title types that trigger the Fiction Series section. I guess it's option number 4 on Marty's list, but I am not sure why it would exacerbate the "empty series" problem or not work for Non-genre? Ahasuerus 02:41, 3 May 2009 (UTC)

It won't exacerbate anything, but it will leave the problem unfixed and popping up in various places (which I gather has been seen with regard to "empty" series in the Anthology Series section -- that's the same problem). If you want to have the display work mostly the way it does now, with addition of Short Fiction Series and Non-Genre Series, I suggest we try #3 (add NG and SF series prior to their respective non-series sections, filter out series previously displayed on the page, add the proposed [NG] tag to Non-Genre titles in the Fiction Series section) and see what people think. It is the most work, but least outwardly disruptive and fixes the two main bugs (missing info, empty entries). We could then look at reorganizing and/or consolidating the series sections as a follow-on step (and I have a feeling there will be other bugs that should be fixed first). --MartyD 11:49, 3 May 2009 (UTC)

Works for me! Ahasuerus 15:51, 3 May 2009 (UTC)

Since this is a test change and there is no opposition, I think we can proceed and see what happens. In the meantime, we can start working on prioritizing bugs/features so that we would have a "pipeline" with some changes being implemented while other proposed changes are still being discussed. Ahasuerus 01:22, 4 May 2009 (UTC)

Sounds good to me and yes I hope nothing implodes. :-)Kraang 01:49, 4 May 2009 (UTC)

For a seriously messed up series display, see Brian W. Aldiss. Several series, such as Hothouse are missing completely, and Enigma -- a nested series -- is put under Essay Series (because some of the nested series contain an essay) with only a select few of the sub-series included.... --MartyD 16:27, 4 May 2009 (UTC)

"Hothouse" could be patched up by adding the eponymous fix-up novel to the series, but overall it's a rather spectacular mess. Aldiss is also responsible for The Horatio Stubbs Saga, a Non-genre series, so he is a pretty good guinea pig. Ahasuerus 17:05, 4 May 2009 (UTC)

(Unindent) I have not read ALL of the above, but I do have one thing to chime in on the topic of "Series". Why does a pub have to 'disappear' once it's been assigned to a series? Not everyone is even cognizant that some of these (stretched) series even exist. I've searched for pubs only to find they are the third variant in some imaginary series. Why can't a pub exist as a novel/collection/omnibus AND show up in the series of its' choice?? I find Poul Anderson's page impossible to navigate; Gordon R. Dickson; Andre Norton; Frederik Pohl; and many others. Not user-friendly. --Bluesman 05:09, 5 May 2009 (UTC)

I don't know the reasoning behind the current behavior. I've found myself bitten by it, too. I misspoke about it slightly: titles can be displayed multiple times, but displaying them in a series removes them from further display. So putting all series at the end in theory would allow the titles to be displayed both in the proper non-series spot and in the series. Another variation to consider down the road. --MartyD 10:16, 5 May 2009 (UTC)

General interest magazines

We have a section for "General Interest Magazines with SF Content" on the Magazines page. I can see how it can be useful to have a list of links to the likes of Argosy, Boy's Life and Playboy in one place, but with the steady increase in the number of non-genre magazines that we cover [bits and pieces of], I wonder if we can realistically have all of them listed together and still keep the list manageable? If not, how can we best handle them? Ahasuerus 08:27, 1 May 2009 (UTC)

Did you take May 31st off?--swfritter 17:46, 1 May 2009 (UTC)

I don't think I am familiar with "May 31st". Is it a magazine? I can't find any references to it in that Wiki page's History... Ahasuerus 18:10, 1 May 2009 (UTC)

I think we should retain a list of such magazines for those who need quick access. But I don't think we need to create individual Wiki pages for each title. Perhaps we should just remove the list from the SF magazines page, create a specific page for this list of titles, and place a link to the page from the SF magazine page (just as we handle fanzines.) MHHutchins 15:22, 1 May 2009 (UTC)

Definitely no wiki pages for each title. They should have a page of their own - one page would work for now although we may soon need some sub-headings. These pubs are not likely to be accessed very often by the casual user. As they start getting more complete we will primarily need to access to check and see if an issue is already in the database. In some cases we may eventually have to consider merging editor records. I have been reading a little bit of Bleiler's "Science-Fiction: The Early Years" each day. It's a wonderful book that has plot summaries for thousands of works that were published before 1930. Many novels but also a lot of short stories in both magazines and collections. I may start putting a few of these in each day which will substantially increase the number of non-genre magazine entries.--swfritter 17:45, 1 May 2009 (UTC)

I think we are already able to get a list of non-genre magazines by searching on "Editors of" in the database. I suppose the fact that the regular Search form won't let you see anything past the first 100 hits is reason enough to have a separate Wiki page... Ahasuerus 02:46, 3 May 2009 (UTC)

If I don't hear anything more I will create a new page in the next couple of days. The reference to that page on the magazines page does not need to be prominent since this is data that will be rarely accessed via the pub level. I might also but a link to the fictionmags site for people who are looking for more complete data for such magazines.--swfritter 20:38, 3 May 2009 (UTC)

As a side issue. When I first began entering non-genre magazines I was creating editor series while others had the good sense (and wiki acumen) to link by editor name. The series methodology requires more maintenance so I have changed all the non-genre magazines to link by editor name - most of them were already that way. Would it makes sense to totally remove the series links?--swfritter 18:21, 1 May 2009 (UTC)

I agree that linking by editor name seems like a better approach in this case. Ahasuerus 02:46, 3 May 2009 (UTC)

Help:Screen:Moderator updated

I have added a paragraph to Help:Screen:Moderator to cover what moderators can do on the Wiki side that regular editors can't. Corrections/additions welcome! Ahasuerus 04:58, 2 May 2009 (UTC)

Title type tags in bibliography display

The changes to the display of Series in the bibliography (see the discussion above) has uncovered a need for some additional tagging of titles to indicate the title type (e.g., Spending My First $100M (2009) [SF] -- "[SF]" is the "tag"). This is currently done only in the Fiction Series section and only for Anthology, Collection, Omnibus, and Short Fiction titles. All other title types in Fiction Series are untagged, as are all title types in all other Series sections.

I believe the intent of the code is to tag everything other than titles with the "default" type for the series. E.g., Fiction Series would tag everything but Novel, Essay Series would tag everything but Essay, and so on. I am making it actually do that, but many "tags" have not been defined.

I propose introducing abbreviated tags for each type of title for which there is a corresponding Series section and unabbreviated tags (using the title's type) for everything else. Here is a table of what I propose. Green rows are types that have Series sections today. Blue rows will have series sections in the near future. Yellow rows have no series sections. BOLD in the "Proposed Column" tag is new.

Title Type	Current Tag	Proposed Tag
NOVEL1		(none)2
COLLECTION1	[C]	[C]
OMNIBUS1	[O]/[O<type>]	[O]/[O<type>]
SERIAL		[SERIAL]
EDITOR		[ED]
ANTHOLOGY	[A]	[A]
NONFICTION		[NF]
CHAPTERBOOK		[CHAPTERBOOK]
NONGENRE		[NG]
xxxART		[xxxART]
SHORTFICTION	[SF]	[SF]
POEM		[POEM]
ESSAY		[ES]
REVIEW		[REVIEW]
INTERVIEW		[INTERVIEW]

¹These all appear in a single "Fiction Series" section.

²There is a proposal to use "[N]".

I am soliciting opinions on whether abbreviations should be used for all of them and for specific abbreviations/tags to be used in any particular case (suggest alternates for the abbreviations I've proposed, too). Thanks. --MartyD 11:54, 5 May 2009 (UTC)

[NF] sounds reasonable, but I suspect that the rest of the new types will appear outside of "their" Series type so infrequently that our users will have a hard time remembering what, say, "ES" stands for. Should we spell them out? (I'll check the latest backup tomorrow to see what the numbers look like at the moment -- unless you already have the numbers handy.) Also, CHAPTERBOOKs are a whole different headache, but there will be time to revamp them later. Ahasuerus 04:05, 6 May 2009 (UTC)

More long-form ones is certainly easy; those are just the title type string and are used instead of a hard-coded abbreviation. From the 4/25 back-up. Count of types appearing in any series:

+--------------+----------+
| title_ttype  | count(*) |
+--------------+----------+
| NOVEL        |    21709 |
| ESSAY        |    11001 |
| SHORTFICTION |     4698 |
| ANTHOLOGY    |     2009 |
| OMNIBUS      |     1427 |
| EDITOR       |     1343 |
| COLLECTION   |      824 |
| NONFICTION   |      493 |
| NONGENRE     |      153 |
| POEM         |      134 |
| SERIAL       |       83 |
| INTERIORART  |       37 |
| CHAPTERBOOK  |        1 |
| COVERART     |        1 |
| INTERVIEW    |        1 |
| REVIEW       |        1 |
+--------------+----------+

Count of non-N/C/O types appearing in a series with some other type:

+--------------+----------+
| title_ttype  | count(*) |
+--------------+----------+
| SHORTFICTION |     3699 |
| ESSAY        |     1627 |
| ANTHOLOGY    |      314 |
| NONFICTION   |      152 |
| EDITOR       |      145 |
| POEM         |      109 |
| SERIAL       |       83 |
| NONGENRE     |       32 |
| INTERIORART  |       23 |
| CHAPTERBOOK  |        1 |
| INTERVIEW    |        1 |
| REVIEW       |        1 |
+--------------+----------+

Looks like there is a coverart series out there.... --MartyD 10:15, 6 May 2009 (UTC)

Can we please get rid of "chapterbook" entirely? Chapbooks have been around for centuries. "Chapterbooks" didn't exist until some teachers in the past decade or so wanted to build their students' self-esteem about progressing from illustrated story books to non-picture books with chapters. MHHutchins 04:07, 7 May 2009 (UTC)

It would be easy to change the display logic, but the term "CHAPTERBOOK" is also embedded in dropdown lists and in the lists of values allowed in certain database fields and in the validation logic and... well, you get the picture :) I am sure it's doable, but it's probably best handled as a separate change, in part because it will require a database tweak. Ahasuerus 04:40, 7 May 2009 (UTC)

All seem reasonable to me. I am especially looking forward to NG, NF, and ES. Kevin 00:42, 8 May 2009 (UTC)

Now that these are present and visible to all, I'm soliciting feedback. I suggest adding a subsection (=== [existing tag] ===) below this point to discuss any particular tag. --MartyD 20:07, 11 June 2009 (UTC)

SF

Can we please change "[SF]" to "[Short]" or some other code that does not also stand for "Science Fiction"? See Source Forge FR #2805039 (Change display of shortfiction in series). This request has ben on the Wiki as Feature:90157 for some time. -DES ^Talk 20:28, 11 June 2009 (UTC)

I can support this idea, particularly as SF might also mean "SourceForge"! ;-) Just what do we change it to? "[Short]" might imply Shortstory as opposed to Novella or Novelette. BLongley 22:34, 11 June 2009 (UTC)

Can you do [NA], [NV], [SS], and [Sh] instead of [SF]? Can the code read the title length? That would be fantastic! Kevin 01:48, 12 June 2009 (UTC)

If you do this, i suggest [NT] instead of [NA] to avoid the latter being read as "Not Applicable" which is often abbreviated NA or N/A. We will probably need some readily available index or caption to these terms -- perhaps the abbreviate ions could link to a wiki page which explains all of them or perhaps there could be one such link somewhere on each biblio page? -DES ^Talk 05:06, 12 June 2009 (UTC)

The display is using the title, so IF a title has a length available, we could certainly make use of that. For SHORTFICTION titles as of a couple of months ago, these are the lengths:

+----------+----------------+
| count(*) | title_storylen |
+----------+----------------+
|    62666 | ss             |
|    18856 | sf             |
|    18811 | nt             |
|     5667 | NULL           |
|     4704 | nv             |
|       22 | -              |
|       19 | None           |
|       16 |                |
|        6 | shortfiction   |
|        5 | na             |
|        3 | White Noise    |
+----------+----------------+

Note that what you see for the length does not have to be what is displayed to represent it. All of the tagging can use any text we want it to. --MartyD 10:20, 12 June 2009 (UTC)

Chapterbook

Do please change the display logic on this at least. I am hopeing that eventually this will be converted into a fully supported SHORT WORK type, but one step at a time. -DES ^Talk 20:28, 11 June 2009 (UTC)

It can be done, but needs work in a lot of places, almost as much as adding or changing to "SHORT WORK" or whatever. And a lot of rules and standards agreement - we have genuine self-proclaimed chapterbooks but they're not always single-item things, they're COLLECTION and ANTHOLOGY types really too, not always one SHORTFICTION published standalone. So we'd be undoing a lot of the workarounds already in place. Something I'd like, but no Developer can go do something that keeps everyone happy, the Designers need to get involved first. BLongley 22:44, 11 June 2009 (UTC)

Yup, we definitely need to decide what we are going to do with the whole "Chap(ter)books issue" first. Converting them to a "container type", with a separate section reserved on the Summary page, was the leading contender the last time we talked about it and we can probably pull it off now, but we need a more detailed design. Ahasuerus 00:09, 12 June 2009 (UTC)

Serial

I think we should reconsider the 'Serial' display on the bibliography page (Can this patch be applied to the series display pages - I would like it there - All parts I think). Unless there is a compelling reason for it (Any Serial title in a series, will normally (always?) have a novel title in the same series and already be displayed). See Poul Anderson and his serialized 'Iron' near the bottom of his fiction series stuff. Since the serialization is (correctly in my opinion) in the series, and the full novel title is in the series, it is being displayed twice on his bibliography. Kevin 02:17, 12 June 2009 (UTC)

If we remove the Series designation from the two SERIAL records, they will still appear under the associated NOVEL record, which will address the immediate problem. We still need to address the larger "lexical match" issue, but that will have to wait at least a few weeks. We could probably fix the "lexical match on ANY author" bug real quick, though -- see the way Harry Harrison's To the Stars is currently linked to L. Ron Hubbard's 1950 SERIAL that uses the same title.

But those two 'serials' appear in that hybrid Baen paperback magazine. I don't recall if it was destinies, new destinies, etc. People looking at the book contents should see an appropriate series call out for that story. Kevin 04:27, 12 June 2009 (UTC)

As far as applying the logic from the last patch to the Series page, it is definitely desirable and has already been requested on Sourceforge -- see Feature 2804561. Ahasuerus 04:04, 12 June 2009 (UTC)

ISFDB Downtime

ISFDB was down much of Monday and Tuesday due to two separate and seemingly unrelated software failures. This is rather puzzling, but hopefully it won't happen again. In the meantime, please keep in mind that we have two backup areas, one at http://groups.google.com/group/isfdb and the other one at http://isfdb.blogspot.com/ , where we post downtime announcements when the Wiki is not available. Ahasuerus 04:05, 6 May 2009 (UTC)

I've been getting several timeouts recently - I hope this isn't due to testing the live server against proposed changes? BLongley 22:46, 11 June 2009 (UTC)

Nope, there has been no testing going on on the live server. As far as I can tell, it occasionally decides to refuse all connections for a few minutes. Unfortunately, I haven't been able to find the root cause :( Ahasuerus 00:05, 12 June 2009 (UTC)

Alan Moore and Co

[Moved to Rules and standards discussions]

Local copy of ISFDB on Windows

I've put together a set of instructions at ISFDB:Personal_Windows_Website for setting up a private copy of the ISFDB in a Windows environment. It's adapted from the Linux instructions and is based on a sample of one, so I'm sure some tweaking will be required. Leave a note at User_talk:MartyD if you try it and need help getting it running. And of course feel free to augment/clarify what's there based on your own experiences. --MartyD 10:33, 13 May 2009 (UTC)

Wonderful, thanks! I took a peek yesterday night, but had to run and fight other fires. I'll give it another shot tonight. Ahasuerus 17:35, 13 May 2009 (UTC)

Apache installed, no problems encountered. The MySQLdb installation program, on the other hand, found a problem with my version of Python, apparently due to the fact that at one point I upgraded Python to 2.6, realized that it was causing issues with some older scripts and downgraded back to 2.5. Apparently, the downgrade wasn't as clean as I thought and the current version is some kind of 2.5/2.6 hybrid which is not recognized by MySQLdb. Hopefully, this won't be a problem for anyone else. Ahasuerus 03:39, 14 May 2009 (UTC)

I couldn't get MySQLdb to work with 2.6. I did do a clean uninstall instead of trying to downgrade, though. --MartyD 10:47, 14 May 2009 (UTC)

I had ActivePython installed since I use it to talk to library catalogs. I have now installed regular Python instead, which had some side effects, but that's another story. I already had MySQL and Cygwin, so adding the make/CVS functionality wasn't too troublesome. There was a minor glitch with permissions when installing the ISFDB scripts, which I documented on the instructions page. At this point everything looks OK and Apache can serve static files (localhost/isfdb.gif etc), but it refuses to recognize the existence of any cgi scripts:

[Fri May 15 00:22:04 2009] [error] [client 127.0.0.1] (OS 3)The system cannot find the path specified.  : couldn't create child process: 720003: history.cgi
[Fri May 15 00:22:04 2009] [error] [client 127.0.0.1] (OS 3)The system cannot find the path specified.  : couldn't spawn child process: C:/Program Files/Apache Software Foundation/Apache2.2/cgi-bin/history.cgi

I played with httpd.conf to the best of my (limited) ability and even added ExecCGI to the list of options, but it didn't help. ScriptAlias seems to be configured properly:

ScriptAlias /cgi-bin/ "C:/Program Files/Apache Software Foundation/Apache2.2/cgi-bin/"

Oh well, I'll give it another shot tomorrow. Ahasuerus 04:33, 15 May 2009 (UTC)

This is the error you get if there is no c:\usr\bin\python.exe for the cgi scripts to run. The ISFDB build/install process pretty much hard-codes this path (you'll see it at the top of the Apache2.2\cgi-bin\history.cgi you were trying to run). The easiest workaround is to mkdir c:\usr\bin and then copy python.exe into it from your python installation. If we get to the point of being able to make tweaks, I will add customization of that location to the build/install process. --MartyD 10:10, 15 May 2009 (UTC)

That did the trick -- thanks muchly! :-)) Ahasuerus 14:13, 15 May 2009 (UTC)

Hmmm. I don't actually have a c: drive (well I do, but it's an SD card reader with no card for it) so I think I need the customisation. BLongley 17:48, 15 May 2009 (UTC)

Sorry, it doesn't have to be C:. There is no drive specification in the CGI files, so it needs to be on the same drive as the working directory for the Apache process. By default, that will be the drive onto which Apache was installed. --MartyD 18:02, 15 May 2009 (UTC)

OK, I might give it a go this weekend. I've got Apache and MySQL working already, although not the same versions. Sounds like I ought to replace the ActivePython though. (Not a problem, I've never used it.) BLongley 18:39, 15 May 2009 (UTC)

As a prize for getting it running, I can send you the proposed series changes to try out. --MartyD 00:39, 16 May 2009 (UTC)

Proposed New Feature - Reviewed Author search

Since MartyD helped me get a local ISFDB working I've been playing around a bit. What do people think of this? How many want it? Is it in the right place, under the right name?

BLongley 18:49, 18 May 2009 (UTC)

Looks great, and would be a tremendous help in getting rid of those authors with only invisible records. Thanks. MHHutchins 19:31, 18 May 2009 (UTC)

Thanks to Kev Pulliam for the suggestion. Now all we need is for me to relearn CVS and one of the Sourceforge Admins to add me as a Developer and someone to explain how and when such changes can be deployed... (Ahasuerus, can you deploy code on the live server?) BLongley 20:03, 18 May 2009 (UTC)

I'd encourage more people to try the local installation of ISFDB so we can get more testers involved. While I am of course an absolutely brilliant programmer and there can be no possibility of my activity introducing any "bugs", I may introduce unwanted "features". ;-) So more people testing offline would be good. BLongley 20:03, 18 May 2009 (UTC)

I vote yes. Looks great. (And I've even dusted off a WinXP laptop to see about doing a local install for testing and or simple coding myself) Kevin 22:57, 18 May 2009 (UTC)

Al and I are trying to make it possible for me to bounce the Web/MySQL servers. As a side effect, it may also enable me to deploy software changes, but if I tried that, I would more than likely cause a catastrophe of mind boggling proportions. (Or at least cause extended downtime and force us to go back to the backups.) Al is still our best bet, but if he is not available, we'll have to think of some other way. Perhaps we could create "change packages", cross-test them and see if Al could install them once every 2-4 weeks rather than on an ad hoc basis? Ahasuerus 00:30, 19 May 2009 (UTC)

I think (but am not sure) that I've checked in edits to three modules that will enable this functionality. Anybody that can download and try it out, please do! I'm going to reserve some of the other changes till I can see if this worked. BLongley 20:53, 20 May 2009 (UTC)

The activity tab under https://sourceforge.net/projects/isfdb/ reports that:

1. blongley committed patchset 159 of module isfdb2 to the ISFDB Bibliographic Tools CVS repository, changing 1 files, 1 hour ago
2. blongley committed patchset 158 of module isfdb2 to the ISFDB Bibliographic Tools CVS repository, changing 2 files, 1 hour ago

I also see your changes at http://isfdb.cvs.sourceforge.net/viewvc/isfdb/isfdb2/edit/ and http://isfdb.cvs.sourceforge.net/viewvc/isfdb/isfdb2/biblio/ and can download them. I'll try to test them locally later tonight. (Hey, this is exciting!) Ahasuerus 21:36, 20 May 2009 (UTC)

There's two separate sets of changes I've made (3 files for "Reviewed Author", then 2 for "Pseudonym Search") - five files in all. And I'm excited too. Or is it "nervous"? I've recently made some "Emergency" changes at work that caused me more work and less worry - you lot are unknown critics! BLongley 23:12, 20 May 2009 (UTC)

Publisher Search Fix

I think I can fix this search:

So it doesn't give:

But this instead:

There's a bit of a problem with the "[100-199]" link at the bottom if that's needed though, so I'm reluctant to release this as an incomplete fix unless someone can test it. BLongley 19:15, 18 May 2009 (UTC)

Wow! Even better. An advanced search that actually works? Go for it, pal! MHHutchins 19:32, 18 May 2009 (UTC)

The options that don't deliver anything but lots of purple look fixable, although purple follow-on pages aren't totally avoided yet. I've got exact "Page Count" searches working for instance, but wonder if anyone would ever use such? BLongley 20:12, 18 May 2009 (UTC)

I've got "Cover Artist" working too - but is "Back Cover Artist" worth fixing? BLongley 20:50, 18 May 2009 (UTC)

I might do "Price" searches though, after all the weird "£4.13" submissions Fixer did recently. It seems only humans are good at spotting weird prices. BLongley 21:12, 18 May 2009 (UTC)

A search for back cover artist would be too specialized for my use. But I'd love to have a boolean search for publisher using a wild character combined with year or author. Would that be a part of your "fix"? MHHutchins 21:16, 18 May 2009 (UTC)

There's always the question of whether anything I do will ever get deployed first. :-( I can look at wild characters next though. Combination searches are something for the future - I still haven't figured out where the "ANDNOT" problem stems from and I thought it would be a simple matter of finding where Al missed a space. :-( But I'll offer my usual Developer/Designer/IT Consultant suggestion - you can have several imperfect improvements "soon", or a perfect one "later". The difference is that for ISFDB there's no cost difference. ;-) BLongley 21:57, 18 May 2009 (UTC)

I'm pretty sure that the ANDNOT problem is very simple. I'm looking at an old version of the code, & also have no way to test it; but if you find the file named search.py & look for the line that says:

	print '<input TYPE="RADIO" NAME="%s" VALUE="ANDNOT">AND NOT' % (operator)

I think inserting a space in the VALUE field will fix it. -- Dave (davecat) 11:27, 1 June 2009 (UTC)

Bill aready did it in CVS: patch. --Roglo 12:16, 1 June 2009 (UTC)

Soon. Yes Please fix all the purple pages. As to the second page going bonkers, I think there is a bug in the 2nd page results for most searches, as they IIRC change from clickable links to cliable links straight to 'edit'. That might be the true source of the second page problem

I now have fixes for all the main purple pages of Publication Search. Not yet for follow-on pages. It seems people can see my first fixing attempts now on other searches, so I'll wait so see how those are received first before potentially breaking anything else. BLongley 22:49, 20 May 2009 (UTC)

I think I've said this elsewhere, but the code changes for all the broken parts of Advanced search have been submitted, and I think I've covered all the likely follow-on pages too now. I think I'll pause on other changes to allow our tester(s) (more testers welcome!) to assess them and to encourage Ahasuerus to roll them out. BLongley 22:44, 23 May 2009 (UTC)

I don't think backcover artist data entry was ever implemented although there is a field for it.--swfritter 00:17, 19 May 2009 (UTC)

The polite term is "partially implemented" :-) 00:20, 19 May 2009 (UTC) —The preceding unsigned comment was added by Ahasuerus (talk • contribs) 00:20, 19 May 2009 (UTC).

Dangit - you guys are teasing me - I saw a comment of 'Partially implemented' and thought it was already up and running. (chuckle) That's kind of like having a Hay Baler, and no Hay Rake. Only Partially Implemented. Kevin 00:25, 19 May 2009 (UTC)

Perhaps it can be done through the Web API? Have we sent Kevin on a snipe hunt yet?:-)--swfritter 00:31, 19 May 2009 (UTC)

Do the snipes live in the Briar Patch? Kevin 01:52, 19 May 2009 (UTC)

"Snipe" is a notorious Back-Cover artist, but as secretive as Banksy. Indeed, Banksy may be the artist for several back-covers. Or front covers. Your mission, should you decide to accept it, is to find the Back-Cover artists, identify them, and create suitable pseudonyms. BLongley 22:49, 20 May 2009 (UTC)

But then they will still be Back Cover Artist Pseudonyms... and people will still have trouble finding them. Kevin 02:54, 21 May 2009 (UTC)

Not with my latest fixes. I've noticed (while looking into the "Doctor Who and the Unfeasibly Long Tags" issue) that there are several Back-Cover-Art entries recorded in notes. So there's obviously a small desire to record such. If we can actually enter them, my changes will find them. I think there's a lot of other places where we need to add the code to display them though. Still, has anyone successfully submitted any yet? BLongley 22:39, 23 May 2009 (UTC)

(Unindent) OK, I've found a couple more publications that could do with Back Cover Artist entries: Science Fiction Monthly, July 1974 and Science Fiction Monthly, August 1974. Does anyone else think this is worth working on? BLongley 21:05, 31 May 2009 (UTC)

Perhaps Interior Artist search would be more useful for now? I think it is the same search, just with INTERIORART instead of BACKCOVERART. --Roglo 21:17, 31 May 2009 (UTC)

We can add that search too, but I was actually asking about being able to enter Back Cover Artist. The search changes are already made for that, but are pretty pointless if we don't actually have any. But it stops the big purple errors. BLongley 22:26, 31 May 2009 (UTC)

The only references to BACKCOVERART are in SQL code (plus bib.displayWorks('BACKCOVERART'), so that it could show up in bibliographies). I don't think it is possible to create a BACKCOVERART without access to the SQL server. You can create multiple COVERART records for a single pub if you are persistent enough (and conspiring with a moderator). --Roglo 13:11, 1 June 2009 (UTC)

It might be possible to create them via the Web API, I haven't checked. But I'm actually asking about whether it would be worth making them more easily enterable, or possible, if the display code is already there. It seems a shame to leave it partially implemented. I doubt it's worth a lot of effort for the few pubs I've identified that could do with it, but it might be for some people that are using "bc" page codes. Or people that want to indicate that there is a wraparound cover and the art is on the back too. There's probably not enough reason to add more fields like "Artistn" to the editpub screen, but it could be an allowable content type like INTERIORART is, for those that really want such. BLongley 19:33, 1 June 2009 (UTC)

A smaller fix

The Publication area of Advanced Search has lots of broken bits, but the Author Search has only one I think. Pseudonyms. I can change this:

to this:

and although I can't (and so haven't) tested the follow up page I can't think of anyone with over 100 people using the pseudonym, so am fairly happy for this to go forward if I've got the intended purpose right. BLongley 22:18, 20 May 2009 (UTC)

OK, that looks awful - my screenshots are worse than my coding (I hope!). But if the idea is that you put in the pseudonym and get the canonical author(s) I think I'm on the right lines. I think I'll check that in while I still remember how, and leave the "Pseudonymns" typo for a later fix. BLongley 22:24, 20 May 2009 (UTC)

Use of varients for different texts

I just noticed that In Fury Born is listed as a variant title of Path of the Fury. Nowe the copyright page says that In Fury Born "Contains a much revised version of Path of the Fury". This appaears to be accurate. Roughly 2/3rds of the text of IFB is new, the remaining third is a reworked version of PotF, with a fair amout of rewriting, but no essential change in the story, and much text unchanged. It seems to me that linking two works with as much difference as this is not what VTs are for. It also means that IFB does not show up in its nornal place on David Weber, and a user could easily think, looking at that page, that IFB was only a retitling of PotF. I would like as clearer policy on what VTs should and should not be used for. In particualr, is it or is it not appropriate to link as VTs two works that are related but significantly different, such as expansions and revised versions. Obviously whe4n and if we get some sort of "based on" or "related work" link in the software, that will be the way to go, but we don't have one now. -DES ^Talk 05:07, 22 May 2009 (UTC)

You may want to see this recent discussion of variant titles.... FWIW, in Poe's case, where the text is significantly altered (beyond changing a name or adding/dropping a couple of leading lines) I've gone with separate titles and notes. --MartyD 09:53, 22 May 2009 (UTC)

And if you've read that discussion you are probably as exhausted as I am from re-reading it. There is no real quantitative measure. There are stories that are 99% identical except for the last paragraph that should be entered as separate titles and others that might be substantially different that could justifiably be merged if the titles are identical or made variants if not. The most important thing is to fully document the information in the title notes. I agree, we should have some general guidelines but I have no idea how it could be worded. My own opinion on the above case is that the two versions are so radically different that they should be separate titles.--swfritter 14:33, 22 May 2009 (UTC)

The current variant function only works well enough to record a difference in title or author credit. It is unable to record a difference in text. There should be software support for an entirely different function for that purpose. And until there's someone who can do that, this topic, just like many discussions that have preceded it, sadly, will be a waste of time. We don't need to fret over quick fixes that will have to be corrected sometime down the line. As Swfritter points out, recording information in the notes is the only way to do it at the present time. MHHutchins 15:23, 22 May 2009 (UTC)

Well then.. lets try to 'solve the problem' - Could we 'clone' the Variant code and call it 'Expanded Variant' or something similar. It seems to me that would involve the least work (duplicating a present function), and just changing the name and descriptions... Instead of (AKA 'The Original Title') in a contents listing it could show (An Expansion or Derivative Work of 'The Original Title'), and so on and so forth. I bet that once we 'clone' the function once, we will then immediately want to clone it again for 'Abridged Variant' or something similar, And then perhaps a third time for 'Juvenile Variant', and then perhaps a fourth time for 'Screen Adaptation (Teleplay, Screenplay) Variant', and then a fifth time for 'Graphic Novel Variant', and then a 6th time for the reverse 'Novelization Variant' but that perhaps will need more codeing... anyway... Many birds.. one stone, film at eleven Kevin 03:36, 23 May 2009 (UTC)

When it gets implemented it will probably be a relatively simple fix and one that will allow for easy expansion of variant processing definitions. A flag could be added to designate whether the variant type is "variant title", "variant text", etc. and a set of rules involving processing procedure for each type could be defined. Maybe someday.--swfritter 13:29, 23 May 2009 (UTC)

Once we are going with new code, i hope we can fully implement "based on" relationships to handle varient text, fixups, expansions, condensations, revised versions, and the like, and make clear which is which. This means allowing for multiple targets, and/or allowing a given work to take part in multiple "based on" relationships.

In the meantime, I think VT relationships between works with significantly different text, including expansions, should be broken, and the relationship documented in notes, and for fixups at least, in tags. -DES ^Talk 15:06, 23 May 2009 (UTC)

I think the relationships should be kept. Assuming we get the fixes, it'll be much easier to find which relationships need adjusting if we have them rather than starting from scratch with people reading notes on unrelated titles. This does not, of course, stop people from recording notes which will help when we get to that point, or even in the meantime. I'm not fond of Tags as they seem a lazy way of recording incomplete notes, and would prefer people use pub notes or even the Wiki for proper notes on the publication records they know about. There's a whole concept of "edition" that is lacking at the moment that we can do something with in the meantime with (revised) (expanded) (abridged) or other suffixes on titles, but that will be lost if a different title is a revision, expansion, or abridgement of another and there's no variant link. BLongley 22:27, 23 May 2009 (UTC)

We need or at least should have, the notes, whether the VT is broken or kept, if the final version is to be at all accurate. I am inclined, by the way, to think such notes should usually be title-level rather than pub-level, but either is better than nothing. Take a look at what I have done with Path of the Fury, where I did break the VT. -DES ^Talk 23:22, 23 May 2009 (UTC)

Agreed on the notes. Recording at every level possible in the meantime is good. However, breaking the VT now just means that somebody will have to reconstruct it later when they find the notes. There is no way that the people that fix the software will be also able to provide a list of things that need looking at after the fix, as there is nothing left in the database to suggest there is any kind of relationship. "Notes, notes and more notes" helps. Breaking links that are there for a reason, however poor the reason may be by current standards, doesn't help. I repeat - keeping the links and noting on both sides is better. How would you feel if I broke every current variant US/UK title that didn't have an explanation recorded on both sides? The variants are there for a reason: yes, it's good to add more notes, but if you're wanting software improvements I think it's better to let the programmers also provide lists of current variants that need a second look rather than break the variants and start from scratch. BLongley 00:04, 24 May 2009 (UTC)

Unindent. If you really thank that a full "based on" relationship will be implemented soon, say within the next 9 months or so, AND there there is a reasonable programmatic way to find VTs that represent differing texts short of a manual examination of all VTs, then not breaking existing but (IMO) improper VT links might be a good idea. Note that if links are broken but good notes are added, a query scanning the notes field for such key words as "version" "based on" "expanded" and the like should probably find any such situations where good notes were inserted. This is not starting from scatch. In the mean time, the DB comntains incorrect information, as it seems to me that a VT relationship is a way of saying "these two pubs contain essentially the same text, even if under a differeent title or author". Removing incorrect info and replacing it with accurate data in the noites is IMO a good thing^TM. How do you expect that VTs representing difffering texts can be programatically identifed from among all VTs? -DES ^Talk 01:08, 24 May 2009 (UTC)

For Novel length works - Compare paperback pagecounts if pagecount is not within x pages of the same, flag for review. Same for Hardcover with y pages. For all works, check all variant title and pub notes automatically for 'expanded', 'abridged', etc. By allowing the variants to remain we reduce the first run of variants (to be reviewed in order to apply a different variant type) to the likeliest subset of records to search. I'm with Bill here... it may be technically incorrect at the moment... but it's not completely wrong. Kevin 02:37, 24 May 2009 (UTC)

I don't think that differing texts can be programatically identified, but I think that we can far more easily identify the VTs for humans to look at if they are VTs than if they are not. I know I'd prefer to have a list of all 23,000 VTs and the things they are VTs of than have to look at all 398,000 titles. And that 23,000 will be much shorter if we can eliminate "same title, pseudonymous authors" and prioritise "massively different page counts" and "notes with certain keywords in". I don't think we've got a massive number of incorrect variants currently, I think you're reading too much into what you see as the definition - VT has never meant "essentially the same text" to me, just that there IS a relationship of some sort. I'd actually like to see more (sensibly noted) variants right now: e.g. Stranger in a Strange Land definitely needs splitting into original and expanded/restored versions at least. The sooner we do it the easier it will be to put each pub under the right version. At the moment, each new pub just gets thrown into the pot and rarely has enough information at pub-level to sort it out. Split NOW and hopefully new additions will get put into the right category. BLongley 06:17, 24 May 2009 (UTC)

I found this ISFDB_FAQ#How_does_the_ISFDB_deal_with_.22Portions_of_this_story_originally_appeared_in....22.3F in my browsing today. Per the FAQ, Variants 'are' an accepted methodology of documenting Text changes "If an individual story is rewritten or revised, then we create a Variant Title for it and add the nature of the changes, e.g. "expanded", "abridged" or "restored", in the Notes section. Please note that these conventions are likely to change in the foreseeable future as we beef up our software in this area." - This may need to be updated, or we may be soon approaching the foreseeable future. Kevin 02:18, 26 May 2009 (UTC)

Single member series

I just noticed 25389 which contains only "The Star". To the best of my knowledge there was no sequel to "The Star", nor any other work which might be in a series with it. Is there any reason not to remove this work from the series, and rename the series for reuse? I don't know who created this series of why, presumably someone had a reason at the time. -DES ^Talk 05:11, 22 May 2009 (UTC)

The story was supposedly also published under the title "Star of Bethlehem" although we don't seem to have that variant in the system. Maybe this was an attempt to document the variant title?--swfritter 13:52, 22 May 2009 (UTC)

Development - status update

At this point we have 3 editors with a locally installed version of the ISFDB application: Marty, Bill and myself. I also have the ability to bounce the Web server and the MySQL database if and when they go down.

In theory, I could also use my newly acquired powers to install the changes that Marty and Bill have been working on, but I need to learn more about the installation process before I can do it safely <imagine a 10 year old at the controls of Bolo Mark XXXIII>. I plan to spend the next day or two recovering after a very eventful fortnight, then I will do more digging and check with Al to see if he thinks that I am ready to install a sample fix. I may also need administrator privileges on SourceForge to keep it up to date, but that's a different story. The bottom line is "soon, very soon (hopefully)". Ahasuerus 21:23, 23 May 2009 (UTC)

If you knew my blood-alcohol levels at times of certain updates you might be even more nervous. ;-) BLongley 23:02, 23 May 2009 (UTC)

Oh, so that's what the smell on that chunk of code was! :) But yes, I realize that we all have our quirks and limitations -- and some of them are hard to diagnose remotely. Besides, we need a single "code master", which is why I may well be stuck installing all the updates for a while. Besides, I am lucky: only 2 emergency landings in all my years of wandering. What could possible go wrong?.. Ahasuerus 04:29, 24 May 2009 (UTC)

But I've tried to keep my updates small and uncontroversial, they're mostly changes to displays and will not corrupt any core data. Hopefully they'll give more data to stop moderators approving controversial edits without research, or help all users search better. BLongley 23:02, 23 May 2009 (UTC)

Ahasuerus, please let me know your Sourceforge account name and I can add you. E-mail off list is faster for getting my attention. --Marc Kupper|talk 02:27, 24 May 2009 (UTC)

I would guess, from the people posting bug reports, that he is "ahasuerus_isfdb". BLongley 06:49, 24 May 2009 (UTC)

I have one general comment about making changes to the code which concerns the notes that accompany a change. Some of the current notes don’t give a background on why the code was changed. For example, one of the notes has “bug fix: add missing non-null columns and values to mw_user insertion” and I can see from the diff that an “insert into mw_user(user_name) values('%s')” was changed to “insert into mw_user(user_name,…,user_touched) values('%s', '', …, '')”. From a Python and SQL syntax view I’m fine with this change and it does fill in values that were not filled in before. However, I don’t know how to reproduce whatever problem this is supposed to fix so that I could then verify that it is indeed fixed. As it is, this particular change puzzles me as the table should either already have default values set for columns that need them and/or MySQL will be filling in the field using the implicit default value based on the field type. I’m guessing the repro is to run MySQL in strict mode and in that case the insert will fail and the supplied change will fix that problem.

Thus a better note would have something like “Run MySQL in strict mode and do an xyzzy. You will get a Python error dump as default values were not provided when inserting new rows into mw_user. This change is to add the missing non-null columns and values.” --Marc Kupper|talk 02:27, 24 May 2009 (UTC)

That started from talks here. It seems the difference between strict mode and non-strict mode on the local MySQL implementation may be important. Use non-strict and the script may work. BLongley 06:49, 24 May 2009 (UTC)

Still, it does re-raise the issue of where we should be talking about changes. I've posted on MartyD's talk-page for installation problems, and posted examples of proposed fixes on the Community portal for general changes and Moderator area for Mod-Only changes - I've also added comments to Bugs and Features on Sourceforge. And there's the mod-list emails and some direct emails too. If we aren't going to use the Sourceforge project forums, then one dedicated area here might be appropriate. I don't really want to repeat myself in 3 or more areas. BLongley 06:49, 24 May 2009 (UTC)

The create_user.py change was mine, in response to all three of us running into the same missing value and no default in a non-null column error while following the MySQL set-up instructions. It didn't occur to me to log a formal bug, since it was just a local environment set-up script. I will make sure there's a but or feature request logged for any future changes. As an aside, I can't figure out how to mark bugs fixed, so I may be a bit Tracker impaired.... --MartyD 01:15, 25 May 2009 (UTC)

What if we start a change akin to something like the commonly-used Change Log, where each major section is a "release", with a minor section for each change. The top section would be "Next Release". Once released, it would get renamed to match the release (however we identify them -- date, number, whatever), and we'd start a new "Next Release" section. Changes could be proposed and discussed or simply "announced" (and discussed after the fact), as appropriate. Links could be dropped into other pages to request feedback on specific proposals. I suppose we might have to use sub-pages instead of sections and MediaWiki's "move" function if we wanted to keep those links intact. --MartyD 01:15, 25 May 2009 (UTC)

(unindent) I have been granted enhanced CVS powers (thanks, Marc!) and I am now playing with bug creation/assigning/closing etc. I also found the source files on the "live" server, but they are in one of Al's subdirectories (which explains why I couldn't find them at first!) and I don't want to touch them without first discussing the issue with Al. In the meantime, I am experimenting with installation options under Windows. Hopefully, this week won't be as exhausting as the last two and I'll be able to get more done. Ahasuerus 03:04, 26 May 2009 (UTC)

Changes present on the live site but missing from the source tree on SourceForge have been incorporated into the respective modules in CVS. --MartyD 00:42, 28 May 2009 (UTC)

Kim Harrison vs. Dawn Cook

According to a recent Locus interview, Kim Harrison is the same person as Dawn Cook. Since the Harrison persona is presumably the better known one, I wonder if we want to make it the canonical name? Ahasuerus 01:56, 27 May 2009 (UTC)

Harrison should be the canonical name, IMHO. MHHutchins 03:34, 27 May 2009 (UTC)

I'm regretting all my work on "Paranormal Romance" (or "Chic-Spec-Fic" as I'm inclined to call it - does my dropping a K mean I get to be the originator of a new term?) so would go with whatever's easiest. BLongley 23:24, 27 May 2009 (UTC)

VTs and the Pseudonym association have been set up. Ahasuerus 00:01, 17 July 2009 (UTC)

Signed copies of China Mieville's The City & ytiC ehT

Powell's in Portland will have Mieville signing copies of his new novel on Sunday, June 9. It's getting some very good reviews. You can also pre-order a signed copy (for list price plus 3.95 postage) if you can't be there. MHHutchins 03:49, 27 May 2009 (UTC)

Alisa Kwitney / Sheckley

I just received the second novel by Alisa Sheckley (submitted this), and noticed there is no connection between her two names. She is known as Alisa Kwitney for her novel The Sandman: King of Dreams, and as Alisa Sheckley for The Better to Hold You and her new novel Moonburn. Kwitney is her husband's name, Sheckley her maiden name, and before linking them I was wondering what the canonical name should be. Both Wikipedia and her own website have Kwitney, but since she's Robert Sheckley's daughter, has written mostly mainstream novels as Kwitney, and as Sheckley is writing "paranormal romance" novels, I would prefer Sheckley as the canonical. Any thoughts about this? Willem H. 10:19, 27 May 2009 (UTC)

I prefer Sheckley. BLongley 23:16, 27 May 2009 (UTC)

Sheckley seems to work. Ahasuerus 15:45, 28 May 2009 (UTC)

All votes go to Sheckley, so I started submitting. Thanks Willem H. 08:42, 30 May 2009 (UTC)

Technical issues - Thursday, May 28 2009

Our virtual server was bounced overnight and we are experiencing intermittent loss of connectivity this morning. When a problem occurs, all connection requests time out, but when connectivity is restored, it looks like the Web server and the MySQL server are fine. There is nothing I can do about it at the moment, but I will try to review the log files later today and see if I can find any clues. Ahasuerus 15:43, 28 May 2009 (UTC)

I had similar time-out/connectivity problems a couple different times, spread out over Weds the 27th, primarily during the daylight hours (Say between 8 am and Noon CDT most likely). Because every thing appeared fine once I did reconnect, I assumed the problem was closer to my end than the server end, and I did not make an exact note of the time. Kevin 16:27, 28 May 2009 (UTC)

Will Wikipedia Re-Licensing allow Hot Linking to Wikipedia Images?

I notice that Wikipedia is re-licensing under Creative Commons by Share Alike (CC-BY-SA) on 15 June. Does anyone know if this will allow us to hotlink images from Wikipedia, Wikimedia (As in Authors photographs)? Kevin 03:02, 29 May 2009 (UTC)

Nevermind - I just went and lookup up the linking policy text after asking the question and realized they will probably still restrict that to Wiki-Sister sites, due to the issue of bandwidth theft, etc. Oh well... back into my corner I go. Kevin 03:05, 29 May 2009 (UTC)

However, it now becomes even more likely in any given case that we can download a wikipedia image, and re-upload it here. I have done so in several cases, particularly for author images. -DES ^Talk 14:41, 29 May 2009 (UTC)

AND NOT searches

I am in the middle of testing the software changes that Marty, Bill and Roglo have uploaded to our software repository. One of the things that Bill has fixed is the "AND NOT" Advanced Search so that when you search on, say, "Author (includes) Jo Walton AND NOT Title includes Farthi", you will get a list of all Jo Walton titles that do not include the string "Farthi" in the title. Bill's fix works fine, but it takes a long time to run this kind of search, about 1 minute and 15 seconds on my local server. I assume that MySQL has to traverse the whole Title table and while doing look-ups against the Author table, which can be time consuming. Fir the technically inclined, here is the raw SQL query that is displayed by the software at the top of the search page:

select titles.* from titles,authors,canonical_author where authors.author_canonical like '%Jo Walton%' and authors.author_id=canonical_author.author_id and canonical_author.ca_status=1 and titles.title_id=canonical_author.title_id AND NOT titles.title_title like '%farthi%' order by titles.title_title limit 100

Assuming that we can't improve this query's performance, I wonder if the additional functionality is worth risking a server slowdown while the query is running. If not, then we may want to remove the "AND NOT" option from the Advanced Search page. Ahasuerus 04:10, 30 May 2009 (UTC)

I don't understand how this significantly increases the search time. It should be pulling all records like in a regular search, and then applying the ANDNOT criteria only to that subset. Kevin 04:19, 30 May 2009 (UTC)

I am not sure, but the "AND" version of the search posted above takes 0.47 seconds on my system while the same "AND NOT" search takes 1 minute and 15 seconds, so something must be different. Something to look into on the local development systems before we apply the fix, perhaps? Ahasuerus 04:28, 30 May 2009 (UTC)

P.S. The new "Reviewed Author" search is taking about 12 seconds on my server and Publication search on Cover Artists takes over a minute. I wonder if Bill is seeing similar results? Ahasuerus 04:46, 30 May 2009 (UTC)

The AND NOT example took 41 seconds on my machine the first time, but subsequent queries with different data then take about 13 seconds, so it's caching something about the tables/columns (and going back to the same original query is instantaneous). The "%x%" form of a text match is worst, since it will always scan the entire table (defeats indexing). AND NOT should not perform any differently than AND in this situation -- each has to do the same amount of work. Also, if you ran the AND NOT, you cannot then run the AND and compare, as it benefits from whatever was cached from the run of the AND NOT. --MartyD 10:46, 30 May 2009 (UTC)

On my ancient machine the query above takes about 2 min 50 sec (after a few runs, but not much difference between them) and the following one:

select * from (select t1.* from titles t1,authors,canonical_author where authors.author_canonical like '%Jo Walton%' and authors.author_id=canonical_author.author_id and canonical_author.ca_status=1 and t1.title_id=canonical_author.title_id) as t2 where NOT t2.title_title like '%farthi%' order by t2.title_title limit 100;

takes under 9 sec. --Roglo 11:08, 30 May 2009 (UTC)

Unfortunately my local configuration doesn't behave anything like the live server. E.g. A Title search for an Author of "Terry Pratchett" doesn't even complete locally, whereas it does (slowly) on the live server. The new Reviewed Author search works much better though. My Publication Search works about the same as you seem to be getting. BLongley 12:38, 30 May 2009 (UTC)

My results (the second query is from the new Advanced Search pp_search.cgi):

mysql> select distinct pubs.* from pubs, pub_content pc, canonical_author ca, titles t, authors a where pc.title_id=ca.title_id and ca.title_id=t.title_id and ca.author_id=a.author_id and t.title_ttype='COVERART' and a.author_canonical LIKE '%Embden%' and pc.pub_id = pubs.pub_id order by pubs.pub_title limit 100 ;

10 rows in set (2.42 sec)

mysql> select pubs.* from pubs where pubs.pub_id in (select pc.pub_id from pub_content pc, canonical_author ca, titles t, authors a where pc.title_id=ca.title_id and ca.title_id=t.title_id and ca.author_id=a.author_id and t.title_ttype='COVERART' and a.author_canonical LIKE '%Embden%') order by pubs.pub_title limit 100 ;

10 rows in set (10.69 sec)

On my machine EXPLAIN shows that the first query first finds titles with t.title_ttype='COVERART' but the second one does a full scan of pubs. --Roglo 13:35, 30 May 2009 (UTC)

"IN" often will not perform well, as it will usually execute the sub-query, then correlate the outer result against it. Here, with no criteria in the outer selection, it will be the whole table. This example would be better off written as a join:

mysql> select distinct p.* from pubs p, pub_content pc, canonical_author ca, titles t, authors a where p.pub_id = pc.pub_id and pc.title_id = ca.title_id and ca.title_id = t.title_id and ca.author_id = a.author_id and t.title_ttype = 'COVERART' and a.author_canonical LIKE '%Embden%' order by p.pub_title limit 100;

The AND NOT case is more difficult. Looks like the optimizer is deciding to do a scan of titles, which is relatively big, rather than considering only the restricted set of titles for the matching author(s). --MartyD 16:25, 30 May 2009 (UTC)

select titles.* from titles,authors,canonical_author USE INDEX(authors) where authors.author_canonical like '%Jo Walton%' and authors.author_id=canonical_author.author_id and canonical_author.ca_status=1 and titles.title_id=canonical_author.title_id AND NOT titles.title_title like '%farthi%' order by titles.title_title limit 100 ;

16 rows in set (0.10 sec). Now I'm happy with the search time :) --Roglo 16:48, 30 May 2009 (UTC)

It took 0.88 seconds the first time around (and 0.06-0.10 seconds on subsequent runs), but it's a huge improvement - thanks! Ahasuerus 17:00, 30 May 2009 (UTC)

P.S. But keep in mind that the Advanced Search page supports various permutations of search values, so we may have to examine which indexes are best used for each one and construct different query strings for them. However, as long as we cover the most likely searches, I think we should be able to release the AND NOT functionality into the wild and improve the performance of other searches later. (So much for it being a trivial fix! :-) Ahasuerus 17:23, 30 May 2009 (UTC)

The USE INDEX fix above is really related to the search by author, because it allows us to limit the amount of titles that should be scanned. It makes Advanced Title Search by Author usable, so I will try to test it a little, and commit it unless someone stops me :) --Roglo 18:23, 30 May 2009 (UTC)

I added Feature Request 2798917 ISFDB Advanced Search queries faster. --Roglo 19:23, 30 May 2009 (UTC)

I think we need smaller, more specific bug reports or feature requests. There's 3 sections of advanced search, all with their own problems. All I've done is enable the broken functions and added one more that was requested. So we've got Title Search with 5 options, possibly multiplied by 3 conditions and 5 options, and maybe another 3 conditions and 5 options. (Make those 6 options if you like the Reviewed Author addition.) Author Search: 6 by 3 by 6 by 3 by 6. Publication Search: 11 by 3 by 11 by 3 by 11, if you accept my fixes. There's several thousand combinations to look at and constructing the perfect query for each would be impossible. So I can understand possibly banning some searches. Or restricting some. Or changing some - "Begins with" searches are much more likely to use an index than "Contains". The more characters put into a search the more likely it is to yield a small set of results, we could demand a minimum length of characters in a search field. Or ban the pointless - nobody has managed to get a Back-Cover Artist into the database yet, so searching on such is pointless at the moment even though I've enabled it. Is preventing server-crippling searches a priority? If so, we need to address what anyone can currently do before enabling anything else. BLongley 23:56, 30 May 2009 (UTC)

Yes, this is getting somewhat hairy. I was hoping to use the Advanced Search issues as our first guinea pig to be applied to the live server, but they may be getting a little too big for that. I'll try to use your "Show present Pseudonym relationships at approval" change (yv_new.py) instead. Ahasuerus 00:53, 31 May 2009 (UTC)

Display changes might be less controversial, and I'm glad that one looks useful. Cover image previews would be my choice given current activity, but if we're going in small steps then it's up to you. BLongley 01:07, 31 May 2009 (UTC)

Ron Miller

We were just visited by Ron Miller, or at least apparently so. See Author:Ron Miller, Bio:Ron Miller, and Bio:Ron Miller/Pubs. This last is a temp page I created to hold the bibliography which does not belong on the Bio page. I am going to attempt to enter some if not all of the publications listed (excluding things clearly out of scope like journal articles), as I believe Ron Miller is well over the "certain threshold" mentioned in the RoA. Provided, that is, i can find useful online confirmation and sources for the needed data, perhaps in OCLC or Amazon. I am also going to put a note on his user page trying to tactfully explain what I am doing.

I welcome input from any of you as to whether I am handling this situation properly, and any help anyone likes to give in getting the relevant stuff from this biblio in to the DB proper. -DES ^Talk 04:35, 30 May 2009 (UTC)

Sounds like an eminently reasonable approach to me! Ahasuerus 04:47, 30 May 2009 (UTC)

The Jungle Book

I would have thought Kipling's The Jungle Book out of scope, but I see Fixer has submitted selections from it, and we have three publications on file, one verified. Of course, if this is in, there have been dozens if not hundreds of editions, with many printings. Probably as many as The Lord of the Rings. Should this be in? -DES ^Talk 14:46, 30 May 2009 (UTC)

A child raised in the jungle by its inhabitants to whom he speaks, told through stories in which the boy grows and matures through lessons learned. Wouldn't the speaking animals be enough for it to be speculative fiction? Think of Animal Farm, Watership Down, The Secret of NIMH, the works of E. B. White and literally hundreds of more titles that would be excluded if The Jungle Book doesn't qualify. Consider The Graveyard Book: a child raised in a graveyard by its inhabitants to whom he speaks, told through stories in which the boy grows and matures through lessons learned. Would the latter being ghosts make it more speculative? MHHutchins 15:16, 30 May 2009 (UTC)

I think DES may be referring to the line in Rules of Acquisition which reads "Speculative fiction is defined to exclude: ... Animal books for very young children (?)". The original intent was to exclude short (typically 6-20pp or so) books for preschoolers that depict simple scenes from animal life featuring anthropomorphized animals. Kipling's work is certainly well above that threshold, but the policy implications are that we may want to clarify the RoA. Ahasuerus 15:58, 30 May 2009 (UTC)

Yes I was thinking of the RoA, and somehow I just don't think of TJB as SF, but I see your point. In it is. -DES ^Talk 19:09, 30 May 2009 (UTC)

And I will add the explanation of the original intent to the RoA. Ahasuerus 20:58, 30 May 2009 (UTC)

Marc immediately clicks to make sure James and the Giant Peach is in ISFDB. I agree though that sometimes the line is fuzzy. Another edge are some futuristic military technothrillers. I'm reading Black Star Rising (Amazon.com 0451220145) where much of the action is centered around stealth fighters that are visually invisible. While the book is touted for it's realistic naval fighter life and flying it also gets more into specfict than the average technothriller as it discusses consequences for when completely invisible fighters get into dog fights, changes in attack and defense strategy, etc. --Marc Kupper|talk 08:22, 31 May 2009 (UTC)

Another edge case: Orbit by John J. Namce. Nance has mostly written aviation thrillers sort of in the Airport vein, but better written and wider-scoped. However, this one deals with a malfunction aboard a private space ship, something a litlte like the next stage of the RL SpaceShip One project. The tone is much like an aviation technothriller, and the tech only a litlte beyond current off-the-shelf tech. Probably Out, but soemhow i think it would appeal to many SF fans, and would like to make it In. —The preceding unsigned comment was added by DESiegel60 (talk • contribs) .

I think, (unfortunately) even in 2009, any plot synopsis which includes the phrase "Private Space Ship" would most definitely be 'In'. I look forward to the day when the Novelization of 'Snakes on a Space Ship', is 'Out' as a Ho-Hum Thriller, but we aren't there yet. Kevin 18:05, 31 May 2009 (UTC)

Concur with Kevin. Ahasuerus 18:36, 31 May 2009 (UTC)

Fine, I'll add it. i was thinkign of the RoA excluding TechnoThriller "Tommorow Fiction". I have the books so i can do a primary verify. -DES ^Talk 19:14, 31 May 2009 (UTC)

Programmer Development Page

Do we need one?--swfritter 16:49, 30 May 2009 (UTC)

I am sure the answer to this question is either "Yes!" or "Hell, yes!" :-)

The second question is whether we want to set one up here or whether we want to use the forums on Sourceforge.

The third question is how can we tell whether an issue is purely technical or whether it requires a community-wide discussion. For example, when I started the AND NOT topic above, I was thinking in terms of "impact on system performance vs. additional functionality" trade-offs and not about a technical solution to the performance issue. I guess we can always start a technical discussion on the technical forum/page and then move it here if we find policy implications (and vice versa.) Ahasuerus 17:09, 30 May 2009 (UTC)

Perhaps the technical issues could be in the programming area until a concise impact statement could go on the Community Portal. We are all, of course, experts at concise statement. Perhaps I should expand upon that idea . . . Oops, sorry the mail just came.--swfritter 21:40, 30 May 2009 (UTC)

"Possibly cripple the server" to "Add functionality" versus "just leave the purple Python problems when we're trying the silly options" should of course be discussable options for all users. Whether we can keep the techie stuff on Sourceforge is another matter - we need to break down the problems expressed here ("make stuff faster") into smaller chunks, but Sourceforge isn't (AFAICS) doing well at keeping needed coordinated changes together. Typically, a search covers two modules for the initial search and further pages. An additional search option covers three modules. A display issue may cover 10 modules. (E.g. I hate "unpaginatedpp" displays when a "0" for page count suppresses that in many other areas, but some people want to enter "unpaginated" in full and have the software deal with it.) "Impact statements" will only be as good as the knowledge of the proposing impacter - and we're just getting to the stage where even Al won't know the impact. BLongley 00:10, 31 May 2009 (UTC)

Re: tracking changes. I haven't found an easy way to find all related changes at Sourceforge (yet) except by checking comments and hoping that the developer remembered to identify all affected Python scripts. Is there a way to associate bugs and changed Python scripts, preferably including their revision number? If there is none, then we may want to either use the Sourceforge ISFDB Developers forum or start a Wiki page which would have a list/table of all current bugs and features that we are currently working on with the following columns: (A) developer, (B) tester, (C) a list of Python scripts affected and their CVS versions, (D) current status, i.e. development or test, and ETA, (E) known conflicts and dependencies, etc. It all seems so basic that I find it hard to believe that Sourceforge doesn't support something similar. Am I missing some obvious area? Ahasuerus 01:16, 31 May 2009 (UTC)

(unindent) Development has been created and a proposed "ISFDB patch process" has been posted. Ahasuerus 05:04, 31 May 2009 (UTC)

Link from submisison page to wiki

To those now doing development:

How much trouble would it be to add a message to the page displayed after a submission -- the one that shows the XML submitted -- that says something like:

"Your submission must be approved by a moderator before it enters the database. If the moderator has questions or comments about your submission, they will be posted on http://www.isfdb.org/wiki/index.php/User_talk:<Poster's User ID Here>. Please check your wiki talk page for comments or questions."

It seems just too easy for new people to find the ISFDB but not visit the wiki, and rejecting subs to put a note in the reject reason is a bit of a kludge, and may not work in all cases anyway. -DES ^Talk 21:32, 30 May 2009 (UTC)

Not too difficult, but it's needed on about 20 submission types. Some of which aren't yet available officially. Do people actually read the XML anyway until they get to the Mod stage? (I suspect some don't even then - but I usually read it to see when an author is being added or deleted unexpectedly, for instance.) BLongley 00:18, 31 May 2009 (UTC)

If we make the font big enough, they will be forced to read it sooner or later :) Ahasuerus 00:54, 31 May 2009 (UTC)

Frankly I'm not at all sure most people, even most mods, really need the XML -- I would favor a page that displays the change to be made in a more human readable form, confirming what the editor has just submitted, ideally with am option to cancel the change if the editor realizes that an awful error has just been made. But I think the link is more urgent than that ideal situation, and if added now, could be retained if and when the XML is changed to something else. In any case I would suggest putting the new link (if implemented) above the XML. Even if this is added to a few if the most common submission types, such as new pub and update pub, the ones newcomers are most likely to submit, it might help a lot. -DES ^Talk 03:22, 31 May 2009 (UTC)

I never look at the XML when submitting things but probably would notice if something extraordinary happened in it. It's fine with me if it goes away as I use the XML dumper far more often. --Marc Kupper|talk 07:57, 31 May 2009 (UTC)

OK, change to edit/submitnewpub.py committed. If that looks like a big enough pointer, we can roll it out to the other types. If not: we can make the message bigger, brighter, more threatening... ;-) BLongley 11:29, 31 May 2009 (UTC)

What would be VERY nice would be an obvious notice in the main ISFDB views or nav menu that something new has been added to your talk page, along with a link to that page. Not only is it currently too easy to not know about your talk page at all, it's also pretty easy to forget to check your talk page until you've developed the habit of watching both the Wiki and the database. If that's too hard, I suggest a link to the talk page in the My Pending Edits view. There is no visibility into the fact that a pending edit is on hold, why it is on hold, or where to look for more information about it when it pends and pends and never comes out of pending. --MartyD 11:57, 31 May 2009 (UTC)

This functionality was requested a long time ago, which prompted Al to look into it. He said that doing that kind of Wiki look-up was non-trivial or at least beyond his understanding of the Wiki software at the time, so it would have required a fair amount of digging. If you know how to do this using the current version of the Wiki, more power to you! :) Ahasuerus 14:12, 31 May 2009 (UTC)

Kev's just submitted feature request 2799074 (Add Column 'Status' to 'My Pending Edits') so the link to talk pages could be added at the same time. I think it should also appear on "My Rejected Edits". BLongley 15:45, 31 May 2009 (UTC)

Change for 2799074 committed, test away. BLongley 17:53, 31 May 2009 (UTC)

Held by looks nice. Interestingly, it links to my local server but the check your talk page links has isfdb.org hardcoded. Just so you know someone is testing your patch ;) --Roglo 18:39, 31 May 2009 (UTC)

Good point, that should probably be derived from one of the localdefs variables. I just used what DES suggested for now. BLongley 19:11, 31 May 2009 (UTC)

Actually, despite the needed improvement to my fix, I don't think we're going to be changing our website address anytime soon and check your talk page seems urgently needed. We've recently had to reject edits from JLochhas and RLCalvin to get their attention, and I'm sure we've lost a lot of editors along the way. This could be a desirable, safe, tested (have you finished testing?) option if Ahasuerus wants to try a small change first. Even if it did go wrong it wouldn't really affect the mods. ;-) BLongley 19:50, 1 June 2009 (UTC)

Of course, if we're not freezing and not deploying soon, the improvement could be added quickly too. BLongley 19:54, 1 June 2009 (UTC)

(Unindent) Hopefully you've all noticed "Your submission must be approved by a moderator before it enters the database" message now, and the talk page link, for "new pub" submissions - does the text need reworking, or can we roll it out to other submission types now? (If so, which need it most urgently?) BLongley 22:50, 14 June 2009 (UTC)

It looks OK and I think it's ready to be propagated, but we may want to put this warning into a central place rather than 10-20 different scripts so that we could easily change it later. Ahasuerus 23:01, 14 June 2009 (UTC)

I like it. I think it will help. And it definitely should be everywhere (seconding Ahasuerus' comment that it should be centralized). One thing I noticed, though, is that it almost seems like an error message. No big deal for seasoned veterans, but a newcomer might be scared by it. I suggest rewording it to be a little softer. Something like: Your submission has been queued for review by a moderator before it enters the database. or Your submission will be reviewed by a moderator before it enters the database. I don't know if anyone else had the same reaction, so don't mind me if I'm in the minority. --MartyD 02:13, 15 June 2009 (UTC)

Come to think of it, "must be approved" does sound a little too "martinetish". "Your submissions will be reviewed by a moderator before it is included in the database", perhaps? Ahasuerus 03:10, 15 June 2009 (UTC)

First patch going live tonight

We will be installing a small, experimental patch on the live server tonight. The patch tag is "r2009-01". The following two features will be implemented as per the Development page:

• 2799069. Link from submission page to wiki [for "New Pub" only].
• 2799066. Show present Pseudonym relationships at approval [moderators only, naturally].

With luck, the installation process will be uneventful and the users won't notice anything (fingers crossed.) I will post again once the new functionality becomes available. Ahasuerus 18:13, 4 June 2009 (UTC)

Ooh, I'm excited now! What time is this happening? Do I have to stay up late to watch? Or should I get up early tomorrow to see how it went? BLongley 18:40, 4 June 2009 (UTC)

No real need to. If you wake up in the middle of the night because the moon is really REALLY bright, you'll know that it didn't go well. (Hey, if Stephen can reference Dinosaur Beach, I should be allowed to allude to Inconstant Moon!) Ahasuerus 19:18, 4 June 2009 (UTC)

OK, so long as you keep an eye on the Klystron generator we should be fine. If it overloads, don't reverse polarity, just use a bobby-pin to wangle the potrzebie. BLongley 19:58, 4 June 2009 (UTC)

Oh, I wouldn't dream of reversing polarity, it never works! (And I expect to install the patch some time around 9pm Eastern, i.e. 2am British summer time.) Ahasuerus 20:42, 4 June 2009 (UTC)

I'm definitely not staying up then. I might get up early to see if you've combined my DNA with that of a fly or suchlike, but even if you did, what could I do but buzz off? (Goes to bed, wondering if he's got a new Pub or Pseudonym to add for testing purposes...) BLongley 21:36, 4 June 2009 (UTC)

(unindent) Patch installed, new functionality confirmed, everything looks OK :-) Please report any problems/issues here. If everything goes smoothly and there are no issues, we should be able to start rolling out more fixes over the weekend. Ahasuerus 00:52, 5 June 2009 (UTC)

Tried it under another name and it looks good, but it doesn't appear on the "Edit This Pub" and "Clone This Pub" will these be added? I assume there is no need to have this appear for any moderator submissions. The pseudonym message looks good and should come in handy for approvals.Kraang 01:29, 5 June 2009 (UTC)

Yes, other submission types will be enhanced soon. We just wanted to deploy something small first, something that we could easily back out of things went wrong. Now that we have proved that we can make small changes successfully, we can start making bigger/more extensive changes. Ahasuerus 03:18, 5 June 2009 (UTC)

Looks good to me. I note that it does appear for submissions under a moderator account, probably simpler not to have to check the user rights, and lets us see what new users see. On to other submission types and other changes! -DES ^Talk 17:22, 5 June 2009 (UTC)

What to Implement Next

Glad this went well. What's next? Do we develop the "Link from submission page to wiki" for other submission types? Suppress the message for Mods? Add more links from submitted edits to things that mods find difficult to check? There's a lot of stuff awaiting testing, and even more awaiting coding, so some more guidance is welcome. BLongley 19:57, 5 June 2009 (UTC)

I see no point in spending development effort to suppress this msg for mods. It may even be a handy link for some, and even when unneeded, does no harm. Why complicate the code? Adding this msg for at least the other common submission types seems like a good idea to me. More mod-helpful links does likewise. There are many useful things on the Feature request list. -DES ^Talk 20:08, 5 June 2009 (UTC)

Yes, I guess what I'm looking for is a communal effort to guide the developers and testers into 1) what is most urgently wanted and 2) will be supported through to implementation. The Feature request list here still includes requests from May 2006, before they opened editing to pesky controversial people like me and you. Closing off some of those would help, although I guess asking the submitters individually to review their old requests would be fairly simple, even if it annoys people that silently supported such feature requests. They can always be re-raised. I just want some idea of our direction before I go do anything big. BLongley 20:32, 5 June 2009 (UTC)

I have, as you know, been going through the on-wiki features list a bit, and cloning some on source forge. Some of those requested features from 2006 still look like good ideas to me. I agree that some prioritization and consensus is needed, although in an open source project, ultimately nothing happens unless a particular developer cares enough to work on the change. I think Ahasuerus's suggestion below is good, although something like a formal voting process on the desirability of a given change may be needed in some cases. -DES ^Talk 20:46, 5 June 2009 (UTC)

[Originally posted on the Development Talk page in response to Bill's question about policies, procedures and prioritization]

In the past, Al was the one who knew the most about the application and he also served as the guardian of database/application integrity, so he was effectively our benevolent dictator. For example, there was once a request to enable automatic deletion of Title records when the last Publication for that record was deleted. Al flatly refused to implement it because he thought that it was too dangerous. Ahasuerus 20:28, 5 June 2009 (UTC)

I can understand that, there's often a good reason for a title to stay (Tuck swears it exists, etc) even if our only publication is bogus and needs deletion. Maybe a "Delete title and all publications" for review by a moderator would be better - there's many manga and RPG entries where I'd like the deletion process to be easier, but automatic looks too risky to me too. We can work on other checks as well - "a title cannot be deleted if an award links to it, or if it has been verified, or reviewed, or <FITB reason>". BLongley 21:45, 5 June 2009 (UTC)

I have often thought about this ability (especially when mass slaughtering innocent RPG accessories), but, unfortunately, it could be easily abused when the potential victim is anything but a straight "NOVEL/NOVEL" pair. Imagine deleting a short fiction Title which is embedded in half a dozen anthologies and losing all of them! Perhaps we could allow it if and only if the Title is (a) a Novel and is (b) linked to one and only one Novel pub, which contains no other Titles (i.e. no introductions etc) ? Ahasuerus 23:36, 5 June 2009 (UTC)

I don't think we have anyone in a similar position at the moment, so we will have to make these decisions by consensus, just like we make policy decisions. If we can't reach a consensus, we will shelve the proposal. There will be one big difference, though: those of us involved with development will be the ones deciding what is and what isn't safe to implement since the rest of the team won't be in a position to judge. Again, if there is no consensus, we will shelve the proposed change since it's much better to be safe than sorry. Ahasuerus 20:28, 5 June 2009 (UTC)

I will be administering the installation process for now, so I will be deciding when things go live based on version conflicts, testing schedules, my availability, etc, but it won't affect what ultimately gets deployed. Ahasuerus 20:28, 5 June 2009 (UTC)

I think this makes you the "benevolent dictator" for now. I'm fine with that (you seem cautious enough) but I'd like to see some visibility of the decision process (who you're listening to, who you trust to test if you're not doing that alone yourself, etc.) BLongley 21:45, 5 June 2009 (UTC)

The Benevolent Dictatorship model seems to work quite well for some types of all volunteer projects, but it requires the BD to be extremely knowledgeable while I don't have the kind of knowledge of the software side of the project that Al does. I suppose I would try to veto some really off the wall idea, e.g. a request to mass delete all non-verified Pub, but as long as we operate by consensus, a request like that would generate enough opposition to kill it anyway. And if it didn't, we would have much bigger problems :) Ahasuerus 23:36, 5 June 2009 (UTC)

Another issues with the BD model is that the BD-du-jour can easily become the primary bottleneck if his availability declines or if is unable to delegate/manage effectively. At the moment we have a few active developers (Roglo is on a 2 week break, but he will be back) and no testers/admins/installers except me, so I suspect that I may become the next bottleneck. If that happens, we may have to ask the development crew to start dong more cross-testing even though testing is not as much fun as developing. Ahasuerus 23:47, 5 June 2009 (UTC)

Prioritization is a different can of worms. First, there are technical considerations, e.g. r2009-02 will contain 3 (and only 3) sets of changes because we need to get the live server in sync with the Sourceforge repository before we do anything else. Second, we are still getting out feet (tentacles, etc) wet, so we probably want to go for the easy-to-implement low hanging fruit. Once we are confident that we can handle bigger fish, we may want to do a poll on the Community Portal. Of course, major changes like implementing an Award editor or removing the lexical match logic for Serials could lead to revision conflict, so we will have to plan that part carefully. Ahasuerus 20:28, 5 June 2009 (UTC)

Yes, there's some big projects requested and there's still plenty of small changes we can get by with for now. More testers, and more developers still wanted, but eventually we'll want some project managers (maybe even program managers). They're a necessary evil in the long run, I've found. I'm looking ahead a bit, I know - but I can foresee times when user "MysticMeg" spends ages making sure that an author and reviewer have their star signs checked for compatibility before we'll accept a review as impartial, and hopefully that sort of thing can be stopped before development starts. (If people really want such a feature, shoot me now.) That's a long way off I hope, but there's lots of low-hanging fruit that can be addressed but need discussion - e.g. links to talk pages. Do we want editors to know which mod is holding their edit and give them an easy way to harangue them before we give the mod a chance to UN-hold the edit? BLongley 21:45, 5 June 2009 (UTC)

Assuming that wasn't a joke, i for one do want editors to know who holds any given edit. Anytime any non-mod editor has asked about that, i have responded with a link to the holding editor's talk page. I don't think it has happened more than 3 or 4 times since I've been a mod. IMO anything that facilitates communication between mod and editor is a Goo Thing^TM. -DES ^Talk 12:06, 6 June 2009 (UTC)

No joke: such a link has been developed. (Feature 2799074.) However, the lack of ability to unhold means a moderator can't hold a submission for investigation, run out of time or patience, and unhold it for another mod to look at. Or maybe a moderator should be able to assign the hold to another mod - e.g. people keep holding edits to my pubs for me to look at. I'm sure they don't want to be flooded with complaints because I haven't approved it yet but they did the original hold. So while the feature should go in, there may be other features that should be done first to minimise annoyance. BLongley 12:29, 6 June 2009 (UTC)

Good Idea. Feature Request #2802260 submitted for FLAGged submissions to assign a submission for review of a different MOD. Kevin 14:45, 6 June 2009 (UTC)

I agree that some structure will probably be needed, managers of some sort. But it is early days yet, and we will see what, er develops, naturally. -DES ^Talk 12:06, 6 June 2009 (UTC)

There are different ways to structure and administer an open source project (see the article linked above), but first we need to figure out how many developers we will have. If DES, Swfritter, Wim Lewis and Marc all get their systems going, the total number of people with development access will approach 10 and at that point we may need more structure. Ahasuerus 23:47, 5 June 2009 (UTC)

Embedded HTML in notes

My own opinion is that it is not wise for many reasons. But if we are going to allow it I would really like to see a set of standards for what is allowable, a tutorial, and some copy-paste templates. Expecting HTML literacy is not the best way to attract new editors.--swfritter 14:23, 6 June 2009 (UTC)

I don't think it is ever requited. I think a limited set of HTML should be allowed and an even more limited set should be encouraged. In the encouraged list I would put br tags for breaking up lists into visible lines, i tags for italicizing titles, and a tags for embeddign links to other sites -- some of the latter are already documented for specalixed cases. I would include in the "allowd but not particularly encouraged" category ul/li tags to make bulleted lists. I would be happy to write up a brief primer/help page that covered these forms. Does anyone have other tags that should be included, or serious objec tions to any of the above. (I have used all of the above and see no reason not to do so. Most editors seem to use either br or ul/li tags routinely.) -DES ^Talk 21:56, 6 June 2009 (UTC)

If an editor needs to update the notes for a pub that has HTML tags then the knowledge is required. I have at times avoided updating notes with HTML tags; although I can figure them out I am not all that fluent in their use. I specifically think italicizing and underlining items is not necessary.--swfritter 23:10, 6 June 2009 (UTC)

Tags for italics are not necessary, but IMO are highly desirable. (I don't see much reason for underlines.) They are also very simple and pretty obvious in context, even to some one who knows no HTML, I think. It is pretty much always OK for an editor to simply remove the HTML, IMO.

Would a basic help page on the few HTML tags that seem reasonable for the ISFDB be useful to you? Should i go ahead with creating one? -DES ^Talk 23:15, 6 June 2009 (UTC)

One of the issues with HTML is that improperly formed HTML can make a submission unapprovable. We may want to create a feature request to beef up HTML validation in submissions first. Ahasuerus 23:44, 6 June 2009 (UTC)

I'd support the validation feature, and suggest we implement that before any sort of extra encouragement to enter HTML. The one that really breaks us is one that at first glance would be entirely innocuous. I suspect people will still want to enter anchor tags to other sites though (coverart images for the other side of a dos-a-dos book, Gutenberg downloads, free audiobooks or samples, interviews etc), and that might need a whitelist of some sort. But we could use that for valid coverart sites too, so it might help us in the long run anyway. BLongley 23:55, 6 June 2009 (UTC)

Yes, a Help page with examples possibly even as part of pub Help; a defined number of tags that are allowable; a larger edit screen for notes so I can see the tag pairs.--swfritter 00:45, 7 June 2009 (UTC)

I might have mentioned this elsewhere so forgive me if I repeat myself: but I recently tidied up 120 notes where we didn't even have matching levels of "<" and ">". About half of those made lines of notes invisible: e.g. one editor seems to enter "<br." quite often and another "<li<". I imagine there's plenty more examples where the numbers of "<" and ">" match but there's a missing "/" on close tags (which is usually less important as it doesn't hide data, just makes following data look funny). We can make some simple software improvements to warn people about this at submission or at approval level if we can agree the limits. If we allow too much, then finding a proper HTML editor/validator plugin would be better though. BLongley 22:24, 14 June 2009 (UTC)

Cover art supplied by ...

Moved to ISFDB:Proposed Interface Changes#Cover art supplied by ...

Series parent display

Moved to ISFDB:Proposed Interface Changes#Series parent display -DES ^Talk 05:56, 14 June 2009 (UTC)

Patch r2009-02

Patch r2009-02 has been put together and is currently in the middle of testing on my local server. If everything goes well, it will be deployed on Sunday. (See the Development page for technical details.) The following bugs and feature requests will be addressed:

• Bugs 1956355, 1961441, 1966177. Empty series are displayed on the main Biblio page and Titles are displayed in a wrong chronological order. Also addresses the request to add Nongenre Series and Short Series displays to the Biblio page.
• Bugs 2137453, 2271738. Pubs with ISBN13 do not get proper Amazon links (which need ISBN10 instead).
• Bug 1987739. 8888-00-00 is not converted to "unpublished" in various places.

In addition, the live server will be reconciled with our source code repository on Sourceforge, which makes it a particularly tricky patch and prevents us from deploying anything else in addition to the changes listed above. Ahasuerus 05:29, 7 June 2009 (UTC)

Testing likely delayed since the tester is recovering from an encounter with ruffian bacteria. To quote my favorite Troll, "undercooking hobbits is a primary cause of indigestion". Ahasuerus 19:58, 7 June 2009 (UTC)

Patch r2009-02 is now live. Henry Kuttner, Brian W. Aldiss, James Patterson, Philip Francis Nowlan, Charles de Lint and others will be happy to showcase the new "Short Fiction Series" and "Non-genre Series" functionality as well as other improvements. We may want to tweak some of the new codes, e.g. [SERIAL], but the core of the new functionality is hopefully solid. The ISBN-13 fix also made it and so did the 8888-00-00 fix (and 9999-00-00 for "forthcoming"), although Marty later found a couple more places where 8888-00-00 still needs to be fixed. Please report any problems here.

Most importantly, the main (aka "live") server is now fully synchronized with the Sourceforge repository, which greatly reduces the probability of Bad Things (tm) happening.

P.S. I will start working on r2009-03 tomorrow. Ahasuerus 03:20, 8 June 2009 (UTC)

Code already exists to display credit for bestsf.net

Code already exists live on the server to display a credit for BestSF, see Interzone April 1998. Currently 46 publication records hot link and credit images from Best SF. It appears that the editor of that site Mark Watson was working on the ISFDB back in early 2005 What's_New_from_2005#What.27s_New_-_18_Jan_2005. Should we remove this code? Should we contact bestsf.net for permission? Is permission already documented somewhere? Is the permission implied (by our what's new history that Mark was test ISFDB2? Thanks Kevin 00:03, 8 June 2009 (UTC)

As I recall, Mark was one of the people helping Al with the ISFDB-to-ISFDB2 conversion and related activities, but it was a while back and I don't think he has been involved since at least early 2006, so we probably want to ask his permission. As Jerry Lewis once said, safety first ;-) Ahasuerus 03:28, 8 June 2009 (UTC)

Permission Request Email sent, with CC to isfdb.moderators@gmail.com address. Kevin 03:21, 9 June 2009 (UTC)

Minor Navbar Changes Proposed - Edit Author, Show All Titles, Magazines and More

Moved to ISFDB:Proposed Interface Changes#Minor Navbar Changes Proposed - Edit Author, Show All Titles, Magazines and More -DES ^Talk 02:30, 14 June 2009 (UTC)

Searching by ISBN behavior

For an ongoing discussion of the nature of ISBNs, Catalog IDs, and other identifiers, see Rules_and_standards_discussions#Dealing_with_Bad_ISBNs (and also Rules_and_standards_discussions#Formatting_ISSN_numbers).

I noticed while testing some recent changes that searching by ISBN does not behave as one (well, "I") might expect. I'm seeking opinions about how search should behave AS ISBNs ARE CURRENT IMPLEMENTED before logging a bug. Please use the appropriate discussion above for general ISBN and Catalog ID comments and ideas.

Example 1: Two pubs sharing the same ISBN pair, one entered with ISBN-10, the other entered with ISBN-13. You can't tell from the pub displays, as both show the same numbers, but the title display shows the difference. Searching by ISBN for 0-441-01547-6 finds one record, and searching by ISBN for 978-0-441-01547-4 finds the other record. Do we expect either should find both?

Example 2a: In the example above, searching by 0-441-01547-6 or 0441015476 (or by 978-0-441-01547-4 or 9780441015474) produces the same result. Consider A Touch of Sturgeon (showing ISBN-10 of 0-671-65526-4 and ISBN-13 of 978-0-671-65526-6). It was entered with an ISBN-10, yet searching by ISBN for 0-671-65526-4 or 0671655264 produces no results. Searching by ISBN for 0%671%65526%4, however, finds it. This is because the ISBN was entered and stored with the hyphens, but ISBN searching normalizes search strings to remove dashes and spaces from valid ISBNs. Do we expect this should have been found using any of the three search strings?

Example 2b: Before someone goes and fixes this one, consider Dragon Magazine #246. Note the bad checksum on its ISBN 978-0-7869-0810-9 (and also a lack of ISBN-10 in the display). Searching by ISBN for 978-0-7869-0810-9 finds it, but searching by ISBN for 9780786908109 does not. Do we expect that it should?

My feeling is that since ISBN 10s and ISBN 13s are shown together, often on books and almost always in the Publication display, searching by ISBN for either value should find all publications, even those entered using the other value. And since dash-or-space punctuation is semi-optional, the search should produce the same results whether the search term includes dashes-or-spaces or not, whether the underlying record is dash-or-space punctuated or not, even if the ISBN has a checksum error. But some of that thinking flies in the face of looking for "exactly as recorded", so I figured I'd see what other people think. Thanks. --MartyD 10:50, 9 June 2009 (UTC)

I tend to agree. IMO valid ISBNs should ideally always be stored without embedded hyphens or or spaces, and a search with a valid ISBN (i.e. one with a checksum that passes) should be searched for in both ISBN-10 and the corresponding ISBN-13 format. I'm less sure what should be done about ISBNs currently stored with hyphens, particularly since they can have them placed incorrectly. removing hyphens (or spaces) from every search target might be prohibitive in perform ace terms (if it isn't, doing this would be ideal, and allow storage "as printed"). Perhaps a data-change script to remove existing hyphens would be needed. Note that I do not think that an invalid ISBN should be converted to the alternate form.

However, before you log a bug, I think this is really an enhancement (feature) request. What is happening now is basic string comparison. What we want is a smarter search, and i hope this won't be too complex to implement, but I think this is,m in effect, as design change (albeit a design that was never publicly documented). So call it a feature, but hope for early implementation, is my view. -DES ^Talk 12:04, 9 June 2009 (UTC)

Personally, if I wanted to find both records in one go I just wouldn't put the ISBN-13 prefix or the check-digit in. 0-441-01547-6 will never match 978-0-441-01547-4, so just search on the common part 044101547. This may not be intuitive to all users but education in the ways of the check-digit would help. BLongley 17:32, 9 June 2009 (UTC)

The danger of changing this search is that there's other uses of that field and so other searches that could break, especially if you try and remove hyphens before searching - e.g. I can search with "#F-" to find F Series Ace paperbacks, but without the hyphen it's contaminated with loads of other publications. I'd publish the current algorithm and the proposed one before attempting any changes, we have to run it past the people that search for ISSNs and Catalog numbers as well. And it would be nice to future proof for 979- prefixes too. BLongley 17:32, 9 June 2009 (UTC)

I really think that is too much to ask for. A user sees an ISBN printed in a book and searches for it. If no result is returned, the user is entitled to assume that no record exists for that book, at least not with that ISBN, not that a different form must be searched for. The case of an invlaid ISBN is an odd one, and I hope fairly rare, but a valid ISBN htat might be in either -10 or -13 form is very very common. -DES ^Talk 21:23, 9 June 2009 (UTC)

BTW it is my view that hyphen removal and ISBN conversion should not apply if the search target starts with # or is not itself a valid ISBN, or at least a plausible one -- in particular any non-numeric character should disable such conversions. -DES ^Talk 21:26, 9 June 2009 (UTC)

But search already does remove the hyphens (and spaces). Sometimes. See Example 2a. The only way to find that one without knowing about SQL wildcarding is to use the omit-the-check-digit trick above while leaving in the punctuation. To my simple little pea brain, if I type in the ISBN and search doesn't find it, it's not in the database. This isn't the same as searching by title or even by author name, where there's a good possibility of variation in spelling, punctuation, omitted/extra words/initials, etc. An ISBN is an ISBN. --MartyD 18:15, 9 June 2009 (UTC)

Exactly. -DES ^Talk 21:23, 9 June 2009 (UTC)

And an ISBN-10 is not an ISBN-13. If I search for one and don't find it, it isn't here: it hasn't been recorded that way. It's arguable that we should be able to record whether it was recorded one way, or the other, or both. Or that most of our users don't understand ISBNs and we should make it easier for them: - but does that mean we try and form all the other valid ISBNs and search for them, or search without the ISBN-13 prefix(es) and check digits? Maybe even without a leading 0 or 1 so we find SBNs? Lots of options to discuss. BLongley 18:58, 9 June 2009 (UTC)

An ISBN is an ISBN. Many, perhaps even most, books now print both a -10 and a -13, and which we enter is pretty much at random, as far as i can see. Many online sources, particularly Amazon, now report ISBN-13s for books published long before the -13 format was thought of. A user finding a -13 ISBN from such a source and searching on it should be able to find the proper record in our db. Not to convert between -10 and -13 for search purposes is IMO almost as counterproductive as making title searches case sensitive would be. Asking the user to guess which way the editor happened to edit a value so fully convertible that we display BOTH forms, and require you to enter edit mode to even see which way it is stored seems perverse. -DES ^Talk 21:23, 9 June 2009 (UTC)

BTW, this little piece of the existing behavior extends to "catalog ids", too. If for some strange reason a pub had "#0-441-01547-6", search using "0-441-01547-6" would not find it. The current algorithm is: If the search term is a valid ISBN (without dashes and spaces looks like an ISBN, and first 9 or 12 digits compute to check digit), search for pubs whose stored ISBN string contains the search term with spaces and hyphens removed. Otherwise, search for pubs whose stored ISBN string contains the original, unaltered search term. A more do-what-I-mean algorithm could be: If the search term is a valid ISBN, search for pubs whose stored ISBN string contains either the original search term or the search term with dashes and hyphens removed or the search term converted to ISBN1x (whichever it is not) without punctuation or the search term converted to ISBN1x with punctuation. Otherwise, search for pubs whose stored ISBN string contains the original, unaltered search term. --MartyD 18:15, 9 June 2009 (UTC)

If a valid ISBN has been #ed out I'd want to find and probably fix those. Have you got examples? As the only time I can foresee that happening is if it's known to be the wrong one, but still stated on the pub that way, and we haven't found the right one. But we have variable practices in situations like that so more investigation is in order. BLongley 18:58, 9 June 2009 (UTC)

I just picked an ISBN to illustrate. Nothing in the code knows it's a real ISBN, just that the first 9 or 12 characters are only digits and the last digit-or-X is what you get from the ISBN check digit calculation. And it doesn't have to be a leading "#". The catalog ID could be "ABC-04410-15476-DEF", and searching using 04410-15476 would not find it, either, just because the search term passes the ISBN recognition rules and is modified. --MartyD 01:19, 10 June 2009 (UTC)

That's where serial searched could answer the problem. Let it search both ways and display the combined results. Kevin 04:16, 10 June 2009 (UTC)

Actually, looking at 2b, I'm wondering why Dragon Magazine has an ISBN rather than an ISSN anyway. Is there an ISSN-13 I've not heard about yet? BLongley 20:12, 9 June 2009 (UTC)

I believe I have seen magazine issues which had both an ISSN and an ISBN. Ahasuerus 21:35, 9 June 2009 (UTC)

Call me a dreamer. I want to enter ISBN format ISBN10, ISBN13, ISBN13_979, Both With and WithOut dashes, Hyphens, Emdashes, With and Without the leading 0 or 1, (Yes I'm biased towards english results) with and without checksum digits, and also a simple matching search should still work for any segment of an ISBN, Publisher or Catalog number, and find the book I'm looking for. (Yes that's alot of trapping and ELIF's) but it only seems reasonable. It might be Easier to code if we rework the ISBN system so that all ISBNs are stored as ISBN13 and ISBN10 is derived for all ISBN10 and ISBN13_978 data entries. Kevin 22:44, 9 June 2009 (UTC)

I would be willing to omit searches that drop the 0 or 1, in fact I would oppose logic to automatically add the leading digit, as i do sometimes need to work with ISBNs whose leading digit is not 0 or 1. I also don't see the need of searches that omit the checksum digit (except by explicit wildcarding), and how is the software to know if a 9 digit search target has an omitted check digit, or is an SBN, or whatever. Too much flexability tends to lead to over-complex interfaces and/or confusion behavior. I would settle for a system in which a valid ISBN could be entered with or without spaces, dashes, etc, in -10, -13, or -13(979) form, and any pub record with any exactly equivalent ISBN, in whatever form, would be found. A wildcard for partial match searches would be nice. A search for cat #s should be a plain text match, preferably with wildcards. -DES ^Talk 23:06, 9 June 2009 (UTC)

Oh.. I'm not imagining a complex user interface. I'm thinking that the ISBN Search function performs serial searches on the transformed number and displays the results as a single result list. As an example, enter an ISBN8 (without the language prefix, or checksum), then you would get all matching ISBN10/ISBN13_978, ISBN_979, SBN's, etc that match, All presumed in english (1 or 0). If you enter an ISBN10/ISBN13_978 or ISBN13_979 with say a 5 language identifier, then you would get results including the 5. The 1 or 0 should only be assumed if missing, and if missing the search should run without the 1 or 0 added as well as with. Kevin 04:12, 10 June 2009 (UTC)

I see. If a 9-digit string that might be an ISBN is entered do you assume a missing lead character, or a missing check digit? I guess you assume both, and return any result that matches either assumption. Do you support a wildcard, so that 123-456-7??? matches any ISBN that starts with 123-456-7 perhaps? Should just doing the -10 / -13 conversion, and running both searchs, be a proper inital small change? -DES ^Talk 13:37, 10 June 2009 (UTC)

(unindent) It's not a complete DWIM searching solution by any means, but can anyone see anything wrong with -- and are there any objections to -- the relatively small change I proposed above: current behavior + allowing "valid ISBN" text to match as entered + allowing "valid ISBN" text to match other-length ISBNs (punctuated and non-)? Or shall I forget this idea, and we live with current "not-a-bug-but-a-Feature" behavior until such time as searching can be made to do much more (perhaps in conjunction with any change to how these IDs are captured and stored in the first place)? --MartyD 15:01, 10 June 2009 (UTC)

Sounds good to me, we can worry about perfection later. -DES ^Talk 22:14, 10 June 2009 (UTC)

Agreed. There are all kinds of complications here, e.g. we are already seeing some books that list an ISBN-13 but not an ISBN-10, but we can sort them out later. Ahasuerus 01:33, 11 June 2009 (UTC)

Better is better. Go for it. Kevin 04:12, 11 June 2009 (UTC)

I'm fine with the small feature request as proposed, don't go into SBNs yet though, it seems some of you don't really understand them yet. (E.g. there's 11 digit numbers that have been called SBNs when they are at best SBNs with a 3 digit price replacing the check digit.) BLongley 21:54, 11 June 2009 (UTC)

I just added a fix for Bug 2804769, addressing #1 and #2a and leaving the behavior of #2b unchanged per this discussion. Searching by ISBN in the basic search or advanced search using a full, "valid" ISBN-10 or ISBN-13, will match any of the four variations of [non-]punctuation and length. --MartyD 11:08, 7 July 2009 (UTC)

Draft Help page on serials

Please see Help:Use of the SERIAL type for a draft of a help page that discusses this subject and the reasons for our current practice. Comments welcome. -DES ^Talk 22:13, 10 June 2009 (UTC)

Change Clone and Edit 'Submit' Buttons

Moved to ISFDB:Proposed Interface Changes#Change Clone and Edit 'Submit' Buttons

Development Choices - A new Page?

Development discussions seem to have overtaken the Community Portal. Development is for documenting what's going on, and Development:Talk is for talking about development code, techniques, etc I feel. Do we need another page with 'special' rules for quicker archiving, to throw up screenshots, etc and discuss user interface, etc. We could post a headline and link on Community Portal, and then link to a 'Development Examples and Discussion' page. When a particular feature goes live on the server, and gets thrashed a bit with everyone testing and proposing changes/updates, that conversation could be archived before it spends 6 months to a year drifting to the top of the page. Just a thought. Interested in seeing if there are similar thoughts out there. Kevin 02:55, 12 June 2009 (UTC)

We already have ISFDB:Proposed Design Changes perhaps we could use that? That was an attempt at such a thing some time ago. Unfortunately it was created just as Al started to have little time for development, and well before the current round of proposals and changes. Some of the content may well be obselete, but the page can be used, i would think. And much of it, i think, is not obselete. -DES ^Talk 12:22, 12 June 2009 (UTC)

That page seems more tuned for 'changes to the sql database', not changes to the 'isfdb interface'. Kevin 01:55, 14 June 2009 (UTC)

Very well, we now have ISFDB:Proposed Interface Changes also. -DES ^Talk 02:25, 14 June 2009 (UTC)

Looks good, (other than it's all my topics at the moment - Chuckle) Kevin 03:32, 14 June 2009 (UTC)

Image Linking Permission - From the ISFDB?

Do we have any policy on image linking from the ISFDB? Since we now host 5000+ images I think it would be appropriate to pre-develop one and post it to ISFDB:Image_linking_permissions. I propose...

1. Blanket permission to any non-commercial / non-profit site for up to 500 hot links to our images. Please contact us if you are approaching that limit.
2. Blanket permission to any commercial / profit site for up to 250 hot links of images, with a human readable link back to "www.isfdb.org" required in each article / blog entry using the image(s). Please contact us if you are approaching that limit.
3. Blanket permission to all deployments (private or public) of the isfdb.org software and or database to link all images without limit. Please contact us if your deployment will serve more than 100 unique users a day, or you are approaching that limit.

The above policies are both generous and reasonable. They might even encourage small fan sites to use us to host their images, (and thereby upgrade our database information to support thier off-site project). Thoughts? Kevin 14:38, 13 June 2009 (UTC)

Seems not unreasonable to me. Of course we already grant permission for reuse as all our contents are published under a creative commons license, but hot-linking is different. -DES ^Talk 14:43, 13 June 2009 (UTC)

Number three is because a 'deployed' private isfdb already hot links every image to www.isfdb.org, so the CC license doesn't cover that. Kevin 14:59, 13 June 2009 (UTC)

Bump. I would like to close this out, or at least get some more opinions, but I think it's been lost in all the discussion below. Kevin 22:02, 16 June 2009 (UTC)

Given our current unexplained timeouts and slowdowns, I'd be reluctant to encourage others to use our bandwidth for now in case that's part of our problems. So I'd leave it as a reminder that we have no problem with reuse of the images, but wouldn't encourage hot-linking yet. If the person/people paying for our current hosts feel more generous, then let them say so - I don't think it's up to us to be even more generous than we currently are. (Or are you paying for our hosting, Kevin?) BLongley 19:57, 18 June 2009 (UTC)

Nope, I'm not paying for the bandwidth. I'm just trying to document a policy. It came up (to me) because we asked someone else to get permission from a similar (German, Single author) Wiki site. It pointed out to me that we don't have a policy, even one so stringent as "No." documented. As for the hosting costs, if they ever become an issue, then we can discuss them. I assumed that our out of pocket costs are rather minimal / covered by the monetized amazon links. I haven't priced a shared server with shell access, but my unlimited storage, unlimited bandwidth (Yes, I know it's not really unlimited), unlimited domain name hosting solution is just under ~$100.00 a year. (shrug). If everyone else here feels it is appropriate to hotlink to other similar sites, and not offer some similar arrangement when 'we' have the better image available, so be it. Kevin 23:45, 18 June 2009 (UTC)

I don't know who is paying for our current bandwidth and hosting costs, what the costs are, nor how near our limits we are, nor whether bandwidth consumption has anything to do with the recent (all too frequent) server time outs. I rather suspect it doesn't but that's just a guess. We should find out. Having found out, if we have plenty of bandwidth to share, i have no objection to hot linking. If we don't have a healthy margin, then encourage reuse but not hot-linking. -DES ^Talk 04:03, 19 June 2009 (UTC)

It might also be time to readdress the possibility of a "switch off images" option for local copies (or maybe even make it a user preference online) so that we can truly use ISFDB completely offline, or avoid unwanted data-charges for images we don't really need if online. BLongley 19:57, 18 June 2009 (UTC)

A few comments/answers:

• The ISFDB FAQ currently says "Q: Is it okay to deep link into ISFDB pages? A: Of course it is", so in a way we already have a policy.
• Our current bandwidth allowance is $350Gb/mo (plus apparently unlimited FTP for backup purposes) and we barely use a couple of Gb/mo.
• We tried a shared server when we moved to this ISP last year and the performance was often atrocious, presumably due to other users' malformed MySQL queries. We ended up upgrading to a virtual server ($30/mo) and it worked well for us until the recent series of intermittent outages started.
• Al is the one who gets the bill from the ISP and I pay for it. Ahasuerus 04:25, 19 June 2009 (UTC)