ISFDB:Community Portal/Archive/Archive38

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

Archives of the community portal for July - December 2015

Nominating Albinoflea for moderator

I hereby nominate Albinoflea (talk • contribs) to be a moderator and he has accepted. He has been an editor on the ISFDB for more than five years, and has grown proficient in every area of the database: creating new records, updating records, varianting, and merging. He also has good communication skills and the right mindset for being a moderator. As such, I believe he is extremely qualified for the position, and he'll be a great asset to the moderating team.

Support

1. Support, as nominator. Mhhutchins|talk 04:13, 1 October 2015 (UTC)
2. Support. Good communication skills, good working knowledge of the software/database. Ahasuerus 04:22, 1 October 2015 (UTC)
3. Support. What he does, he usually does right. I'm all in favor. Stonecreek 13:12, 1 October 2015 (UTC)
4. Support. The few submissions I've seen from him looked good. I trust Michael's estimation of his edits, and looking at his talkpage shows good communication skills. --Willem 18:30, 1 October 2015 (UTC)
5. Support. For all the reasons stated above. PeteYoung 00:24, 2 October 2015 (UTC)
6. Support. Despite the low number of contributions over the five years, he seems to know his stuff. I trust him. ···日本穣 · 投稿 · Talk to Nihonjoe 05:00, 3 October 2015 (UTC)
7. Support. Sorry to be late to the party. No reservations. I haven't had to question a submission in years, and his communication skills are excellent. --MartyD 00:38, 6 October 2015 (UTC)

Oppose

Comments/Neutral

1. Neutral A number of contributions (less than 1700) a bit low overall for a moderator and denoting a sporadic activity (five years as an editor). Hauck 12:45, 1 October 2015 (UTC)

Outcome

The nomination was successful. The moderator flag has been set on the account. Congratulations! Ahasuerus 20:16, 6 October 2015 (UTC)

2015-10-01 -- Brief database outage at 5pm server time

There will be a brief database outage between 5pm and 5:05pm server (US Central) time. Ahasuerus 21:48, 1 October 2015 (UTC)

Updating the "Pub Binding/Format" help documentation

Since there are almost 700 records in the database for MAGAZINE-typed publications entered as "tp", I have updated the help documentation to include it as an option for print magazines. The addition is:

• tp - trade paperback magazines, usually perfect-bound, i.e. periodical publications (often POD) which otherwise would qualify as trade paperbacks (see "tp" in the Print books section)

If there are suggestions for further clarification of the documentation, please let me know. Mhhutchins|talk 19:35, 2 October 2015 (UTC)

I see you made a few other changes at the same time to improve nearby sections, and I like them all. I especially appreciate it when someone shows they know the difference between "i.e." and "e.g." :-) Chavey 14:19, 5 October 2015 (UTC)

Extra long synopses

Some of our synopses are quite long, approaching 3,000 characters. For example, consider Borrowed Time. The synopsis field accounts for 70%+ of the page, which seems excessive. Should we institute a policy requiring anything beyond the first N characters to be hidden behind {{BREAK}} now that the functionality is available? If we decide to do it, I can whip up a cleanup report identifying the offenders.

For reference purposes, we have 13 titles with 2,000+ character synopses and 299 titles with 1,000+ character synopses. The total number of titles with synopses is 9,962. Ahasuerus 15:40, 3 October 2015 (UTC)

I believe we need to limit the synopsis to 1000 characters or less. That way we wouldn't have to deal with a break. I can't imagine that any work would need more than 1000 characters to synopsize. Mhhutchins|talk 19:06, 3 October 2015 (UTC)

It seems like a reasonable policy when entering home-grown synopses, but what should we do when dealing with publisher-provided ones? It may require careful editing and lots of ellipses, which can make using BREAK an attractive alternative, especially since BREAK is already supported in the Synopsis field. Ahasuerus 02:38, 4 October 2015 (UTC)

In my experience, long publisher synopses can usually be abbreviated by selectively excluding some introductory text or else things such as a final paragraph. There's usually stuff that goes into too much detail on plot, and is unnecessary to just getting a sense as to what the book is about. IMHO, any book that deserves more that Mike's suggested 1000 characters deserves, instead, to have a Wikipedia page that we link to. If it's not significant enough for Wikipedia, it's not significant enough for a lengthy extract here. Chavey 15:01, 5 October 2015 (UTC)

Two David Gerrolds?

Based on circumstantial evidence, it would appear that the author of the novel Jacob is not the same person as "our" David Gerrold. Would anyone happen to have a way to confirm it? Ahasuerus 02:34, 4 October 2015 (UTC)

Yes, he's "our" David Gerrold. Look on the back of the book via the Amazon listing. Mhhutchins|talk 03:36, 4 October 2015 (UTC)

Just added a new collection from the same publisher. As there are only two works from this publisher, he could be self-publishing these new works. Both have "DG Media Banner Edition" on the back cover. Mhhutchins|talk 03:53, 4 October 2015 (UTC)

Nice, thanks! Ahasuerus 04:39, 4 October 2015 (UTC)

Locus dates in square brackets?

A great many Locus online site book entries have a second date in square brackets after the first date listing; I'm guessing they indicate an alternative edition or similar, but can't find anything about them elsewhere on the site - does anyone know what the intended reason for them is? Thanks, Astrodan 13:08, 4 October 2015 (UTC)

On the printed versions of the indexes (I've grabbed this one), the date in brackets is given as being [Date First Seen]. I suppose it's the same meaning online. Hauck 13:38, 4 October 2015 (UTC)

Based on my experience with their Web site, your interpretation is correct. Sometimes they get books before the official publication date and sometimes (much) later. Ahasuerus 16:50, 4 October 2015 (UTC)

Thanks, Hauck Astrodan 13:53, 4 October 2015 (UTC)

Triplanetary (1934 serial version)

I noticed that one of my primary verified publications (Triplanetary) has recently been edited. The intent appears to have been to separate out the serialized and novel versions of Triplanetary. While I can agree with the intent, I have concerns with the implementation:

• Title Records: I don't see the need to disambiguate the various title records to Triplanetary (1934 serial version). Disambiguating title records is usually used only for common titles (Introduction, etc.). For cases like this, we normally rely on the notes alone. I believe the title records should be restored to "Triplanetary". At the most, the parent record could be disambiguated and the variants should retain there as-published titles.
• Publication Records: Even if we use the title record disambiguation, the publication titles should not have been updated to add the "(1934 serial version)". The publication titles should match the publication title page per our standards.

I'm surprised that such a major change would have been made to primary verified publications without any notice. While the other two primary verifiers are no longer active, that should have entailed a note at the moderator noticeboard and I should have been notified. -- JLaTondre (talk) 16:37, 4 October 2015 (UTC)

I made two submissions in the early hours of 10/3: 1) to change the date of the title record to be consistent with the rule of first book publication of a serial, and 2) to variant the title record of a Fixer-submitted record to the canonical author. I made no changes to your verified record. These two changes were made because the title showed up on a cleanup report. Looking over the list of accepted submissions for late 10/2 (which caused them to show up on the following day's reports), Marc Kupper made more than 30 submissions affecting both title records and publication records, including yours. I can see why the two works should be separated, and the disambiguation seems to be the most effective way to keep them separate. But I agree that the publication's title fields should not have been changed. And you should have been notified. I'll leave a message on Marc's page to ask him to join the discussion. Mhhutchins|talk 17:05, 4 October 2015 (UTC)

It's been quite awhile without a response from Marc and he's been active. I've gone ahead and restored the publication records [removing the "(1934 serial version)"] so they match the publications as per our standards. I still believe the title record disambiguation is unnecessary. It is no different than a case where an author has used the same title for two different stories. However, I don't feel strong enough about it that I would pursue debating it. -- JLaTondre (talk) 20:29, 16 October 2015 (UTC)

I agree that the title fields of the publication records should not have been disambiguated. Because of the mismatch in the title fields of the publication and title records, this will show up on the cleanup report which finds mismatches (once novels have been added to it), but at least now we have the option to ignore such discrepancies. Mhhutchins|talk 20:36, 16 October 2015 (UTC)

Alerting all editors: single cover art with multiple credits

Since the software change which creates multiple cover art records when an editor uses the "Add Artist" button when creating a publication record, it is important to only use that button if there are two covers for which there are separate credits. Do not use that button when there are multiple artists credited for a single cover. You should only enter one credit at the time of the publication record's creation, and then once it is moderated, you have to go back and update the one cover art record to add the other credits. Without this workaround we are creating hundreds of false records, both publication records and cover art records. It is much harder to fix these after their creation than it would be to avoid them in the first place. Unless there are volunteers who are willing to help clearing the 2000+ records on this clean-up report.

I personally wish the software would be changed so that the default of using the "Add Artist" button would create a single record crediting multiple artists, Mhhutchins|talk 17:34, 4 October 2015 (UTC)

Yes, it's possible to implement. However, COVERART records have a number of issues associated with them, e.g. Bug 155 (Shared COVERART titles not handled consistently), and I hope that we can implement a single major change which will address all of the issues in one fell swoop rather than applying multiple partial band-aids. As discussed earlier:

• It would appear that the most straightforward solution would be to convert the current multiply occurring "Artist" field to a multiply occurring "Cover Art" group of fields. Each "Cover Art" occurrence would then support multiply occurring "Artist" fields. It would be similar to the way the Content section works: it supports multiple "Title" groups and each group supports multiple "Author" fields. Ahasuerus 19:05, 4 October 2015 (UTC)

and that the record would appear on each artist's summary page as "Cover: XXXX [with ArtistB]". Ahasuerus, is that possible? Mhhutchins|talk 17:34, 4 October 2015 (UTC)

I am not sure I am reading the second question correctly. The way the "Cover Art" section of Summary pages works is similar to what you seem to be describing. For example, here is a section of Leo Dillon's Summary page:

• Cover: The Odyssey: The Story of Odysseus (1963) with Diane Dillon
• Cover: The Complete Short Stories of Mark Twain (1964) with Diane Dillon

What kind of changes would you like to see? Ahasuerus 19:05, 4 October 2015 (UTC)

If I understood this problem correctly then this is all news to me, and the Help is wrong (and incomplete) then: "Add Artist. If the cover art is credited to more than one artist, this button will create a second artist field." Also, the "Add artist" button label should probably be renamed to "Add Cover", at least for the time being until the software has been changed, because I think this label is less prone to be misunderstood. Jens Hitspacebar 20:32, 4 October 2015 (UTC)

The Help page may not have been updated when the software change was made that created separate cover records (as opposed to separate cover artists). And yes, you're correct. Instead of being labeled "Add Artist", it should be "Add Cover" since that's exactly what it does. It doesn't add an artist to the cover record. Mhhutchins|talk 21:32, 4 October 2015 (UTC)

The reason the Dillons' pages look that way is because it took me the better part of a day to fix all of their records about a year ago. And I'm going back to check it every month or so to find new errors to correct. Those records are the way they should be, not the way they would exist if I hadn't fixed them. Mhhutchins|talk 21:32, 4 October 2015 (UTC)

Understood, but I am afraid I am still not sure what kind of change to the way the Summary page behaves you would like to see. Could you please provide an example of the data appearing one way while you would like it to appear another way? Ahasuerus 23:39, 4 October 2015 (UTC)

Look at any recent publication record which had multiple artists credited for a single cover. For example, this publication record was created today. There is one cover credited to two artists, but there are two cover art records each attributed to each artist. There should be one cover art record credited to two artists. If you look at one of the artist's summary page there's no indication that the cover was a collaboration, as in " [with Shutterstock]". If you click on the cover art record, you have no idea that it was a collaboration. Of the 2300+ records on the clean-up report, I'd guess that 90% of them are cases like this, instead of publications with two covers. Tomorrow morning, this publication record will show up on the cleanup report. Mhhutchins|talk 00:43, 5 October 2015 (UTC)

True enough, but that's a data entry problem, not a display problem, which was how I originally interpreted your second question. Unfortunately, once the software has created two COVERART records, the damage has been done and it can't be undone by changing the way the Summary page displays things. Ahasuerus 01:30, 5 October 2015 (UTC)

And that's the purpose of my original post. To ask editors to not use the "Add Artist" button for single covers, because the software acts like you want it to create two covers. So it's not a "data entry problem". The editors are doing exactly as they are being told to do: add a new artist. They're just now aware of what the software does with the data that is entered. They don't realize that the software is creating multiple cover art records. Mhhutchins|talk 01:38, 5 October 2015 (UTC)

Sorry, I didn't mean to imply that it was the editors' fault. I guess I should have said something like a "data capture problem", as opposed to a display problem. Ahasuerus 02:30, 5 October 2015 (UTC)

What we need to do is change the way the data is captured and stored in the database, not change the way it is displayed. The latter would only make things worse by incorrectly displaying pubs with 2 covers like An Earth Gone Mad / The Rebellious Stars. I'll see what I can do in the next few days. Ahasuerus 01:30, 5 October 2015 (UTC)

That's exactly what I'm asking. But until the software is changed, the least we can do is ask editors to minimize the damage being done now. I doubt many moderators will be working on that cleanup report to fix the thousands of bad records in the database. Thanks. Mhhutchins|talk 01:38, 5 October 2015 (UTC)

It seems it might be helpful to have a cleanup report that warned us about all pubs that listed as having two covers, but aren't in dos-a-dos format. Chavey 14:24, 5 October 2015 (UTC)

That was silly. I clearly don't know my cleanup reports as well as I should. Chavey 03:26, 6 October 2015 (UTC)

We are up to 95 reports -- there are times when I have to check the code to see what they do :-) Ahasuerus 04:00, 6 October 2015 (UTC)

A question, though: Does that clean-up report auto-skip books that are listed as "dos" type? Chavey 03:26, 6 October 2015 (UTC)

I see it does not filter out such books; presumably we have to mark books such as this (a dos currently on that cleanup report) as "Skip". Chavey 03:56, 6 October 2015 (UTC)

That's right. A dos pub has two covers and each cover may have 2+ artists, so I think it would be best to check them manually. Ahasuerus 04:00, 6 October 2015 (UTC)

I went through all dos pubs on the list (well, all those that were named "title 1 / title 2"), and they were all limited to two authors, so I "ignored" all of them. And made some other progress on the cleanup report list. Chavey 23:18, 6 October 2015 (UTC)

Excellent, thanks! Ahasuerus 23:30, 6 October 2015 (UTC)

I hope you meant two "artists" and not "authors". :) Records with two covers by the same artist has to be manipulated to credit him for both covers. This involves changing his name to a temporary one because the system currently doesn't create two cover records when only one artist does both. Mhhutchins|talk 01:45, 7 October 2015 (UTC)

(unindent) Yes, I meant "artists". I did run across one book that had 3 "covers" on the cover, 2 by the same artist, so that was left as it was with 3 covers. (I think I then hit the "ignore" link.) Chavey 15:01, 8 October 2015 (UTC)

For the record, and regarding the very beginning of this discussion : I followed the suggested procedure, and added a second artist credit after moderation, but ended up with two covers here. And this is not the first time this procedure doesn't work (with me, anyway). Linguist 16:14, 8 October 2015 (UTC).

It looks like you updated the publication record and not the cover title record. It's going to take two submissions. On the first submission, remove one of the artist credits. Then you must wait for that submission to be moderated before making the submission updating the cover title record. It can not be sitting in the queue at the time the first submission is moderated. Add the removed artist credit back in the second submission updating the cover title record, not the publication record. Mhhutchins|talk 16:42, 8 October 2015 (UTC)

Ah, right, I get it. I had understood “update the one cover art record” as “update the art cover field in the record”. Thanks for the clarification. Linguist 21:38, 8 October 2015 (UTC).

Size doesn't matter (or does it ?)

Discussion copied from Bill (Bluesman)'s talk page:

Hi Bill. As you might have noticed, I had re-sized this image from 640 to 600 pixels, as regulations seem to imply this should be the norm (if I understood them correctly). Just for the record, and for my own understanding of the sometimes implicit rules of this database, could you enlighten me as to the reason of your revert ? TYIA, Linguist 20:38, 4 October 2015 (UTC).

Simply put, file size. Though the image was reduced in pixels, the file size actually went up [not a lot in this case, about 10kb??]. While we will never run out of pixels, the available storage space for the DB is finite. This peculiar rule was adopted when the DB was quite new and when pixels/file size were more tightly bound to each other. It's sad it hasn't been updated, strange that the warning about the file size doesn't come up until after an upload is attempted. With all the newer programs for manipulating images pixels and kbs have little to do with each other, so no, size [pixels] doesn't really matter. It's like comparing a cubic mile of pure vacuum to a cubic centimeter of neutronium ..... and only taking into account the dimensions. I'll get the usual storm of protest that "Da rules is da rules!!!" .... ah, well .... If you can reduce the size [pixels] of any image without losing the details that matter [prices/catalog #s/artist signatures/etc] AND reduce the file size, go for it, but don't sacrifice the data just for the ephemeral. A particular editor resized several hundred images from another editor but in each case the file size went up by at least 30%, but by golly "Da Rules" were being followed ................. Cheers! --~ Bill, Bluesman 21:37, 4 October 2015 (UTC)

Several thousands, I say ;-) Hauck 05:59, 5 October 2015 (UTC)

Thanks for your answer. I'll try and make the most of it… :o) Linguist 09:48, 5 October 2015 (UTC).

No. No. No. Don't do it. By Bill's rationale, we could upload an image that is 2,000 pixels tall, as long as it was under 150 kb. No, that's wrong. The reason why we limited it to 600 pixels was to claim the fair-use stance and to protect copyrighted material, and that had nothing to do with server capacity. We had to make sure that copyright holders couldn't accuse of hosting files that could be used to create illegal copies. Someone (not me) determined that 600 pixels would be about the limit before our fair-use claim would be questioned. Most of us are staying within that limit, so there's no reason why all of us can't. Mhhutchins|talk 16:41, 5 October 2015 (UTC)

Not correct. The reason for the 150 kb limit is to stay within the fair-use stance. Any image that has 150 kb of data or less can't be used to make a commercially viable copy, regardless of how many pixels there are [10x10 or 1,000,000x1,000,000] the file size determines how much data there is to be used/abused, nothing else. The pixel 'limit' is from at least 15 years ago?? Sadly out of date now with all the newer programs that let one manipulate same. As for below, when the option was still available to restore a deleted image, I checked many that you had resized and M. Hauck's images would run 65-90kb before but were over 125 after 'reducing' them. Quirk of the program?? There was really no point in reducing them at all as they weren't of high enough resolution to make a commercial copy. --~ Bill, Bluesman 23:44, 7 October 2015 (UTC)

And BTW, I have reduced the image size of several hundred files uploaded by both Bluesman and Hauck (maybe even thousands, I didn't keep count), but the size of the file was ALWAYS reduced as well. That's something I shouldn't have had to do, but when I approached both of them about violating the standards, they either refused or ignored my requests. If they felt strongly that the standards should be changed, then they should have brought it before the group for discussion, and not made unilateral decisions to ignore the standards. That's not how a community works. Mhhutchins|talk 16:49, 5 October 2015 (UTC)

Says our expert on community management. Hauck 19:49, 5 October 2015 (UTC)

Says our expert on snide remarks which add nothing to the discussion. Mhhutchins|talk 21:14, 5 October 2015 (UTC)

禅. Linguist 20:46, 5 October 2015 (UTC).

(unindent) Bill and Michael are both right. Hosting extra-large high-resolution images (at one point an editor uploaded a 2MB file!) can cause copyright issues. At the same time, our disk space remains limited, so that's also a concern. We've been OK disk space-wise since the last round of optimizations, but it can become an issue if we are not careful. Ahasuerus 23:36, 5 October 2015 (UTC)

Actually, no. Bill is saying that there should be no consideration for the image size limit as long as we stay within the file size limit. I'm saying we should be considerate of both, each for different reasons: the image size for copyright reasons, and the file size for server space reasons. Mhhutchins|talk 04:12, 6 October 2015 (UTC)

It's NOT the image size, it's the resolution used [ie: the file size] that would constitute copyright infringement. --~ Bill, Bluesman 23:44, 7 October 2015 (UTC)

Also, let me repeat my mantra from years past: the internet is a wonderful tool, but, unfortunately, it doesn't transmit your body language, which can cause all kinds of misunderstandings and lead to unnecessary conflict. Ahasuerus 23:36, 5 October 2015 (UTC)

Some words and their meanings are quite clear, regardless of any unseen body language. And this particular editor has made such remarks consistently, so I don't need to see his body language to understand exactly what he means. There's no possibility of misunderstanding in this case. Mhhutchins|talk 04:12, 6 October 2015 (UTC)

(unindent) I had thought the reason for the 600px limit as a specific number on ISFDB is because we don't have a wikimedia add-on, plugin, or whatever it's called in that universe to auto-scale images. At the time, and possibly the present, we did not have internal expertise to do the level of twiddling needed to install the component. If an image is over 600px then you get a white box on the Image:... pages though can still use the image on publication and author records. Thus 600px became a technical limitation. It also worked out well as a copyright and fair-use limitation. At the time, Amazon had a 500px limit and so was setting a standard in that area. After some discussion we felt it was safe to use 600px. Please see Rules and standards discussions/Archive/Archive05#Image scaling for a discussion back in 2008. Marching forwards, Amazon's limit is now 1000px and Goodreads (owned by Amazon) uses 933px.

The file size grows as the total number of pixels grow at a 4x rate for each doubling of the number of pixels. My 600px images are averaging 48,838 bytes. If we went to 1000 pixels it would be 104,350 bytes per image. --Marc Kupper|talk 08:40, 6 October 2015 (UTC)

When one is scanning. You can't take an existing file, double the 'space' it occupies [pixels in this case] and get 4x the data. All you'd get is a very grainy image, again useless for commercial copying. --~ Bill, Bluesman 23:44, 7 October 2015 (UTC)

Criminal or detective stories

I try to find out if detective or criminal stories are to be included in ISFDB or not and don't get a conclusion. Sherlock Holmes is marked as NONGENRE, but the Black Widowers from Asimov not. Some detective stories are included, others not. The Rules page does neither say yes nor no. As I think more is better I'd prefer to include them all as borders between fiction genres are and will never be clearly defined. IS there an consensus which only was not documented? --Stoecker 16:06, 6 October 2015 (UTC)

The Rules of Acquisition cover it under items 4 and 8. Without any speculative fiction elements, they would only be included if the author is "above the threshold". Unfortunately, "above the threshold" is not an easily quantifiable description and different editors have different opinions. When there is debate, it should be brought here for group consensus. As far as marking them non-genre, that is a relatively new field. If the stories are included because the author is above the threshold and they don't have any speculative elements (which can also be debated as different editors have different thresholds for that as well), they should be marked non-genre. Not all older entries have been updated. -- JLaTondre (talk) 16:15, 6 October 2015 (UTC)

Isaac Asimov is "above the threshold", so his mystery stories should be included in the database. Those without any speculative element should be marked non-genre. Raymond Chandler is not "above the threshold", so only his speculative fiction stories would be eligible for the database. The measurement of "above the threshold" is too nebulous to be documented. As JLaTondre says, if you're uncertain if an author qualifies, you can inquire here on the Community portal. Mhhutchins|talk 17:54, 6 October 2015 (UTC)

ISFDB app for iPhone / Android

Because of my own personal library I've been forced to download and use an Android app on my phone to keep track of what books I own. In my search for just such an app I stumbled across your wonderful database. It has occurred to me that you could expand and fill-in your online database by the creation of your own app. Such an app could assist the users by helping them log and keep track of their own physical libraries on their phone/tablet (as I do). In trade the users could use the app to help isfdb fill in details on the books already here as well as add missing books when the user happened to be trawling through new or used books stores. Everyone wins. Blargg 08:32, 9 October 2015 (UTC)

An intriguing idea. I don't have the right skill set or the time/bandwidth to learn the necessary skills, but perhaps someone else may be interested. Ahasuerus 03:20, 10 October 2015 (UTC)

Publication/Title Delete fixes

A fairly big patch was installed 20 minutes ago. It changed/corrected the way publications and titles are deleted. There should be no user-visible changes to the way the software behaves, but the change should eliminate "dangling artist" records which used to stay behind when the last COVEART title was deleted. As always, if you see anything unusual, please report your findings here. Ahasuerus 03:29, 10 October 2015 (UTC)

Further tweaks to the way the Title page displayes publications

As per Bug 583, the Title page has been changed to display near-simultaneous editions correctly. For example, the 1928-10-02 edition of Virginia Woolf's Orlando now appears before the 1928-10-11 edition. YYYY-MM-00 pubs will now appear after YYYY-MM-DD pubs. Ahasuerus 23:15, 10 October 2015 (UTC)

The submitter of Bug 583 thanks you :-) Chavey 05:25, 11 October 2015 (UTC)

Bibliographic warnings for magazines/fanzines

Magazines and fanzines will no longer generate "bibliographic warnings" when they do not have ISBNs or catalog IDs associated with them. Ahasuerus 15:52, 11 October 2015 (UTC)

Thank you! Chavey 18:37, 11 October 2015 (UTC)

Standardization of Publisher names ... ??

Twice in the past three days as I attempt to get a backlog of several hundred paperbacks off my desk, I have had "New Publisher" show up after submitting a new record/change record. Today it was Corgi Books. Someone has standardized it to simply Corgi. Since the late 60s all Corgi editions have Corgi Books on the title page; only the earliest editions had the little dog logo [sometimes with Corgi on it] but no "Books". The other one was Baen. I entered an edition that has Baen Books and apparently THAT is a new publisher. Baen went through various minor changes from Baen to Baen Books and then split to have Baen Science Fiction Books and Baen Fantasy before going back simply to Baen. All this over 20+ years. Someone combined the first three into just Baen but left Baen Fantasy. There is no Community Portal discussion within the last year concerning this, nor one that says the Title Page is no longer the source for a publisher name. Standardization for its own sake is what Locus does, and we've been correcting same from that source for years. I'm hesitant to re-enter the 'correct' publisher names for editions I have as the same Moderator [no editor could do such a sweeping change without it showing up somewhere] could just do this again. --~ Bill, Bluesman 19:56, 11 October 2015 (UTC)

New/Edit/Clone Pub tweaks

There have been some minor tweaks to the way certain fields are displayed in New/Edit/Clone Pub. Most of the changes were behind-the-scenes HTML fixes, but a few are visible to the naked eye, notably the way the separator bar is displayed between Contents title records. Ahasuerus 01:38, 13 October 2015 (UTC)

Self-advertising

I volunteer for a local charity that runs three book sales each year. The sales volume is enough to warrant a separate section (10+ tables) of science fiction and fantasy. In speaking to browsers and buyers about their book, author and series interests, I have had occasion to mention this site a number of times. In spite of being armed with paper and electronic lists, they often only make a mental note of the site address. I would like to pre-print a number of 'cards' with the site URL to hand out. Before starting though, I thought I'd gauge the reaction of active members as to the content, presentation and advisability of such a venture and if there are other considerations or interests. Doug 16:28, 13 October 2015 (UTC)

I see no harm in your proposal, and it may even get us not only new users but, even better, new editors. I say go for it. Mhhutchins|talk 21:15, 13 October 2015 (UTC)

Good idea, Doug. Our late editor Bill Longley (rest in peace, sir) was a great promoter of the ISFDB and even went so far as to make an ISFDB t-shirt to wear at conventions. But I think he only got to wear it once before he passed away. PeteYoung 17:23, 15 October 2015 (UTC)

ISFDB/Wiki outage

ISFDB and the Wiki will be unavailable between 8pm and approximately 8:20pm server (US Central) time. Ahasuerus 00:49, 14 October 2015 (UTC)

Everything should be back up and operational. Ahasuerus 01:21, 14 October 2015 (UTC)

Steve Berry spec-fic?

Is anyone familiar with the work of Steve Berry and can attest to its eligibility for inclusion in the database? All I could determine from listings and reviews is that he writes political/historical novels with no fantasy elements. Mhhutchins|talk 04:58, 17 October 2015 (UTC)

I haven't read his works, but I looked into them when Fixer submitted a few "Cotton Malone" books. They are "secret histories" and feature centuries-old conspiracies, the Knights Templar, shadow governments and so on.

The issue of "secret history" eligibility has been discussed, but I don't think we have a solid consensus. My personal take on it is that they should be eligible if the counterfactual element is significant. For example, if a book is about how human history has been secretly manipulated by the Catholic Church/The Secret Nine/the Knights Templar for the last N centuries, then it's eligible. If it's about a more limited conspiracy, e.g. a plot to kill John F. Kennedy, then it's not. Ahasuerus 13:17, 17 October 2015 (UTC)

But just because one book in the series may have a "secret history" plot doesn't mean that all of them are eligible for the database. From what I've read only the first two Malone novels qualify, and even then just barely. There are far too many "thriller" novels already in the database that are marginal at best. I just don't want to fall down the slippery slope of "Well, if ABC is in the database, then why shouldn't DEF?" (And don't get me started with all of those romance novels by Nora Roberts being qualified for the db.) Mhhutchins|talk 19:08, 17 October 2015 (UTC)

Oh, I agree. I just don't know enough about the series to tell whether volumes 3+ have significant "secret history" elements. Something to ask on a Goodreads forum, perhaps? Ahasuerus 19:15, 17 October 2015 (UTC)

Changes to the way cover indicators appear on the Title page

If you have the "Cover" column enabled on the Title page (under My Preferences), you will now see the name of the site hosting the cover scan. At this time the display values are limited to "ISFDB", "Amazon" and "other", but we can easily make the software display full site names instead of "other" if desired.

Another proposed enhancement is to change the destination page for "ISFDB" images. Currently if you click on "ISFDB", the actual image is displayed. The proposed change would display the Wiki page associated with the image, which will typically have additional information about it, instead. Would that be desirable? Ahasuerus 02:21, 18 October 2015 (UTC)

Yes. Hauck 19:02, 18 October 2015 (UTC)

I've chosen not to see that column displayed, so I tried it. Still didn't care for it. In any case, I'm not sure how a non-editing user who clicks on it would understand about the wiki page for it. Mhhutchins|talk 19:31, 18 October 2015 (UTC)

I don't think it's a good idea to link the the image wiki page for now because I always get "Error creating thumbnail: /var/www/html/wiki//bin/ulimit4.sh: line 4: /usr/local/bin/convert: No such file or directory" in the image area of such a wiki page with Firefox (on Ubuntu 14.04 and 15.04, all add-ons disabled). Google Chrome and Opera work fine, however, and strangely Firefox on Windows works too. I have no idea how Ubuntu's Firefox can lead to such an error on the server side while other browsers don't. This might not be a wide-spread problem, but since Firefox is wide-spread it's probably better to link to the image itself until this problem is fixed permanently. Jens Hitspacebar 08:26, 19 October 2015 (UTC)

Fascinating :) Thanks for sharing! Ahasuerus 04:03, 20 October 2015 (UTC)

Are you sure that's true - for the same image? The fact whether that error comes or not should depend on the size of the image (when > 600 px), not the browser. Issue can be fixed easily by installing ImageMagick on the server, so that "/usr/local/bin/convert" exists. --Stoecker 08:36, 20 October 2015 (UTC)

Yep, same image wiki page URL. Example: this one produces the error, depending on browser version and operation system, like I mentioned above. But your hint regarding the image size was good: it indeed seems to depend on it, because this smaller cover image with 310 × 443 pixels works in all browsers I tested with. Jens Hitspacebar 09:38, 20 October 2015 (UTC)

Ahhh, I just had an idea and found the reason for this strange behaviour: it does not depend on the browser version but on whether I am logged in into the ISFDB wiki or not! So if I'm not logged in it all works fine. If I'm logged in the error depends on the setting for "Limit images on file description pages to" on the "Files" tab in my user preferences. In other words: if the wiki software thinks it needs to create a thumbnail for the image in a wiki page because of the settings it fails. Jens Hitspacebar 09:48, 20 October 2015 (UTC)

Images on the front page?

Is everyone happy with the size/dimensions of the cover scans displayed on the front page? We are currently tweaking the display logic to make the HTML and CSS standards-compliant, so now would be a good time to decide if they need to be made bigger/smaller/etc. Ahasuerus 18:47, 18 October 2015 (UTC)

I'd like to see the covers a little bigger, maybe increase the width by about a quarter? To my eye, at the moment they look too small compared to the size of the type. PeteYoung 04:13, 19 October 2015 (UTC)

Perhaps if you could tell us what the upper limitations are for a "reasonable" size, we could comment/speculate our opinions on the topic. If an additional 10% increase is outside the limitations of reason, then most any comment/speculation would be superfluous. Blargg 21:54, 19 October 2015 (UTC)

I can live with the size displayed. It only takes some time to adjust to it, I'd think. Stonecreek 03:52, 20 October 2015 (UTC)

I would not increase the size. It's on overview, so it should be compact. Better would be a dynamic amount of columns (e.g. 3 or 4 on wide csreens), but I found no way to do that without scripts. --Stoecker 08:38, 20 October 2015 (UTC)

New/Edit/Clone Publication changes

The Web pages responsible for creating, editing and cloning publications have been changed. You may need to force a page refresh (typically Control-F5) in order to see the new layout correctly.

The majority of the changes happened behind the scenes, but a few are visible to naked eye. In the "Content" section, the following fields have been made wider to make it easier to see what you are typing: Page, Title, Author, Reviewer, Interviewee, Interviewer. If this causes any problems, we can undo the changes quickly. Everything else should be the same, so if you see any irregularities, please report them here. Ahasuerus 01:09, 20 October 2015 (UTC)

"My ..." links while editing?

At this time our edit pages display only one "My ..." link, "My Messages". Regular bibliographic pages also display the rest of "My..." links, i.e. "My Preferences", "My Recent Edits", etc. An editor would like to see all of "My ..." links displayed on all edit pages. Any objections? Ahasuerus 16:44, 20 October 2015 (UTC)

Thanks for the suggestion, Ahasuerus. For me, the usual bundle outside the Edit screens is sufficient, though. Stonecreek 17:15, 20 October 2015 (UTC)

No objections. I'd seldom use it, but it wouldn't disturb either. Jens Hitspacebar 18:12, 20 October 2015 (UTC)

COVERART bug fixed

There was a bug in the "Publication Update" code. An attempt to remove a COVERART title from a publication could fail with a Python error if the COVERART record had multiple artists and was shared by multiple pubs. The immediate bug has been fixed, but I am still working on the larger COVERART issue. It will take many more patches to get us where we need to be. Ahasuerus 16:42, 26 October 2015 (UTC)

Are all fanzines "In"?

Are there any constraints on what fanzines should be included in our database? Aside from the issues of priorities, and having the time to get to them, that is. At present, we seem primarily to have listings for fanzines that have won (or been nominated for) the "Best Fanzine" Hugo, along with a few others that editors have decided to add. And many of even those Hugo winning fanzines have minimal support -- e.g. Cry of the Nameless won the Hugo in 1960, so we have title recs for 1958 and 1959, but not for any of the other years of its run (1950-64 and 1968-70). And for those two years with title recs, there are no publications listed, even as "stubs". Altogether, we have partial data on about 250 fanzine titles, while sources such as the Ned Brooks index have over 5000 fanzine titles. Should we be expecting that some day we should have all of those titles indexed with us as well? Or would we want to limit ourselves to some type(s) of subsets? Chavey 16:11, 27 October 2015 (UTC)

I see no reason why any fanzine should be excluded unless it is not specifically devoted to speculative fiction. For example, a fanzine about horror films wouldn't be eligible. But as you suggest, it's a matter of prioritizing. I personally wouldn't allocate much time to creating dummy records when there are hundreds of spec-fic publications listed by Tuck and Reginald that still aren't in the database. But a fan of fanzines would think differently. Mhhutchins|talk 02:19, 28 October 2015 (UTC)

The big difference, to me, is that I have electronic copies of the Ned Brooks list, hence can create scripts to enter them. I have no electronic version of Tuck or Reginald, so all data would have to be entered from the print copies via pounding away at the keyboard. Chavey 04:35, 28 October 2015 (UTC)

For the most part I agree, but "perzines", i.e. "personal zines", may be a grey area. Would a perzine published by Marion Zimmer Bradley be "in"? What about Harry Warner, Jr.? Ahasuerus 02:24, 28 October 2015 (UTC)

Some perzines discuss the author's experiences at cons, visits with other fans, and things of general fannish interest, so I suspect those would be "in". Others are really more strictly personal, e.g. one I remember spent the entire issue discussing the author's health and had no connection with "fandom" outside of the fact that this particular writer was a moderately well-known fan in one region. I would think the former would be included, but not the latter. Fancyclopedia describes a perzine as "a zine written entirely by its [fan editor]. It may have outside contributors, particularly of fanart and [letters], but the bulk of it will be by its originator. Perzines are often diary or letter substitutes, but they may also feature articles, trip reports, book reviews or whatever it occurs to the editor to include." I think those that feature articles, trip reports, book reviews, etc. would be "in". A perzine by MZB, for example, will probably include a poem by her, and that would be surely be relevant. I don't know Harry Warner, Jr's work as well, but my sense is that he often talks about fannish activities going on, including cons and other interactions, and much of that would probably be "in". Chavey 04:35, 28 October 2015 (UTC)